Re: [em28xx] No sound in Leadtek WinFast TV USB II (not Deluxe)
2010/5/7 Владимир Чернышев : > Hello. > > I try to plug Leadtek WinFast TV USB II (LR6021 Rev. C) to my Ubuntu > 10.04 (2.6.32-22-generic #33-Ubuntu SMP Wed Apr 28 13:27:30 UTC 2010 > i686 GNU/Linux with all latest security and updates ). First I try > card=8 - no results, then I try card=28 (because in Windows it seems > like Leadtek WinFast TV USB II Deluxe) - TV works fine, tvtime scans > all available channels, but no sound in any audio standards > (/dev/mixer:line1 is ok with other sources). If I start tuner in > Windows, make hard reset, boot Ubuntu and start tvtime then audio > works fine at all channels while tuner is powered on. So I think > em28xx doesn't execute some initializing sequence for turn on audio. > > With latest version from http://linuxtv.org/hg/v4l-dvb my tuner works > only if i change SAA7115_COMPOSITE4 to SAA7115_COMPOSITE2 in > EM28XX_VMUX_TELEVISION section for Leadtek WinFast TV USB II Deluxe in > em28xx-cards.c and only video too. /dev/radio detected but not work > too. > > Any tips, recommendations? I don't want use Windows to tuner init only :) > > The peace of dmesg when I don't set card: > > em28xx #0: found i2c device @ 0x30 [???] > em28xx #0: found i2c device @ 0x3e [???] > em28xx #0: found i2c device @ 0x4a [saa7113h] > em28xx #0: found i2c device @ 0x86 [tda9887] > em28xx #0: found i2c device @ 0xb0 [tda9874] > em28xx #0: found i2c device @ 0xc2 [tuner (analog)] > em28xx #0: Board i2c devicelist hash is 0x81bb00dc > > dmesg with "original" (srcversion: AC6C6B6C3CB530BED33DFD3) em28xx > > em28xx: New device @ 480 Mbps (eb1a:2820, interface 0, class 0) > em28xx #0: chip ID is em2820 (or em2710) > em28xx #0: board has no eeprom > em28xx #0: Identified as Leadtek Winfast USB II Deluxe (card=28) > em28xx #0: > em28xx #0: The support for this board weren't valid yet. > em28xx #0: Please send a report of having this working > em28xx #0: not to V4L mailing list (and/or to other addresses) > saa7115 2-0025: saa7113 found (1f7113d0e10) @ 0x4a (em28xx #0) > tuner 2-0043: chip found @ 0x86 (em28xx #0) > tda9887 2-0043: creating new instance > tda9887 2-0043: tda988[5/6/7] found > tuner 2-0061: chip found @ 0xc2 (em28xx #0) > tuner-simple 2-0061: creating new instance > tuner-simple 2-0061: type set to 38 (Philips PAL/SECAM multi (FM1216ME MK3)) > em28xx #0: Config register raw data: 0x00 > em28xx #0: v4l2 driver version 0.1.2 > em28xx #0: V4L2 video device registered as /dev/video0 > usbcore: registered new interface driver em28xx > em28xx driver loaded > > dmesg with latest (srcversion: 7B6A05D4D518CB79FF69F9D) em28xx (with > minor change sad above). > > em28xx: New device @ 480 Mbps (eb1a:2820, interface 0, class 0) > em28xx #0: chip ID is em2820 (or em2710) > em28xx #0: board has no eeprom > input: i2c IR (i2c IR (EM2820 Winfast as /devices/virtual/irrcv/irrcv0/input7 > irrcv0: i2c IR (i2c IR (EM2820 Winfast as /devices/virtual/irrcv/irrcv0 > ir-kbd-i2c: i2c IR (i2c IR (EM2820 Winfast detected at > i2c-2/2-001f/ir0 [em28xx #0] > em28xx #0: Identified as Leadtek Winfast USB II Deluxe (card=28) > em28xx #0: > em28xx #0: The support for this board weren't valid yet. > em28xx #0: Please send a report of having this working > em28xx #0: not to V4L mailing list (and/or to other addresses) > saa7115 2-0025: saa7113 found (1f7113d0e10) @ 0x4a (em28xx #0) > tvaudio 2-0058: found tda9874a. > tvaudio 2-0058: tda9874h/a found @ 0xb0 (em28xx #0) > tuner 2-: chip found @ 0x0 (em28xx #0) > tuner 2-0043: chip found @ 0x86 (em28xx #0) > tda9887 2-0043: creating new instance > tda9887 2-0043: tda988[5/6/7] found > tuner 2-0061: chip found @ 0xc2 (em28xx #0) > tuner-simple 2-: unable to probe Alps TSBE1, proceeding anyway. > tuner-simple 2-: creating new instance > tuner-simple 2-: type set to 10 (Alps TSBE1) > tuner-simple 2-0061: creating new instance > tuner-simple 2-0061: type set to 38 (Philips PAL/SECAM multi (FM1216ME MK3)) > em28xx #0: Config register raw data: 0x00 > em28xx #0: v4l2 driver version 0.1.2 > em28xx #0: Registered radio device as radio0 > em28xx #0: V4L2 video device registered as video0 > usbcore: registered new interface driver em28xx > em28xx driver loaded > -- > To unsubscribe from this list: send the line "unsubscribe linux-media" in > the body of a message to majord...@vger.kernel.org > More majordomo info at http://vger.kernel.org/majordomo-info.html > Hi, the main problem (I think) is that your box doesn't support audio over usb. So when you use the "card=28" option, it doesn't turn on the audio output connector. Your box has a Em2800 chip, where the "Deluxe" version uses a Em2820. I'll take a look at the code when I comes home, maybe I can figure something out. Your box is supposed to be supported but maybe some regression in the codes has happend. /Magnus -- 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/majord
Re: [PATCH] dvb_frontend: fix typos in comments and one function
Hello Steven, > I've had an open TDA10048 bug on my list for quite a while, I think > you've already made reference to this in an earlier email. Essentially > I'm told my a number of Australian users that the 10048 isn't > broad-locking when tuned +- 167Khz away from the carrier, which it > should definitely do. If you're in the mood for patching the 10048 and > want to find and flip the broad-locking bit then I'd be certainly > thrilled to test this. :) Well, this is an interesting subject and there is a lot to say. Sorry in advance if you already know what I will explain: - the channel distribution is usually well known in DVB-T. For example, from 474MHz to 858MHz in UHF/8MHz. This channel distribution depends on each country. - due to the existing analogue channels, some FIXED frequency offsets have been introduced here and there to move the DVB-T channel away from the analogue channels depending on how critical it can be. These frequency offsets are commonly +/-166KHz everywhere, except in France (+/-N*166KHz with N=1,2,3) and in Australia (+/-125KHz) as far as I know. - hence the DVB-T channel can be shifted in IF by +/-125KHz, +/-166KHz, +/-333KHz, +/-500KHz. The channel decoder will or will not recover such an offset depending on the strategy. If it can lock, the IF signal will be partially filtered out by the IF filter and this impacts the performance. The best approach is to detect the potential frequency offset and re-program the tuner to the new frequency. Now about the TDA10048: - it naturally recovers the small offsets during the lock (error returned in FREQERR_R at 0x28 & 0x29): in 8MHz: +/-93KHz in 7MHz: +/-82KHz in 6MHz: +/-70KHz - the AUTOOFFSET bit allows to detect the fixed frequency offset whose value is returned in OFFSET_F (in 0x14) when there is no lock. If an offset is detected, it is applied to the tuner, then AUTOOFFSET is set to 0 and the acquisition is checked again. This is the normal and preferred way. The non-recommended option is to force the lock when a fixed offset is detected without reprogramming the tuner. This is possible only with certain firmware versions (>=0x34), in forcing 1 in register 0x19[0], the fixed offset will still be available in OFFSET_F after the lock. For earlier firmware versions, the 0x19[0] bit has no effect. Ideally, for the channel demodulator driver, the API should provide an interface to set the frequency offset recovery (AUTO, NONE...) and to get the detected frequency offset if any. -- Guillaume -- 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 -next 1/2] media/az6027: doing dma on the stack
walter harms wrote: > > Dan Carpenter schrieb: >> I changed the dma buffers to use allocated memory instead of stack >> memory. >> >> The reason for this is documented in Documentation/DMA-API-HOWTO.txt >> under the section: "What memory is DMA'able?" That document was only >> added a couple weeks ago and there are still lots of modules which >> haven't been corrected yet. Btw. Smatch includes a pretty good test to >> find places which use stack memory as a dma buffer. That's how I found >> these. (http://smatch.sf.net). >> >> Signed-off-by: Dan Carpenter >> >> diff --git a/drivers/media/dvb/dvb-usb/az6027.c >> b/drivers/media/dvb/dvb-usb/az6027.c >> index 8934788..baaa301 100644 >> --- a/drivers/media/dvb/dvb-usb/az6027.c >> +++ b/drivers/media/dvb/dvb-usb/az6027.c >> @@ -417,11 +417,15 @@ static int az6027_ci_read_attribute_mem(struct >> dvb_ca_en50221 *ca, >> u16 value; >> u16 index; >> int blen; >> -u8 b[12]; >> +u8 *b; >> >> if (slot != 0) >> return -EINVAL; >> >> +b = kmalloc(12, GFP_KERNEL); >> +if (!b) >> +return -ENOMEM; >> + >> mutex_lock(&state->ca_mutex); >> >> req = 0xC1; > > > Hi Dan, > i am not sure if that is the way to go. > iff i understand the code correctly the b[12] seems to overcommit only > blen bytes (not 12) is needed. There must be a cheaper way to send a few bytes > of space to send a command to a device. Perhaps gregKH has a hint ? There is: you can add an array on a device private structure to hold those memory transfers. For now, I'll add this patch, as it corrects a real bug. 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
[GIT PULL for 2.6.34] V4L/DVB fixes
The following changes since commit 722154e4cacf015161efe60009ae9be23d492296: Linus Torvalds (1): Merge branch 'zerolen' of git://git.kernel.org/.../jgarzik/misc-2.6 are available in the git repository at: ssh://master.kernel.org/pub/scm/linux/kernel/git/mchehab/linux-2.6.git v4l_for_2.6.34 Bjørn Mork (1): V4L/DVB: budget: Oops: "BUG: unable to handle kernel NULL pointer dereference" Dan Carpenter (2): V4L/DVB: omap24xxcam: potential buffer overflow V4L/DVB: video: testing unsigned for less than 0 Erik Andrén (1): V4L/DVB: gspca - stv06xx: Remove the 046d:08da from the stv06xx driver Hans Verkuil (3): V4L/DVB: feature-removal: announce videotext.h removal V4L/DVB: v4l: fix config dependencies: mxb and saa7191 are V4L2 drivers, not V4L1 V4L/DVB: saa7146: fix regression of the av7110/budget-av driver John Ellson (1): V4L/DVB: gspca: make usb id 0461:0815 get handled by the right driver Michael Hunold (1): V4L/DVB: saa7146: fix up bytesperline if it is an impossible value Murali Karicheri (1): V4L/DVB: V4L: vpfe_capture - free ccdc_lock when memory allocation fails Muralidharan Karicheri (1): V4L/DVB: V4L - vpfe capture - fix for kernel crash Oliver Endriss (1): V4L/DVB: ngene: Workaround for stuck DiSEqC pin Stefan Herbrechtsmeier (1): V4L/DVB: pxa_camera: move fifo reset direct before dma start Uwe Kleine-König (1): V4L/DVB: mx1-camera: compile fix Vaibhav Hiremath (1): V4L/DVB: V4L - Makfile:Removed duplicate entry of davinci Yong Zhang (1): V4L/DVB: gspca - sn9c20x: Correct onstack wait_queue_head declaration Documentation/feature-removal-schedule.txt | 23 +++ arch/arm/plat-mxc/include/mach/dma-mx1-mx2.h |8 +- drivers/media/common/saa7146_fops.c | 11 +++ drivers/media/common/saa7146_video.c |8 +++-- drivers/media/dvb/frontends/stv090x.c|4 +++ drivers/media/dvb/ttpci/budget.c |3 -- drivers/media/video/Kconfig |4 +- drivers/media/video/Makefile |2 - drivers/media/video/davinci/vpfe_capture.c | 38 +++-- drivers/media/video/gspca/sn9c20x.c |2 +- drivers/media/video/gspca/spca508.c |1 - drivers/media/video/gspca/spca561.c |1 + drivers/media/video/gspca/stv06xx/stv06xx.c |2 - drivers/media/video/hexium_gemini.c |3 -- drivers/media/video/hexium_orion.c |4 --- drivers/media/video/mx1_camera.c |8 ++--- drivers/media/video/mxb.c| 17 +-- drivers/media/video/omap24xxcam.c|2 +- drivers/media/video/pxa_camera.c | 11 --- drivers/media/video/sh_mobile_ceu_camera.c |2 +- include/media/saa7146_vv.h |1 - 21 files changed, 90 insertions(+), 65 deletions(-) -- 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
[em28xx] No sound in Leadtek WinFast TV USB II (not Deluxe)
Hello. I try to plug Leadtek WinFast TV USB II (LR6021 Rev. C) to my Ubuntu 10.04 (2.6.32-22-generic #33-Ubuntu SMP Wed Apr 28 13:27:30 UTC 2010 i686 GNU/Linux with all latest security and updates ). First I try card=8 - no results, then I try card=28 (because in Windows it seems like Leadtek WinFast TV USB II Deluxe) - TV works fine, tvtime scans all available channels, but no sound in any audio standards (/dev/mixer:line1 is ok with other sources). If I start tuner in Windows, make hard reset, boot Ubuntu and start tvtime then audio works fine at all channels while tuner is powered on. So I think em28xx doesn't execute some initializing sequence for turn on audio. With latest version from http://linuxtv.org/hg/v4l-dvb my tuner works only if i change SAA7115_COMPOSITE4 to SAA7115_COMPOSITE2 in EM28XX_VMUX_TELEVISION section for Leadtek WinFast TV USB II Deluxe in em28xx-cards.c and only video too. /dev/radio detected but not work too. Any tips, recommendations? I don't want use Windows to tuner init only :) The peace of dmesg when I don't set card: em28xx #0: found i2c device @ 0x30 [???] em28xx #0: found i2c device @ 0x3e [???] em28xx #0: found i2c device @ 0x4a [saa7113h] em28xx #0: found i2c device @ 0x86 [tda9887] em28xx #0: found i2c device @ 0xb0 [tda9874] em28xx #0: found i2c device @ 0xc2 [tuner (analog)] em28xx #0: Board i2c devicelist hash is 0x81bb00dc dmesg with "original" (srcversion: AC6C6B6C3CB530BED33DFD3) em28xx em28xx: New device @ 480 Mbps (eb1a:2820, interface 0, class 0) em28xx #0: chip ID is em2820 (or em2710) em28xx #0: board has no eeprom em28xx #0: Identified as Leadtek Winfast USB II Deluxe (card=28) em28xx #0: em28xx #0: The support for this board weren't valid yet. em28xx #0: Please send a report of having this working em28xx #0: not to V4L mailing list (and/or to other addresses) saa7115 2-0025: saa7113 found (1f7113d0e10) @ 0x4a (em28xx #0) tuner 2-0043: chip found @ 0x86 (em28xx #0) tda9887 2-0043: creating new instance tda9887 2-0043: tda988[5/6/7] found tuner 2-0061: chip found @ 0xc2 (em28xx #0) tuner-simple 2-0061: creating new instance tuner-simple 2-0061: type set to 38 (Philips PAL/SECAM multi (FM1216ME MK3)) em28xx #0: Config register raw data: 0x00 em28xx #0: v4l2 driver version 0.1.2 em28xx #0: V4L2 video device registered as /dev/video0 usbcore: registered new interface driver em28xx em28xx driver loaded dmesg with latest (srcversion: 7B6A05D4D518CB79FF69F9D) em28xx (with minor change sad above). em28xx: New device @ 480 Mbps (eb1a:2820, interface 0, class 0) em28xx #0: chip ID is em2820 (or em2710) em28xx #0: board has no eeprom input: i2c IR (i2c IR (EM2820 Winfast as /devices/virtual/irrcv/irrcv0/input7 irrcv0: i2c IR (i2c IR (EM2820 Winfast as /devices/virtual/irrcv/irrcv0 ir-kbd-i2c: i2c IR (i2c IR (EM2820 Winfast detected at i2c-2/2-001f/ir0 [em28xx #0] em28xx #0: Identified as Leadtek Winfast USB II Deluxe (card=28) em28xx #0: em28xx #0: The support for this board weren't valid yet. em28xx #0: Please send a report of having this working em28xx #0: not to V4L mailing list (and/or to other addresses) saa7115 2-0025: saa7113 found (1f7113d0e10) @ 0x4a (em28xx #0) tvaudio 2-0058: found tda9874a. tvaudio 2-0058: tda9874h/a found @ 0xb0 (em28xx #0) tuner 2-: chip found @ 0x0 (em28xx #0) tuner 2-0043: chip found @ 0x86 (em28xx #0) tda9887 2-0043: creating new instance tda9887 2-0043: tda988[5/6/7] found tuner 2-0061: chip found @ 0xc2 (em28xx #0) tuner-simple 2-: unable to probe Alps TSBE1, proceeding anyway. tuner-simple 2-: creating new instance tuner-simple 2-: type set to 10 (Alps TSBE1) tuner-simple 2-0061: creating new instance tuner-simple 2-0061: type set to 38 (Philips PAL/SECAM multi (FM1216ME MK3)) em28xx #0: Config register raw data: 0x00 em28xx #0: v4l2 driver version 0.1.2 em28xx #0: Registered radio device as radio0 em28xx #0: V4L2 video device registered as video0 usbcore: registered new interface driver em28xx em28xx driver loaded -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
dvb_ttpci: PES packet shortened; cx8800 and dvb_ttpci crashes on rmmod (2.6.34-rc6)
Hi, on a crusade to get a setup with one FF Hauppauge WinTV Nexus-S + CAM and two Hauppauge WinTV-HVR400 to behave well (again) with vdr (1.6.0 now), finally I've been arrived at kernel 2.6.34-rc6 and still suffering.. :-( Accessing sky channels via CAM/AlphaCrypt could result in floods of PES packet shortened to bytes (expected: bytes) in vdr logs. Once this starts, the display is distorted from heavy pixel junk, and nothing cures this issue other than rebooting. :-(... Is this a known problem? Any idea on how to debug/fix such an problem? The "normal" course of actions in this case is: reloading modules, but neither cx8800 nor dvb_ttpci do unload properly ATM: [ 324.584972] cx8800 :07:02.0: PCI INT A disabled [ 324.630743] cx8800 :07:01.0: PCI INT A disabled [ 324.630838] BUG: unable to handle kernel paging request at 38352e34 [ 324.643415] IP: [] sysfs_remove_group+0x7e/0xd0 [ 324.654404] *pdpt = 23528001 *pde = [ 324.666116] Oops: [#1] SMP [ 324.672707] last sysfs file: /sys/devices/system/cpu/cpu7/cache/index2/shared_cpu_map [ 324.688553] Modules linked in: ip6t_LOG ipt_MASQUERADE xt_pkttype xt_TCPMSS xt_tcpudp ipt_LOG xt_limit iptable_nat nf _nat nfsd autofs4 af_packet nfs lockd fscache nfs_acl auth_rpcgss sunrpc cpufreq_conservative cpufreq_userspace cpufreq_ powersave acpi_cpufreq speedstep_lib ip6t_REJECT nf_conntrack_ipv6 ip6table_raw xt_NOTRACK ipt_REJECT xt_physdev xt_stat e iptable_raw iptable_filter ip6table_mangle nf_conntrack_netbios_ns nf_conntrack_ipv4 nf_conntrack nf_defrag_ipv4 ip_ta bles ip6table_filter ip6_tables x_tables bridge stp llc fuse aufs loop dm_mod isl6421 cx24116 stv0299 ves1x93 tuner dvb_ ttpci dvb_core snd_hda_intel saa7146_vv snd_hda_codec cx8800(-) cx88xx v4l2_common ir_common videodev i2c_algo_bit snd_h wdep saa7146 v4l1_compat tveeprom snd_pcm ir_core snd_timer videobuf_dma_sg snd tpm_tis iTCO_wdt i2c_i801 videobuf_core tpm btcx_risc pcspkr button sr_mod tpm_bios cdrom iTCO_vendor_support pl2303 usbserial e1000e usbhid ttpci_eeprom soundc ore snd_page_alloc kvm_intel sg kvm ehci_hcd usbcore edd xfs exportfs fan thermal processor thermal_sys sd_mod ata_piix libata arcmsr scsi_mod [last unloaded: cx88_alsa] [ 324.890574] [ 324.893587] Pid: 7320, comm: modprobe Not tainted 2.6.34-rc6-4-pae #1 P7F-E/System Product Name [ 324.911008] EIP: 0060:[] EFLAGS: 00010202 CPU: 4 [ 324.922133] EIP is at sysfs_remove_group+0x7e/0xd0 [ 324.931832] EAX: e6a50e08 EBX: 38352e34 ECX: e7e0 EDX: [ 324.944559] ESI: EDI: e641285c EBP: e6a50e08 ESP: e2b9be70 [ 324.957181] DS: 007b ES: 007b FS: 00d8 GS: 0033 SS: 0068 [ 324.968084] Process modprobe (pid: 7320, ti=e2b9a000 task=e51b0270 task.ti=e2b9a000) [ 324.983565] Stack: [ 324.987715] 0286 0001 e64da9dc e6a50a00 0286 e6412840 e6889000 [ 325.003149] <0> e6bb2800 f03ae932 e6412840 e6889000 f03ae044 faff e6c8f180 [ 325.019671] <0> e6bb2800 f04ba5e5 fa00 f04b6dd9 0100 faff [ 325.036573] Call Trace: [ 325.041554] [] ir_unregister_class+0x32/0x60 [ir_core] [ 325.053888] [] ir_input_unregister+0x44/0x90 [ir_core] [ 325.066202] [] cx88_ir_fini+0x25/0x50 [cx88xx] [ 325.077213] [] cx88_core_put+0xb9/0x140 [cx88xx] [ 325.088434] [] cx8800_finidev+0x7e/0x89 [cx8800] [ 325.099765] [] pci_device_remove+0x16/0x40 [ 325.110004] [] __device_release_driver+0x6d/0xd0 [ 325.121232] [] driver_detach+0x7f/0x90 [ 325.130751] [] bus_remove_driver+0x7a/0x100 [ 325.141196] [] pci_unregister_driver+0x2e/0x80 [ 325.152163] [] sys_delete_module+0x179/0x250 [ 325.162684] [] sysenter_do_call+0x12/0x22 [ 325.172618] [] 0xe424 [ 325.179852] Code: f0 ff 0e 0f 94 c0 84 c0 75 0b 83 c4 14 5b 5e 5f 5d c3 8d 76 00 83 c4 14 89 f0 5b 5e 5f 5d e9 ca e6 ff ff 66 90 31 f6 85 db 74 a3 <8b> 03 85 c0 74 07 f0 ff 03 89 de eb 96 ba 9d 00 00 00 b8 e8 81 [ 325.220532] EIP: [] sysfs_remove_group+0x7e/0xd0 SS:ESP 0068:e2b9be70 [ 325.235367] CR2: 38352e34 [ 325.242044] ---[ end trace ad00d5df5a39e6b6 ]--- This one I was able to work around by blacklisting ir_common and ir_core (this is a server install anyway), but unloading dvb_ttpci results in: [ 64.526813] cx24116_load_firmware: FW version 1.22.82.0 [ 64.526823] cx24116_firmware_ondemand: Firmware upload complete [ 131.523444] cx88/2: unregistering cx8802 driver, type: dvb access: shared [ 131.523451] cx88[0]/2: subsystem: 0070:6906, board: Hauppauge WinTV-HVR4000(Lite) DVB-S/S2 [card=69] [ 131.524048] cx88[1]/2: subsystem: 0070:6906, board: Hauppauge WinTV-HVR4000(Lite) DVB-S/S2 [card=69] [ 131.554953] cx88-mpeg driver manager :07:02.2: PCI INT A disabled [ 131.555024] cx88-mpeg driver manager :07:01.2: PCI INT A disabled [ 143.260583] cx88_audio :07:02.1: PCI INT A disabled [ 143.260670] cx88_audio :07:01.1: PCI INT A disabled [ 171.110862] cx8800 :07:02.0: PCI INT
[PATCH -next] IR: add header file to fix build
From: Randy Dunlap Fix build error: drivers/media/IR/rc-map.c:51: error: implicit declaration of function 'msleep' Signed-off-by: Randy Dunlap Cc: Mauro Carvalho Chehab --- drivers/media/IR/rc-map.c |1 + 1 file changed, 1 insertion(+) --- linux-next-20100506.orig/drivers/media/IR/rc-map.c +++ linux-next-20100506/drivers/media/IR/rc-map.c @@ -13,6 +13,7 @@ */ #include +#include #include /* Used to handle IR raw handler extensions */ -- 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 01/15] [RFC] v4l: Add new control handling framework
Hi Hans, I don't think I should review the code in details before we agree on the architecture (please correct me if I'm wrong). Two comments though. On Monday 26 April 2010 09:33:30 Hans Verkuil wrote: [snip] > diff --git a/include/media/v4l2-ctrls.h b/include/media/v4l2-ctrls.h > new file mode 100644 > index 000..ea23f3d > --- /dev/null > +++ b/include/media/v4l2-ctrls.h [snip] > +/* Fill in the control fields based on the control ID. This works for all > + standard V4L2 controls. > + For non-standard controls it will only fill in the given arguments > + and name will be NULL. > + This function will overwrite the contents of name, type and flags. > + The contents of min, max, step and def may be modified depending on > + the type. > + Do not use in drivers! It is used internally for backwards > compatibility + control handling only. Once all drivers are converted to > use the new + control framework this function will no longer be > exported. */ +void v4l2_ctrl_fill(u32 id, const char **name, enum > v4l2_ctrl_type *type, + s32 *min, s32 *max, s32 *step, s32 > *def, u32 > *flags); Using kerneldoc comments in the source file would provide a much better documentation than a few lines of comment in the header. [snip] > diff --git a/include/media/v4l2-dev.h b/include/media/v4l2-dev.h > index 2dee938..cc9ed09 100644 > --- a/include/media/v4l2-dev.h > +++ b/include/media/v4l2-dev.h > @@ -27,6 +27,7 @@ > struct v4l2_ioctl_callbacks; > struct video_device; > struct v4l2_device; > +struct v4l2_ctrl_handler; > > /* Flag to mark the video_device struct as registered. > Drivers can clear this flag if they want to block all future > @@ -66,6 +67,9 @@ struct video_device > struct device *parent; /* device parent */ > struct v4l2_device *v4l2_dev; /* v4l2_device parent */ > > + /* Control handler associated with this device node. May be NULL. */ Shouldn't we talk about a control*s* handler ? It handles more than one control (would be a bit pointless otherwise :-)). -- Regards, Laurent Pinchart -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 03/15] [RFC] Documentation: add v4l2-controls.txt documenting the new controls API.
Hi Hans, On Monday 03 May 2010 00:21:46 Hans Verkuil wrote: > On Sunday 02 May 2010 22:39:11 Laurent Pinchart wrote: > > On Monday 26 April 2010 09:33:38 Hans Verkuil wrote: [snip] > > > +Objects in the framework > > > + > > > + > > > +There are two main objects: > > > + > > > +The v4l2_ctrl object describes the control properties and keeps track > > > of the > > > +control's value (both the current value and the proposed new value). > > > > I'm not sure v4l2_ctrl is a good name. We already have a v4l2_control > > structure, and using the abbreviated name for the in-kernel version is > > going to be confusing. > > Originally it was called v4l2_ctrl_info but that became very cumbersome. > It's not really an info object anyway, it really describes a control. When > using this framework the driver no longer sees the v4l2_control anymore, so > from the point of view of the driver there is only v4l2_ctrl. Sure, but it's still misleading. Using an both the abbreviated and non- abbreviated names to refer to two different things has been done too often in V4L2, and it's starting to bother me. It makes the API look inconsistent. We need to define a naming policy and stick to it for the future. That can be a topic for the V4L2 summit in June. > > It's obviously too late to change v4l2_control to something else. > > v4l2_control_info and v4l2_control_value are two names that come to my > > mind. Actually, it might be a good idea to split the v4l2_ctrl structure > > into a static driver-wide structure (v4l2_control_info) and an > > instance-specific structure (v4l2_control_value). There's no point in > > storing the same static data (function pointers, names, ...) for > > identical controls in different devices. > > Other than the name there isn't anything that is static. And the name is > already static. The following fields are static (they're identical across all v4l2_ctrl instances for the same control): - ops - id - name - type - menu (not too sure about this one) [snip] > > > + > > > + How to hook the handler into a bridge driver: > > > + > > > + foo->v4l2_dev.ctrl_handler = &foo->hdl; [snip] > > > + > > > + And whenever you call video_register_device() you must set the > > > + ctrl_handler field of struct video_device as well: > > > + > > > + vdev->ctrl_handler = &foo->hdl; [snip] > > Why can't the framework find the ctrl_handler instance from the > > video_device's v4l2_device parent ? > > Sometimes you want to provide different control handlers to different > video devices. E.g. /dev/radio0 may have only a small subset of the > controls of /dev/video0 (bttv does that, for example). > > One option is to automatically let video_register_device copy ctrl_handler > from the v4l2_dev struct, but I think it is clearer if it is explicitly > set. I was thinking about copying it implicitly if it's not set, yes. That way only the v4l2_device instance would need an explicit handler, video devices would inherit it from their v4l2_device parent. The driver would still have the ability to set it if it wants to override the default behaviour. It might be clearer to always set it explicitly, I have no strong opinion on this one. > > > + Finally, remove all control functions from your v4l2_ioctl_ops: > > > + vidioc_queryctrl, vidioc_querymenu, vidioc_g_ctrl, vidioc_s_ctrl, > > > + vidioc_g_ext_ctrls, vidioc_try_ext_ctrls and vidioc_s_ext_ctrls. > > > + Those are now no longer needed. > > > + > > > + How to hook the control handler into a subdev driver: > > > + > > > + foo->sd.ctrl_handler = &foo->hdl; > > > + > > > + And set all core control ops in your struct v4l2_subdev_core_ops to > > > these > > > + helpers: > > > + > > > + .queryctrl = v4l2_sd_queryctrl, > > > + .querymenu = v4l2_sd_querymenu, > > > + .g_ctrl = v4l2_sd_g_ctrl, > > > + .s_ctrl = v4l2_sd_s_ctrl, > > > + .g_ext_ctrls = v4l2_sd_g_ext_ctrls, > > > + .try_ext_ctrls = v4l2_sd_try_ext_ctrls, > > > + .s_ext_ctrls = v4l2_sd_s_ext_ctrls, > > > > s/sd/subdev/ ? > > I have to sleep on that... :-) You've slept on it for a week now :-) We really have too many abbreviations in V4L2, or at least no consistent usage of them. [snip] > > What about hardware for which the boundaries are only known at runtime, > > or could depend on the values of other controls ? I'm thinking about UVC > > devices for instance, the boundaries, step and default values need to be > > retrieved from the hardware. I currently do that at runtime when the > > control is queried for the first time and cache the values, as doing it > > during initialization (probe function) crashes a few webcams. That > > doesn't seem to be possible with the control framework. > > It is possible to add controls to an existing control handler at runtime. > It is also possible to change boundaries at runtime: you just change the > relevant values in v4l2_ctrl. There is no function for that, it's enough > to call v4l2_ctrl_lock(), change the values a
Re: setting up a tevii s660
Hello Tim, i also have a tevii s660 which i cannot get to work properly. i'm no programmer and nobody has given a reaction on my previous posts (debugging my tevii...). I get this in my log after getting the source from the linuxtv site with the driver igor wrote: [ 45.654362] dvb-usb: found a 'TeVii S660 USB' in cold state, will try to load a firmware [ 45.654379] usb 1-3: firmware: requesting dvb-usb-s630.fw [ 45.717438] dvb-usb: downloading firmware from file 'dvb-usb-s630.fw' [ 45.717450] dw2102: start downloading DW210X firmware [ 45.824245] usb 1-3: USB disconnect, address 3 [ 45.930055] dvb-usb: found a 'TeVii S660 USB' in warm state. [ 45.930167] dvb-usb: will pass the complete MPEG2 transport stream to the software demuxer. [ 45.930233] DVB: registering new adapter (TeVii S660 USB) [ 56.182533] dvb-usb: MAC address: 00:00:00:00:00:00 [ 56.262532] mt312: R(126): 00 [ 56.262543] Only Zarlink VP310/MT312/ZL10313 are supported chips. [ 56.607024] ds3000_attach [ 56.642535] ds3000_readreg: read reg 0x00, value 0x00 [ 56.642542] Invalid probe, probably not a DS3000 [ 56.642816] dvb-usb: no frontend was attached by 'TeVii S660 USB' [ 56.643037] input: IR-receiver inside an USB DVB receiver as /devices/pci:00/:00:1d.7/usb1/1-3/input/input5 [ 56.643189] dvb-usb: schedule remote query interval to 150 msecs. [ 56.643203] dvb-usb: TeVii S660 USB successfully initialized and connected. [ 56.643290] usbcore: registered new interface driver dw2102 [ 56.773230] dvb-usb: TeVii S660 USB successfully deinitialized and disconnected. [ 57.050043] usb 1-3: new high speed USB device using ehci_hcd and address 5 in my previous post i got a message that an mt312 chip was found and now it does not find anything. so now i don't have a dvb device at all. the firmware is from the drivers from tevii. I tried and the s630 firmware and later the s660 firmware renamed to s630 but none worked. After installing the driver/changing the firmware, I shutdown the computer removed the power from the tevii device and then replugged and started my computer again. == modinfo dvb-usb-dw2102 filename: /lib/modules/2.6.34-020634rc2-generic/kernel/drivers/media/dvb/dvb-usb/dvb-usb-dw2102.ko license:GPL version:0.1 description:Driver for DVBWorld DVB-S 2101, 2102, DVB-S2 2104, DVB-C 3101 USB2.0, TeVii S600, S630, S650, S660 USB2.0, Prof 1100, 7500 USB2.0 devices author: Igor M. Liplianin (c) liplia...@me.by srcversion: FCBA4EFAEF1F6A88DC9F2DB alias: usb:v3034p7500d*dc*dsc*dp*ic*isc*ip* alias: usb:v9022pD660d*dc*dsc*dp*ic*isc*ip* alias: usb:v3011pB012d*dc*dsc*dp*ic*isc*ip* alias: usb:v9022pD630d*dc*dsc*dp*ic*isc*ip* alias: usb:v04B4p3101d*dc*dsc*dp*ic*isc*ip* alias: usb:v0CCDp0064d*dc*dsc*dp*ic*isc*ip* alias: usb:v9022pD650d*dc*dsc*dp*ic*isc*ip* alias: usb:v04B4p2104d*dc*dsc*dp*ic*isc*ip* alias: usb:v04B4p2101d*dc*dsc*dp*ic*isc*ip* alias: usb:v04B4p2102d*dc*dsc*dp*ic*isc*ip* depends:dvb-usb vermagic: 2.6.34-020634rc2-generic SMP mod_unload modversions parm: debug:set debugging level (1=info 2=xfer 4=rc(or-able)). (int) parm: keymap:set keymap 0=default 1=dvbworld 2=tevii 3=tbs ... (int) parm: demod:demod to probe (1=cx24116 2=stv0903+stv6110 4=stv0903+stb6100(or-able)). (int) parm: adapter_nr:DVB adapter numbers (array of short) if you need help testing i would be glad to help. The tevii drivers are working and also detect the mt312 chip. This driver does not, but i'm not very pleased about the driver from tevii because channel switch takes long and image quality is bad and my system get's slow/freezes. With kind regards William van de Velde On 05/06/2010 01:07 AM, Tim Coote wrote: Hullo I've been struggling with this for a couple of days. I have checked archives, but missed anything useful. I've got a tevii s660 (dvbs2 via usb). It works with some limitations on windows xp (I cannot get HD signals decoded, but think that's a limitation of the software that comes on the CD). I'm trying to get this working on Linux. I've tried VMs based on fedora 12 and mythbuntu (VMWare Fusion on a MacBookPro, both based on kernel 2.6.32), using the drivers from tevii's site (www.tevii.com/support.asp). these drivers are slightly modified versions of the v4l tip - but don't appear to be modified where I've not yet managed to get the drivers working :-(. Mythbuntu seems to be closest to working. Goodness knows how tevii tested the code, but it doesn't seem to work as far as I can see. My issues could just be down to using a VM. I believe that I need to load up the modules ds3000 and dvb-usb-dw2102, + add a rule to /etc/udev/rules.d and a script to /etc/udev/scripts. I think that I must be missing quite a lot of context, tho'. When I look at the cod
Visiting Nurses & RN's marketing email list
We have lists for healthcare, business & finance, consumers and professionals. Lots of different lists from various optin sources. Just send me an email here for additional info: mario.cul...@realresults.co.cc to get off please email disapp...@realresults.co.cc -- 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
Fwd: Re: setting up a tevii s660
On 06/05/2010 00:07, Tim Coote wrote: Hullo I've been struggling with this for a couple of days. I have checked archives, but missed anything useful. I've got a tevii s660 (dvbs2 via usb). It works with some limitations on windows xp (I cannot get HD signals decoded, but think that's a limitation of the software that comes on the CD). I downloaded version from tevii.com and it worked for me on laptop running win 7. Had problems with HD on an XP machine but I assumed it was because the video card was old/slow. I'm trying to get this working on Linux. I've tried VMs based on fedora 12 and mythbuntu (VMWare Fusion on a MacBookPro, both based on kernel 2.6.32), using the drivers from tevii's site (www.tevii.com/support.asp). these drivers are slightly modified versions of the v4l tip - but don't appear to be modified where I've not yet managed to get the drivers working :-(. Mythbuntu seems to be closest to working. Goodness knows how tevii tested the code, but it doesn't seem to work as far as I can see. My issues could just be down to using a VM. I tried on Ubuntu 9.10 but had problems which I documented here on 16 april. Loading the firmware worked fine but there were problems with remote control messages being logged continually as well as stability problems. The card would tune (with scan) and worked with mythtv (for a day or so) I believe that I need to load up the modules ds3000 and dvb-usb-dw2102, + add a rule to /etc/udev/rules.d and a script to /etc/udev/scripts. I didn't touch rules.d I think that I must be missing quite a lot of context, tho'. When I look at the code in dw2102.c, which seems to support the s660, the bit that downloads the firmware looks broken and if I add a default clause to the switch that does the download, the s660's missed the download process. This could be why when I do get anything out of the device it looks like I'm just getting repeated bytes (the same value repeated, different values at different times, sometimes nothing). I'm finding it non-trivial working out the call sequences of the code or devising repeatable tests. Had no problem with Ubuntu recognising the device and the correct .fw file being downloaded. There are various versions of dw2102.c from tevii, etc. I think I tried all of them. I did change the timeout on RC messages (dw2102.c?) which helped but did not cure the problem. Also tried the s2-liplianin library as well which seemed promising but also did not cure the problem. Can anyone kick me off on getting this working? I'd like to at least get to the point where scandvb can tune the device. It does look like some folk have had success in the past, but probably with totally different codebase (there are posts that refer to the teviis660 module, which I cannot find). Any pointer gratefully accepted. I'll feed back any success if I can be pointed at where to drop document it. I didn't have the knowledge (or time) to decide if the problem was in the firmware or the v4l drivers or perhaps some strange interaction with my dvb-t usb box. Exchanged some emails with tevii guys who had posted here however they appear to take the view that if it works under windows then the device is fine and offer no other solution. In the end I bought a Nova S2 PCI card which works fine but would be interested in trying to get the S660 working. paul -- 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] TechnoTrend TT-budget T-3000
Hi,
This patch adds support for TechnoTrend TT-budget T-3000
DVB-T card.
diff -r ee9826bc7106 linux/drivers/media/video/saa7134/saa7134-cards.c
--- a/linux/drivers/media/video/saa7134/saa7134-cards.c Thu Apr 29
23:31:06 2010 -0300
+++ b/linux/drivers/media/video/saa7134/saa7134-cards.c Thu May 06
21:33:14 2010 +0300
@@ -5411,6 +5411,30 @@
.gpio = 0x01fc00,
} },
},
+ [SAA7134_BOARD_TECHNOTREND_BUDGET_T3000] = {
+ .name = "TechoTrend TT-budget T-3000",
+ .tuner_type = TUNER_PHILIPS_TD1316,
+ .audio_clock= 0x00187de7,
+ .radio_type = UNSET,
+ .tuner_addr = 0x63,
+ .radio_addr = ADDR_UNSET,
+ .tda9887_conf = TDA9887_PRESENT | TDA9887_PORT1_ACTIVE,
+ .mpeg = SAA7134_MPEG_DVB,
+ .inputs = {{
+ .name = name_tv,
+ .vmux = 3,
+ .amux = TV,
+ .tv = 1,
+ }, {
+ .name = name_comp1,
+ .vmux = 0,
+ .amux = LINE2,
+ }, {
+ .name = name_svideo,
+ .vmux = 8,
+ .amux = LINE2,
+ } },
+ },
};
@@ -6568,6 +6592,12 @@
.subdevice= 0x6655,
.driver_data = SAA7134_BOARD_LEADTEK_WINFAST_DTV1000S,
}, {
+ .vendor = PCI_VENDOR_ID_PHILIPS,
+ .device = PCI_DEVICE_ID_PHILIPS_SAA7133,
+ .subvendor= 0x13c2,
+ .subdevice= 0x2804,
+ .driver_data = SAA7134_BOARD_TECHNOTREND_BUDGET_T3000,
+ }, {
/* --- boards without eeprom + subsystem ID --- */
.vendor = PCI_VENDOR_ID_PHILIPS,
.device = PCI_DEVICE_ID_PHILIPS_SAA7134,
@@ -7277,6 +7307,7 @@
case SAA7134_BOARD_VIDEOMATE_DVBT_300:
case SAA7134_BOARD_ASUS_EUROPA2_HYBRID:
case SAA7134_BOARD_ASUS_EUROPA_HYBRID:
+ case SAA7134_BOARD_TECHNOTREND_BUDGET_T3000:
{
/* The Philips EUROPA based hybrid boards have the tuner
diff -r ee9826bc7106 linux/drivers/media/video/saa7134/saa7134-dvb.c
--- a/linux/drivers/media/video/saa7134/saa7134-dvb.c Thu Apr 29
23:31:06 2010 -0300
+++ b/linux/drivers/media/video/saa7134/saa7134-dvb.c Thu May 06
21:33:14 2010 +0300
@@ -482,6 +482,18 @@
.request_firmware = philips_tda1004x_request_firmware
};
+static struct tda1004x_config technotrend_budget_t3000_config = {
+ .demod_address = 0x8,
+ .invert= 1,
+ .invert_oclk = 0,
+ .xtal_freq = TDA10046_XTAL_4M,
+ .agc_config= TDA10046_AGC_DEFAULT,
+ .if_freq = TDA10046_FREQ_3617,
+ .tuner_address = 0x63,
+ .request_firmware = philips_tda1004x_request_firmware
+};
+
+
/* --
* tda 1004x based cards with philips silicon tuner
*/
@@ -1169,6 +1181,18 @@
fe0->dvb.frontend->ops.tuner_ops.set_params =
philips_td1316_tuner_set_params;
}
break;
+ case SAA7134_BOARD_TECHNOTREND_BUDGET_T3000:
+ fe0->dvb.frontend = dvb_attach(tda10046_attach,
+ &technotrend_budget_t3000_config,
+ &dev->i2c_adap);
+ if (fe0->dvb.frontend) {
+ dev->original_demod_sleep =
fe0->dvb.frontend->ops.sleep;
+ fe0->dvb.frontend->ops.sleep =
philips_europa_demod_sleep;
+ fe0->dvb.frontend->ops.tuner_ops.init =
philips_europa_tuner_init;
+ fe0->dvb.frontend->ops.tuner_ops.sleep =
philips_europa_tuner_sleep;
+ fe0->dvb.frontend->ops.tuner_ops.set_params =
philips_td1316_tuner_set_params;
+ }
+ break;
case SAA7134_BOARD_VIDEOMATE_DVBT_200:
fe0->dvb.frontend = dvb_attach(tda10046_attach,
&philips_tu1216_61_config,
diff -r ee9826bc7106 linux/drivers/media/video/saa7134/saa7134.h
--- a/linux/drivers/media/video/saa7134/saa7134.h Thu Apr 29 23:31:06
2010 -0300
+++ b/linux/drivers/media/video/saa7134/saa7134.h Thu May 06 21:33:14
2010 +0300
@@ -302,6 +302,7 @@
#define SAA7134_BOARD_LEADTEK_WINFAST_DTV1000S 175
#define SAA7134_BOARD_BEHOLD_505RDS_MK3 176
#define SAA7134_BOARD_HAWELL_HW_404M7 177
+#define SAA7134_BOARD_TECHNOTREND_BUDGET_T3000 178
#define SAA7134_MAXBOARDS 32
#define SAA7134_INPUT_MAX 8
Signed-off-by: Vadim Catana
Best regards,
Vadim Catana
diff -r ee9826bc7106 linux/drivers/media/video/saa7134/saa7134-cards.c
--- a/linux/d
Re: cx88 pci_abort errors (Hauppauge WinTV Nova-HD-S2)
On 06/05/2010 16:01, Thierry LELEGARD wrote: I recently added a Hauppauge WinTV Nova-HD-S2 into a Linux system. I experience frequent packet loss and pci_abort errors. Each time my application detects packet loss (continuity errors actually), I get the following messages in dmesg: cx88[0]: irq mpeg [0x8] pci_abort* cx88[0]/2-mpeg: general errors: 0x0008 Such problems occur every few seconds. I use firmware file dvb-fe-cx24116.fw version 1.26.90.0. Since the IRQ was shared with the nVidia card and a Dektec modulator, I swapped some PCI boards. The IRQ is still shared but with another Tuner I do not use when using the S2 tuner. After swapping the PCI boards, the errors occur less frequently but still happen. Assuming that the pci_abort was due to an interrupted DMA transfer, I tried to increase the PCI latency timer of the device to 248 but this did not change anything (setpci -s 05:05 latency_timer=f8). I use the tuner with a custom application which reads the complete Transport stream. This application had worked for years using DVB-T and DVB-S tuners. I tried to reduce the application read buffer input size and it did not change anything at all. Note that my application still uses the V3 API, not the S2API. But, using DVB-S transponders, it works (except the pci_abort errors). I disabled the serial port, the parallel port and the PS/2 ports in the BIOS. It did not change anything either. Does anyone have an idea, please? Thanks a lot in advance for any help. -Thierry I have the board working in a Ubuntu 9.10 system, log below shows no pci errors: Apr 21 18:32:11 antec300 kernel: [ 16.576416] cx88/2: cx2388x MPEG-TS Driver Manager version 0.0.7 loaded Apr 21 18:32:11 antec300 kernel: [ 16.576711] cx88[0]: subsystem: 0070:6906, board: Hauppauge WinTV-HVR4000(Lite) DVB-S/S2 [card=69,autodetected], frontend(s): 1 Apr 21 18:32:11 antec300 kernel: [ 16.576714] cx88[0]: TV tuner type -1, Radio tuner type -1 Apr 21 18:32:11 antec300 kernel: [ 16.583565] cx88/0: cx2388x v4l2 driver version 0.0.7 loaded Apr 21 18:32:11 antec300 kernel: [ 16.586270] cx2388x alsa driver version 0.0.7 loaded Apr 21 18:32:11 antec300 kernel: [ 16.605679] EXT4-fs (sda1): internal journal on sda1:8 Apr 21 18:32:11 antec300 kernel: [ 16.755834] EXT4-fs (sdc1): barriers enabled Apr 21 18:32:11 antec300 kernel: [ 16.757791] kjournald2 starting: pid 956, dev sdc1:8, commit interval 5 seconds Apr 21 18:32:11 antec300 kernel: [ 16.763057] EXT4-fs (sdc1): internal journal on sdc1:8 Apr 21 18:32:11 antec300 kernel: [ 16.763061] EXT4-fs (sdc1): delayed allocation enabled Apr 21 18:32:11 antec300 kernel: [ 16.763063] EXT4-fs: file extents enabled Apr 21 18:32:11 antec300 kernel: [ 16.789147] EXT4-fs: mballoc enabled Apr 21 18:32:11 antec300 kernel: [ 16.789163] EXT4-fs (sdc1): mounted filesystem with ordered data mode Apr 21 18:32:11 antec300 kernel: [ 16.795868] tveeprom 2-0050: Hauppauge model 69100, rev B4C3, serial# 7084390 Apr 21 18:32:11 antec300 kernel: [ 16.795871] tveeprom 2-0050: MAC address is 00:0d:fe:6c:19:66 Apr 21 18:32:11 antec300 kernel: [ 16.795874] tveeprom 2-0050: tuner model is Conexant CX24118A (idx 123, type 4) Apr 21 18:32:11 antec300 kernel: [ 16.795876] tveeprom 2-0050: TV standards ATSC/DVB Digital (eeprom 0x80) Apr 21 18:32:11 antec300 kernel: [ 16.795878] tveeprom 2-0050: audio processor is None (idx 0) Apr 21 18:32:11 antec300 kernel: [ 16.795880] tveeprom 2-0050: decoder processor is CX880 (idx 20) Apr 21 18:32:11 antec300 kernel: [ 16.795882] tveeprom 2-0050: has no radio, has IR receiver, has no IR transmitter Apr 21 18:32:11 antec300 kernel: [ 16.795884] cx88[0]: hauppauge eeprom: model=69100 Apr 21 18:32:11 antec300 kernel: [ 16.798457] input: cx88 IR (Hauppauge WinTV-HVR400 as /devices/pci:00/:00:1e.0/:06:02.2/input/input6 Apr 21 18:32:11 antec300 kernel: [ 16.798488] cx88[0]/2: cx2388x 8802 Driver Manager Apr 21 18:32:11 antec300 kernel: [ 16.798500] cx88-mpeg driver manager :06:02.2: PCI INT A -> GSI 19 (level, low) -> IRQ 19 Apr 21 18:32:11 antec300 kernel: [ 16.798506] cx88[0]/2: found at :06:02.2, rev: 5, irq: 19, latency: 32, mmio: 0xf800 Apr 21 18:32:11 antec300 kernel: [ 16.798510] IRQ 19/cx88[0]: IRQF_DISABLED is not guaranteed on shared IRQs Apr 21 18:32:11 antec300 kernel: [ 16.799143] cx8800 :06:02.0: PCI INT A -> GSI 19 (level, low) -> IRQ 19 Apr 21 18:32:11 antec300 kernel: [ 16.799151] cx88[0]/0: found at :06:02.0, rev: 5, irq: 19, latency: 32, mmio: 0xfa00 Apr 21 18:32:11 antec300 kernel: [ 16.799158] IRQ 19/cx88[0]: IRQF_DISABLED is not guaranteed on shared IRQs Apr 21 18:32:11 antec300 kernel: [ 16.799193] cx88[0]/0: registered device video0 [v4l2] Apr 21 18:32:11 antec300 kernel: [ 16.799210] cx88[0]/0: registered device vbi0 Apr 21 18:32:11 antec300 kernel: [ 16.802095] cx88_audio :06:02.1: PCI INT A -> GSI 19 (level, low) -> IRQ 1
Re: Problem with gspca and zc3xx
On Thu, 06 May 2010 15:09:33 -0300 Mauro Carvalho Chehab wrote: > > I found the problem. Autogain don't work well if brightness is de > > default value(128). if brightness is less(64) autogain work well. > > There is a problem when setting the brightness. It is safe to > > remove the brightness control? Patch attached. > > > > Jose Alberto > > This patch doesn't apply anymore. I'm not sure if the issue were > fixed upstream. If not, please re-base your patch against my git tree > and send it again. > > patching file drivers/media/video/gspca/zc3xx.c > Hunk #1 succeeded at 6086 with fuzz 1 (offset 45 lines). > Hunk #2 FAILED at 6882. > 1 out of 2 hunks FAILED -- saving rejects to file > drivers/media/video/gspca/zc3xx.c.rej > >>> Patch patches/lmml_72895_problem_with_gspca_and_zc3xx.patch > >>> doesn't apply Jose's patch is not needed anymore. I completely removed the brightness control as it was done: it did not work for any zc3xx webcam. The git change is bdd13e1bf3ada06bb9ccd04f5f65f7912eff72af. Cheers. -- Ken ar c'hentañ | ** Breizh ha Linux atav! ** Jef | http://moinejf.free.fr/ -- 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 2.6.22 and up: ERRORS, 2.6.16-2.6.21: 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:Thu May 6 19:00:24 CEST 2010 path:http://www.linuxtv.org/hg/v4l-dvb changeset: 14644:4a8d6d981f07 git master: f6760aa024199cfbce564311dc4bc4d47b6fb349 git media-master: fe6abd62358baa849e3ac5940fd47f25015b49fe gcc version: i686-linux-gcc (GCC) 4.4.3 host hardware:x86_64 host os: 2.6.32.5 linux-2.6.32.6-armv5: ERRORS linux-2.6.33-armv5: ERRORS linux-2.6.34-rc1-armv5: ERRORS linux-2.6.32.6-armv5-davinci: ERRORS linux-2.6.33-armv5-davinci: ERRORS linux-2.6.34-rc1-armv5-davinci: ERRORS linux-2.6.32.6-armv5-ixp: ERRORS linux-2.6.33-armv5-ixp: ERRORS linux-2.6.34-rc1-armv5-ixp: ERRORS linux-2.6.32.6-armv5-omap2: ERRORS linux-2.6.33-armv5-omap2: ERRORS linux-2.6.34-rc1-armv5-omap2: ERRORS linux-2.6.22.19-i686: ERRORS linux-2.6.23.17-i686: ERRORS linux-2.6.24.7-i686: ERRORS linux-2.6.25.20-i686: ERRORS linux-2.6.26.8-i686: ERRORS linux-2.6.27.44-i686: ERRORS linux-2.6.28.10-i686: ERRORS linux-2.6.29.1-i686: ERRORS linux-2.6.30.10-i686: ERRORS linux-2.6.31.12-i686: ERRORS linux-2.6.32.6-i686: ERRORS linux-2.6.33-i686: OK linux-2.6.34-rc1-i686: WARNINGS linux-2.6.32.6-m32r: ERRORS linux-2.6.33-m32r: ERRORS linux-2.6.34-rc1-m32r: ERRORS linux-2.6.32.6-mips: ERRORS linux-2.6.33-mips: ERRORS linux-2.6.34-rc1-mips: ERRORS linux-2.6.32.6-powerpc64: ERRORS linux-2.6.33-powerpc64: ERRORS linux-2.6.34-rc1-powerpc64: ERRORS linux-2.6.22.19-x86_64: ERRORS linux-2.6.23.17-x86_64: ERRORS linux-2.6.24.7-x86_64: ERRORS linux-2.6.25.20-x86_64: ERRORS linux-2.6.26.8-x86_64: ERRORS linux-2.6.27.44-x86_64: ERRORS linux-2.6.28.10-x86_64: ERRORS linux-2.6.29.1-x86_64: ERRORS linux-2.6.30.10-x86_64: ERRORS linux-2.6.31.12-x86_64: ERRORS linux-2.6.32.6-x86_64: ERRORS linux-2.6.33-x86_64: OK linux-2.6.34-rc1-x86_64: WARNINGS 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: OK linux-git-powerpc64: OK linux-git-x86_64: WARNINGS spec: ERRORS spec-git: OK sparse: ERRORS linux-2.6.16.62-i686: ERRORS linux-2.6.17.14-i686: ERRORS linux-2.6.18.8-i686: ERRORS linux-2.6.19.7-i686: ERRORS linux-2.6.20.21-i686: ERRORS linux-2.6.21.7-i686: ERRORS linux-2.6.16.62-x86_64: ERRORS linux-2.6.17.14-x86_64: ERRORS linux-2.6.18.8-x86_64: ERRORS linux-2.6.19.7-x86_64: ERRORS linux-2.6.20.21-x86_64: ERRORS linux-2.6.21.7-x86_64: ERRORS Detailed results are available here: http://www.xs4all.nl/~hverkuil/logs/Thursday.log Full logs are available here: http://www.xs4all.nl/~hverkuil/logs/Thursday.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: [PATCH 1/3] add feedback LED control
Jean-Francois Moine wrote:
> On Sun, 28 Feb 2010 20:38:00 +0100
> Németh Márton wrote:
>
>> With a bitfield on and off state can be specified. What about the
>> "auto" mode? Should two bits grouped together to have auto, on and
>> off state? Is there already a similar control?
>>
>> Is the brightness of the background light LEDs adjustable or are they
>> just on/off? If yes, then maybe the feedback LEDs and the background
>> light LEDs should be treated as different kind.
>
> OK. My idea about switching the LEDs by v4l2 controls was not good. So,
> forget about it.
>
> Instead, some job of the led class may be done in the gspca main,
> especially register/unregister.
>
> I propose to add a LED description in the gspca structure (level
> 'struct cam'). There would be 'nleds' for the number of LEDS and
> 'leds', a pointer to an array of:
>
> struct gspca_led {
> struct led_classdev led_cdev;
> char led_name[32];
> struct led_trigger led_trigger;
> char trigger_name[32];
> };
>
> (this array should be in the subdriver structure - I don't show the
> #ifdef's)
>
> Then, this would work as:
>
> - on probe, in the 'config' function of the subdriver, this one
> initializes the led and trigger fields. The 'led_cdev.name' and
> 'led_trigger.name' should point to a sprintf format with one
> argument: the video device number (ex: "video%d::toplight").
>
> - then, at the end of gspca_dev_probe(), the gspca main creates the real
> names of the leds and triggers, and does the register job.
>
> - all led/trigger events are treated by the subdriver, normally by a
> workqueue. This one must not be the system workqueue.
>
> - on disconnection, the gspca main unregisters the leds and triggers
> without calling the subdriver. In the workqueue, the disconnection
> can be simply handled testing the flag 'present' after each subsystem
> call.
>
> Cheers.
>
The feedback LED patch series doesn't apply anymore.
patching file Documentation/DocBook/v4l/controls.xml
Hunk #1 succeeded at 324 (offset 13 lines).
patching file Documentation/DocBook/v4l/videodev2.h.xml
Hunk #1 succeeded at 1031 (offset 7 lines).
patching file drivers/media/video/v4l2-common.c
Hunk #1 succeeded at 358 (offset 9 lines).
Hunk #3 FAILED at 442.
Hunk #4 succeeded at 598 (offset 14 lines).
1 out of 4 hunks FAILED -- saving rejects to file
drivers/media/video/v4l2-common.c.rej
patching file include/linux/videodev2.h
Hunk #1 FAILED at 1030.
1 out of 1 hunk FAILED -- saving rejects to file include/linux/videodev2.h.rej
>>> Patch patches/lmml_82773_1_3_add_feedback_led_control.patch doesn't apply
As the original approach weren't accepted, I'm dropping those patches from
my queue. Please re-submit after having some agreement about that.
--
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: Problem with gspca and zc3xx
Jose Alberto Reguero wrote: > El Miércoles, 13 de Enero de 2010, Jose Alberto Reguero escribió: >> El Martes, 12 de Enero de 2010, Jose Alberto Reguero escribió: >>> El Martes, 12 de Enero de 2010, Jean-Francois Moine escribió: On Mon, 11 Jan 2010 15:49:55 +0100 Jose Alberto Reguero wrote: > I take another image with 640x480 and the bad bottom lines are 8. The > right side look right this time. The good sizes are: > 320x240->320x232 > 640x480->640x472 Hi Jose Alberto and Hans, Hans, I modified a bit your patch to handle the 2 resolutions (also, the problem with pas202b does not exist anymore). May you sign or ack it? Jose Alberto, the attached patch is to be applied to the last version of the gspca in my test repository at LinuxTv.org http://linuxtv.org/hg/~jfrancois/gspca May you try it? Regards. >>> The patch works well. >>> There is another problem. When autogain is on(default), the image is bad. >>> It is possible to put autogain off by default? >>> >>> Thanks. >>> Jose Alberto >> Autogain works well again. I can't reproduce the problem. Perhaps the debug >> messages. (Now I have debug off). >> >> Thanks. >> Jose Alberto > > I found the problem. Autogain don't work well if brightness is de default > value(128). if brightness is less(64) autogain work well. There is a problem > when setting the brightness. It is safe to remove the brightness control? > Patch attached. > > Jose Alberto This patch doesn't apply anymore. I'm not sure if the issue were fixed upstream. If not, please re-base your patch against my git tree and send it again. patching file drivers/media/video/gspca/zc3xx.c Hunk #1 succeeded at 6086 with fuzz 1 (offset 45 lines). Hunk #2 FAILED at 6882. 1 out of 2 hunks FAILED -- saving rejects to file drivers/media/video/gspca/zc3xx.c.rej >>> Patch patches/lmml_72895_problem_with_gspca_and_zc3xx.patch doesn't apply -- 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: this is a test mail
Thanks. Mauro. It's there. Hope the patch will be accepted. Mauro Carvalho Chehab wrote: Ang Way Chuang wrote: That's weird. You can receive my email, yet I don't receive my email from the mailing list. Does that mean my patch went through as well? Just check at patchwork.kernel.org. If you sent a patch correctly (e. g., in plain text only, no html, no line wrap), your patches should be there. Jed wrote: Try sending via your ISP's SMTP host instead of Google's. I had issues with this list until I made the switch. On 7/05/10 12:51 AM, Ang Way Chuang wrote: Please ignore this email. why can't i get my email through linux media mailing list when i can receive it? -- 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 -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: this is a test mail
Ang Way Chuang wrote: > That's weird. You can receive my email, yet I don't receive my email > from the mailing list. Does that mean my patch went through as well? Just check at patchwork.kernel.org. If you sent a patch correctly (e. g., in plain text only, no html, no line wrap), your patches should be there. > > Jed wrote: >> Try sending via your ISP's SMTP host instead of Google's. >> I had issues with this list until I made the switch. >> >> On 7/05/10 12:51 AM, Ang Way Chuang wrote: >>> Please ignore this email. why can't i get my email through linux media >>> mailing list when i can receive it? >>> -- >>> 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 >> > > -- > 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 -- 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
cx88 pci_abort errors (Hauppauge WinTV Nova-HD-S2)
Hello, Does anyone experience pci_abort errors with the cx88 driver? Many thanks -Thierry De : linux-media-ow...@vger.kernel.org [mailto:linux-media-ow...@vger.kernel.org] De la part de Thierry LELEGARD Envoyé : mardi 4 mai 2010 16:48 À : linux-...@linuxtv.org; linux-media@vger.kernel.org Objet : [linux-dvb] pci_abort errors with Hauppauge WinTV Nova-HD-S2 Hello, I recently added a Hauppauge WinTV Nova-HD-S2 into a Linux system. I experience frequent packet loss and pci_abort errors. Each time my application detects packet loss (continuity errors actually), I get the following messages in dmesg: cx88[0]: irq mpeg [0x8] pci_abort* cx88[0]/2-mpeg: general errors: 0x0008 Such problems occur every few seconds. I use firmware file dvb-fe-cx24116.fw version 1.26.90.0. Since the IRQ was shared with the nVidia card and a Dektec modulator, I swapped some PCI boards. The IRQ is still shared but with another Tuner I do not use when using the S2 tuner. After swapping the PCI boards, the errors occur less frequently but still happen. Assuming that the pci_abort was due to an interrupted DMA transfer, I tried to increase the PCI latency timer of the device to 248 but this did not change anything (setpci -s 05:05 latency_timer=f8). I use the tuner with a custom application which reads the complete Transport stream. This application had worked for years using DVB-T and DVB-S tuners. I tried to reduce the application read buffer input size and it did not change anything at all. Note that my application still uses the V3 API, not the S2API. But, using DVB-S transponders, it works (except the pci_abort errors). I disabled the serial port, the parallel port and the PS/2 ports in the BIOS. It did not change anything either. Does anyone have an idea, please? Thanks a lot in advance for any help. -Thierry PS: some additional information: # lspci -v -s 05:05 05:05.0 Multimedia video controller: Conexant Systems, Inc. CX23880/1/2/3 PCI Video and Audio Decoder (rev 05) Subsystem: Hauppauge computer works Inc. Device 6906 Flags: bus master, medium devsel, latency 248, IRQ 17 Memory at f500 (32-bit, non-prefetchable) [size=16M] Capabilities: [44] Vital Product Data Capabilities: [4c] Power Management version 2 Kernel driver in use: cx8800 Kernel modules: cx8800 05:05.1 Multimedia controller: Conexant Systems, Inc. CX23880/1/2/3 PCI Video and Audio Decoder [Audio Port] (rev 05) Subsystem: Hauppauge computer works Inc. Device 6906 Flags: bus master, medium devsel, latency 248, IRQ 17 Memory at f600 (32-bit, non-prefetchable) [size=16M] Capabilities: [4c] Power Management version 2 Kernel driver in use: cx88_audio Kernel modules: cx88-alsa 05:05.2 Multimedia controller: Conexant Systems, Inc. CX23880/1/2/3 PCI Video and Audio Decoder [MPEG Port] (rev 05) Subsystem: Hauppauge computer works Inc. Device 6906 Flags: bus master, medium devsel, latency 248, IRQ 17 Memory at f700 (32-bit, non-prefetchable) [size=16M] Capabilities: [4c] Power Management version 2 Kernel driver in use: cx88-mpeg driver manager Kernel modules: cx8802 05:05.4 Multimedia controller: Conexant Systems, Inc. CX23880/1/2/3 PCI Video and Audio Decoder [IR Port] (rev 05) Subsystem: Hauppauge computer works Inc. Device 6906 Flags: bus master, medium devsel, latency 248, IRQ 10 Memory at f800 (32-bit, non-prefetchable) [size=16M] Capabilities: [4c] Power Management version 2 # cat /proc/interrupts CPU0 CPU1 0:296 4 IO-APIC-edge timer 1: 1 2 IO-APIC-edge i8042 8: 1 0 IO-APIC-edge rtc0 9: 0 0 IO-APIC-fasteoi acpi 16:279 122104 IO-APIC-fasteoi uhci_hcd:usb4, uhci_hcd:usb10, HDA Intel, Dta1xx, nvidia 17: 1863 507353 IO-APIC-fasteoi uhci_hcd:usb5, uhci_hcd:usb8, uhci_hcd:usb11, cx88[0], cx88[0], cx88[0] 18: 130224 8533 IO-APIC-fasteoi ehci_hcd:usb3, uhci_hcd:usb9 22: 0 0 IO-APIC-fasteoi ehci_hcd:usb1, uhci_hcd:usb6 23: 170156246 IO-APIC-fasteoi ehci_hcd:usb2, uhci_hcd:usb7 28: 57235 4517 PCI-MSI-edge ahci 29: 69 15965 PCI-MSI-edge eth0 NMI: 0 0 Non-maskable interrupts LOC:25290232281329 Local timer interrupts SPU: 0 0 Spurious interrupts PMI: 0 0 Performance monitoring interrupts PND: 0 0 Performance pending work RES: 42023 29529 Rescheduling interrupts CAL:123994 Function call interrupts TLB: 150508 136321 TLB shootdowns TRM: 0 0 Thermal event interrupts THR: 0 0 Threshold APIC interrupts MCE: 0 0
Re: this is a test mail
Oops, my bad. Jed wrote: Anyone know why we're getting 2 emails every time one sends only to linux-media@vger.kernel.org ? It's a tincy bit irritating, not that I'm complaining ;) On 7/05/10 12:57 AM, Jed wrote: Try sending via your ISP's SMTP host instead of Google's. I had issues with this list until I made the switch. On 7/05/10 12:51 AM, Ang Way Chuang wrote: Please ignore this email. why can't i get my email through linux media mailing list when i can receive it? -- 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 -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: this is a test mail
Anyone know why we're getting 2 emails every time one sends only to linux-media@vger.kernel.org ? It's a tincy bit irritating, not that I'm complaining ;) On 7/05/10 12:57 AM, Jed wrote: Try sending via your ISP's SMTP host instead of Google's. I had issues with this list until I made the switch. On 7/05/10 12:51 AM, Ang Way Chuang wrote: Please ignore this email. why can't i get my email through linux media mailing list when i can receive it? -- 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 -- 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: this is a test mail
That's weird. You can receive my email, yet I don't receive my email from the mailing list. Does that mean my patch went through as well? Jed wrote: Try sending via your ISP's SMTP host instead of Google's. I had issues with this list until I made the switch. On 7/05/10 12:51 AM, Ang Way Chuang wrote: Please ignore this email. why can't i get my email through linux media mailing list when i can receive it? -- 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 -- 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: this is a test mail
Try sending via your ISP's SMTP host instead of Google's. I had issues with this list until I made the switch. On 7/05/10 12:51 AM, Ang Way Chuang wrote: Please ignore this email. why can't i get my email through linux media mailing list when i can receive it? -- 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
[PATCH] dvb-core: Fix ULE decapsulation bug when less than 4 bytes of ULE SNDU is packed into the remaining bytes of a MPEG2-TS frame
ULE (Unidirectional Lightweight Encapsulation RFC 4326) decapsulation
code has a bug that incorrectly treats ULE SNDU packed into the
remaining 2 or 3 bytes of a MPEG2-TS frame as having invalid pointer
field on the subsequent MPEG2-TS frame.
This patch was generated and tested against v2.6.34-rc6. I suspect
that this bug was introduced in kernel version 2.6.15, but had not
verified it.
Care has been taken not to introduce more bug by fixing this bug, but
please scrutinize the code because I always produces buggy code.
Signed-off-by: Ang Way Chuang
---
diff --git a/drivers/media/dvb/dvb-core/dvb_net.c
b/drivers/media/dvb/dvb-core/dvb_net.c
index 441c064..35a4afb 100644
--- a/drivers/media/dvb/dvb-core/dvb_net.c
+++ b/drivers/media/dvb/dvb-core/dvb_net.c
@@ -458,8 +458,9 @@ static void dvb_net_ule( struct net_device *dev, const u8
*buf, size_t buf_len )
"field: %u.\n",
priv->ts_count, *from_where);
/* Drop partly decoded SNDU,
reset state, resync on PUSI. */
- if (priv->ule_skb) {
- dev_kfree_skb(
priv->ule_skb );
+ if (priv->ule_skb ||
priv->ule_sndu_remain) {
+ if (priv->ule_skb)
+ dev_kfree_skb(
priv->ule_skb );
dev->stats.rx_errors++;
dev->stats.rx_frame_errors++;
}
@@ -534,6 +535,7 @@ static void dvb_net_ule( struct net_device *dev, const u8
*buf, size_t buf_len )
from_where += 2;
}
+ priv->ule_sndu_remain = priv->ule_sndu_len + 2;
/*
* State of current TS:
* ts_remain (remaining bytes in the current TS cell)
@@ -543,6 +545,7 @@ static void dvb_net_ule( struct net_device *dev, const u8
*buf, size_t buf_len )
*/
switch (ts_remain) {
case 1:
+ priv->ule_sndu_remain--;
priv->ule_sndu_type = from_where[0] <<
8;
priv->ule_sndu_type_1 = 1; /* first
byte of ule_type is set. */
ts_remain -= 1; from_where += 1;
@@ -556,6 +559,7 @@ static void dvb_net_ule( struct net_device *dev, const u8
*buf, size_t buf_len )
default: /* complete ULE header is present in
current TS. */
/* Extract ULE type field. */
if (priv->ule_sndu_type_1) {
+ priv->ule_sndu_type_1 = 0;
priv->ule_sndu_type |=
from_where[0];
from_where += 1; /* points to
payload start. */
ts_remain -= 1;
--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [videobuf] Query: Condition bytesize limit in videobuf_reqbufs -> buf_setup() call?
Hi Mauro,
On Thursday 06 May 2010 15:23:10 Mauro Carvalho Chehab wrote:
> Laurent Pinchart wrote:
> > On Thursday 06 May 2010 14:38:36 Mauro Carvalho Chehab wrote:
> >> Laurent Pinchart wrote:
> >>> On Thursday 06 May 2010 01:29:54 Aguirre, Sergio wrote:
> > -Original Message-
> > From: Mauro Carvalho Chehab [mailto:mche...@redhat.com]
> > Sent: Wednesday, May 05, 2010 6:24 PM
> > To: Aguirre, Sergio
> > Cc: linux-media@vger.kernel.org
> > Subject: Re: [videobuf] Query: Condition bytesize limit in
> > videobuf_reqbufs -> buf_setup() call?
[snip]
> > I don't see any problem on propagating the memory type to
> > buffer_setup, if this is really needed. Yet, I can't see why you
> > would restrict the buffer size to 32 MB on one case, and not
> > restrict the size at all with non-MMAP types.
>
> Ok, my reason for doing that is because I thought that there should be
> a memory limit in whichever place you're doing the buffer
> allocations.
>
> MMAP is allocating buffers in kernel, so kernel should provide a
> memory restriction, if applies.
>
> USERPTR is allocating buffers in userspace, so userspace should
> provide a memory restriction, if applies.
> >>>
> >>> I agree with the intend here, but not with the current implementation
> >>> which has a hardcoded arbitrary limit. Do you think it would be
> >>> possible to compute a meaningful default limit in the V4L2 core, with
> >>> a way for userspace to modify it (with root privileges of course) ?
> >>
> >> On almost all drivers, the limit is not arbitrary. It is a reasonable
> >> number of buffers (like 16 buffers). A limit in terms of the number of
> >> buffers is meaningful for V4L2 API, and also, has a "physical meaning":
> >> considering that almost all drivers that use videobuf can do at maximum
> >> 30 fps, 16 buffers mean that the maximum delay that the driver will
> >> apply to the stream is 533 ms.
> >>
> >> Some drivers even provide a modprobe parameter to allow changing this
> >> limit (for example, bttv allows changing it up to 32 buffers), but only
> >> during module load time. I can't foresee any use case where this
> >> maximum limit would need to be dynamically adjusted. Root can always
> >> change it by removing and re-inserting the module with a new maximum
> >> size.
> >
> > I wasn't talking about the limit on the number of buffers, but on the
> > amount of memory. That's what Sergio was mentioning, and that's what is
> > done in the OMAP3 ISP driver.
>
> The memory consumption is basically dictated by the maximum size of an
> image (resolution x bpp / 8) and the number of buffers. An arbitrary value
> in terms of megabytes is meaningless: it is just a random number above
> some reasonable limit.
>
> The proper way to limit memory is to do something like:
>
> #define MAX_HRES 1920
> #define MAX_VRES 1650
> #define MAX_DEPTH 3
> #define MAX_BUFS 4
>
> #define MAX_MEMSIZE (MAX_HRES * MAX_VRES * MAX_DEPTH * MAX_BUFS)
>
> buf_setup(...)
> {
> if (size > MAX_MEMSIZE)
> fix_it_by_reducing_number_of_buffers();
> }
That's what we do. The limit is this not a number of buffers, but a memory
limit. You an allocate more than 4 buffers in small resolutions. This is still
a somewhat arbitrary limit. The OMAP3 ISP driver has 7 video nodes (a 8th one
is possible). If we let userspace application allocate 3 buffers of the
maximum size (think about 4096x4096 and 2 bytes per pixel, could be even
higher for some of the blocks), the total is 256MB. That's quite a lot. A
device-global memory limit might need to be enforced.
--
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
this is a test mail
Please ignore this email. why can't i get my email through linux media mailing list when i can receive it? -- 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 v2 2/10] V4L2 patches for Intel Moorestown Camera Imaging Drivers - part 1
Hi Hans,
Thanks you time to review this. if you have time to review it on this weekend,
it is good for us. Actually, we have finished your comment about the sub device
drivers (sensors, lens and flash) and we are going to submit it to the mailing
list for review again. But for ISP driver, we are still pending for review
since we received few comment, so far.
BRs
Xiaolin
-Original Message-
From: Hans Verkuil [mailto:hverk...@xs4all.nl]
Sent: Thursday, May 06, 2010 2:40 PM
To: Zhang, Xiaolin
Cc: linux-media@vger.kernel.org; Zhu, Daniel; Yu, Jinlu; Wang, Wen W; Huang,
Kai; Hu, Gang A; Ba, Zheng
Subject: Re: [PATCH v2 2/10] V4L2 patches for Intel Moorestown Camera Imaging
Drivers - part 1
On Monday 29 March 2010 08:40:50 Hans Verkuil wrote:
> Hi Xiaolin,
>
> On Sunday 28 March 2010 16:42:30 Zhang, Xiaolin wrote:
> > From 1c18c41be33246e4b766d0e95e28a72dded87475 Mon Sep 17 00:00:00 2001
> > From: Xiaolin Zhang
> > Date: Sun, 28 Mar 2010 21:31:24 +0800
> > Subject: [PATCH 2/10] This patch is second part of intel moorestown isp
> > driver and c files collection which is v4l2 implementation.
> >
>
>
>
> > +struct videobuf_dma_contig_memory {
> > + u32 magic;
> > + void *vaddr;
> > + dma_addr_t dma_handle;
> > + unsigned long size;
> > + int is_userptr;
> > +};
> > +
> > +#define MAGIC_DC_MEM 0x0733ac61
> > +#define MAGIC_CHECK(is, should)
> > \
> > + if (unlikely((is) != (should))) {
> > \
> > + pr_err("magic mismatch: %x expected %x\n", (is), (should));
> > \
> > + BUG();
> > \
> > + }
>
> I will do a more in-depth review in a few days.
I realize that I never got round to this. You have to remind me if you don't
see a follow-up within a week! These things tend to get buried otherwise.
I will try to review this this weekend. Let me know if you prefer me to wait
for the next patch series incorporating the comments already made by others.
Regards,
Hans
> However, I did notice that
> you added your own dma_contig implementation. What were the reasons for doing
> this? I've CC-ed Pawel since he will be interested in this as well.
>
> Another question that came up is: what is 'marvin'? It's clearly a codename,
> but a codename for what? This should be documented at the top of some source
> or header. Apologies if it is already documented, I didn't read everything
> yet.
>
> A final point I noticed: don't cast away a function result:
>
> (void)ci_isp_set_bp_detection(NULL);
>
> No need for (void). The gcc compiler won't warn about this unless the function
> is annotated with __must_check__.
>
> Regards,
>
> Hans
>
>
--
Hans Verkuil - video4linux developer - sponsored by TANDBERG, part of Cisco
--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH] tm6000: README - add vbi
From: Stefan Ringel Signed-off-by: Stefan Ringel --- drivers/staging/tm6000/README |1 + 1 files changed, 1 insertions(+), 0 deletions(-) diff --git a/drivers/staging/tm6000/README b/drivers/staging/tm6000/README index 078e803..c340ebc 100644 --- a/drivers/staging/tm6000/README +++ b/drivers/staging/tm6000/README @@ -4,6 +4,7 @@ Todo: URB control transfers - Properly add the locks at tm6000-video - Add audio support + - Add vbi support - Add IR support - Do several cleanups - I think that frame1/frame0 are inverted. This causes a funny effect at the image. -- 1.7.0.3 -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 3/3] mx25: add support for the CSI device
Signed-off-by: Baruch Siach
---
arch/arm/mach-mx25/clock.c| 14 --
arch/arm/mach-mx25/devices.c | 22 ++
arch/arm/mach-mx25/devices.h |1 +
arch/arm/plat-mxc/include/mach/mx25.h |2 ++
4 files changed, 37 insertions(+), 2 deletions(-)
diff --git a/arch/arm/mach-mx25/clock.c b/arch/arm/mach-mx25/clock.c
index 1550149..7a98d18 100644
--- a/arch/arm/mach-mx25/clock.c
+++ b/arch/arm/mach-mx25/clock.c
@@ -129,6 +129,11 @@ static unsigned long get_rate_lcdc(struct clk *clk)
return get_rate_per(7);
}
+static unsigned long get_rate_csi(struct clk *clk)
+{
+ return get_rate_per(0);
+}
+
static unsigned long get_rate_otg(struct clk *clk)
{
return 4800; /* FIXME */
@@ -174,6 +179,8 @@ DEFINE_CLOCK(cspi3_clk, 0, CCM_CGCR1, 7, get_rate_ipg,
NULL, NULL);
DEFINE_CLOCK(fec_ahb_clk, 0, CCM_CGCR0, 23, NULL, NULL, NULL);
DEFINE_CLOCK(lcdc_ahb_clk, 0, CCM_CGCR0, 24, NULL, NULL, NULL);
DEFINE_CLOCK(lcdc_per_clk, 0, CCM_CGCR0, 7, NULL, NULL, &lcdc_ahb_clk);
+DEFINE_CLOCK(csi_ahb_clk, 0, CCM_CGCR0, 18, get_rate_csi, NULL, NULL);
+DEFINE_CLOCK(csi_per_clk, 0, CCM_CGCR0, 0, get_rate_csi, NULL, &csi_ahb_clk);
DEFINE_CLOCK(uart1_clk, 0, CCM_CGCR2, 14, get_rate_uart, NULL, &uart_per_clk);
DEFINE_CLOCK(uart2_clk, 0, CCM_CGCR2, 15, get_rate_uart, NULL, &uart_per_clk);
DEFINE_CLOCK(uart3_clk, 0, CCM_CGCR2, 16, get_rate_uart, NULL, &uart_per_clk);
@@ -191,6 +198,7 @@ DEFINE_CLOCK(i2c_clk,0, CCM_CGCR0, 6,
get_rate_i2c, NULL, NULL);
DEFINE_CLOCK(fec_clk, 0, CCM_CGCR1, 15, get_rate_ipg, NULL, &fec_ahb_clk);
DEFINE_CLOCK(dryice_clk, 0, CCM_CGCR1, 8, get_rate_ipg, NULL, NULL);
DEFINE_CLOCK(lcdc_clk, 0, CCM_CGCR1, 29, get_rate_lcdc, NULL, &lcdc_per_clk);
+DEFINE_CLOCK(csi_clk,0, CCM_CGCR1, 4, get_rate_csi, NULL, &csi_per_clk);
#define _REGISTER_CLOCK(d, n, c) \
{ \
@@ -225,6 +233,7 @@ static struct clk_lookup lookups[] = {
_REGISTER_CLOCK("fec.0", NULL, fec_clk)
_REGISTER_CLOCK("imxdi_rtc.0", NULL, dryice_clk)
_REGISTER_CLOCK("imx-fb.0", NULL, lcdc_clk)
+ _REGISTER_CLOCK("mx2-camera.0", NULL, csi_clk)
};
int __init mx25_clocks_init(void)
@@ -239,8 +248,9 @@ int __init mx25_clocks_init(void)
__raw_writel((0xf << 16) | (3 << 26), CRM_BASE + CCM_CGCR1);
__raw_writel((1 << 5), CRM_BASE + CCM_CGCR2);
- /* Clock source for lcdc is upll */
- __raw_writel(__raw_readl(CRM_BASE+0x64) | (1 << 7), CRM_BASE + 0x64);
+ /* Clock source for lcdc and csi is upll */
+ __raw_writel(__raw_readl(CRM_BASE+0x64) | (1 << 7) | (1 << 0),
+ CRM_BASE + 0x64);
mxc_timer_init(&gpt_clk, MX25_IO_ADDRESS(MX25_GPT1_BASE_ADDR), 54);
diff --git a/arch/arm/mach-mx25/devices.c b/arch/arm/mach-mx25/devices.c
index 3f4b8a0..bc6d189 100644
--- a/arch/arm/mach-mx25/devices.c
+++ b/arch/arm/mach-mx25/devices.c
@@ -500,3 +500,25 @@ struct platform_device mx25_fb_device = {
.coherent_dma_mask = 0x,
},
};
+
+static struct resource mx25_csi_resources[] = {
+ {
+ .start = MX25_CSI_BASE_ADDR,
+ .end= MX25_CSI_BASE_ADDR + 0xfff,
+ .flags = IORESOURCE_MEM,
+ },
+ {
+ .start = MX25_INT_CSI,
+ .flags = IORESOURCE_IRQ
+ },
+};
+
+struct platform_device mx25_csi_device = {
+ .name = "mx2-camera",
+ .id = 0,
+ .num_resources = ARRAY_SIZE(mx25_csi_resources),
+ .resource = mx25_csi_resources,
+ .dev= {
+ .coherent_dma_mask = 0x,
+ },
+};
diff --git a/arch/arm/mach-mx25/devices.h b/arch/arm/mach-mx25/devices.h
index 39560e1..1e80ac2 100644
--- a/arch/arm/mach-mx25/devices.h
+++ b/arch/arm/mach-mx25/devices.h
@@ -21,3 +21,4 @@ extern struct platform_device mx25_fec_device;
extern struct platform_device mxc_nand_device;
extern struct platform_device mx25_rtc_device;
extern struct platform_device mx25_fb_device;
+extern struct platform_device mx25_csi_device;
diff --git a/arch/arm/plat-mxc/include/mach/mx25.h
b/arch/arm/plat-mxc/include/mach/mx25.h
index 4eb6e33..5e6a8b5 100644
--- a/arch/arm/plat-mxc/include/mach/mx25.h
+++ b/arch/arm/plat-mxc/include/mach/mx25.h
@@ -34,11 +34,13 @@
#define MX25_NFC_BASE_ADDR 0xbb00
#define MX25_DRYICE_BASE_ADDR 0x53ffc000
#define MX25_LCDC_BASE_ADDR0x53fbc000
+#define MX25_CSI_BASE_ADDR 0x53ff8000
#define MX25_INT_DRYICE25
#define MX25_INT_FEC 57
#define MX25_INT_NANDFC33
#define MX25_INT_LCDC 39
+#define MX25_INT_CSI 17
#if defined(IMX_NEEDS_DEPRECATED_SYMBOLS)
#define UART1_BASE_ADDRMX25_UART1_BASE_ADDR
--
1.7.0
--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majord...@vger.ker
[PATCH 2/3] mx27: add support for the CSI device
Signed-off-by: Baruch Siach
---
arch/arm/mach-mx2/clock_imx27.c |2 +-
arch/arm/mach-mx2/devices.c | 31 +++
arch/arm/mach-mx2/devices.h |1 +
3 files changed, 33 insertions(+), 1 deletions(-)
diff --git a/arch/arm/mach-mx2/clock_imx27.c b/arch/arm/mach-mx2/clock_imx27.c
index 0f0823c..5a1aa15 100644
--- a/arch/arm/mach-mx2/clock_imx27.c
+++ b/arch/arm/mach-mx2/clock_imx27.c
@@ -644,7 +644,7 @@ static struct clk_lookup lookups[] = {
_REGISTER_CLOCK("spi_imx.1", NULL, cspi2_clk)
_REGISTER_CLOCK("spi_imx.2", NULL, cspi3_clk)
_REGISTER_CLOCK("imx-fb.0", NULL, lcdc_clk)
- _REGISTER_CLOCK(NULL, "csi", csi_clk)
+ _REGISTER_CLOCK("mx2-camera.0", NULL, csi_clk)
_REGISTER_CLOCK("fsl-usb2-udc", "usb", usb_clk)
_REGISTER_CLOCK("fsl-usb2-udc", "usb_ahb", usb_clk1)
_REGISTER_CLOCK("mxc-ehci.0", "usb", usb_clk)
diff --git a/arch/arm/mach-mx2/devices.c b/arch/arm/mach-mx2/devices.c
index b91e412..de501ac 100644
--- a/arch/arm/mach-mx2/devices.c
+++ b/arch/arm/mach-mx2/devices.c
@@ -40,6 +40,37 @@
#include "devices.h"
+#ifdef CONFIG_MACH_MX27
+static struct resource mx27_camera_resources[] = {
+ {
+ .start = CSI_BASE_ADDR,
+ .end = CSI_BASE_ADDR + 0x1f,
+ .flags = IORESOURCE_MEM,
+ }, {
+ .start = EMMA_PRP_BASE_ADDR,
+ .end = EMMA_PRP_BASE_ADDR + 0x1f,
+ .flags = IORESOURCE_MEM,
+ }, {
+ .start = MXC_INT_CSI,
+ .end = MXC_INT_CSI,
+ .flags = IORESOURCE_IRQ,
+ },{
+ .start = MXC_INT_EMMAPRP,
+ .end = MXC_INT_EMMAPRP,
+ .flags = IORESOURCE_IRQ,
+ },
+};
+struct platform_device mx27_camera_device = {
+ .name = "mx2-camera",
+ .id = 0,
+ .num_resources = ARRAY_SIZE(mx27_camera_resources),
+ .resource = mx27_camera_resources,
+ .dev = {
+ .coherent_dma_mask = 0x,
+ },
+};
+#endif
+
/*
* SPI master controller
*
diff --git a/arch/arm/mach-mx2/devices.h b/arch/arm/mach-mx2/devices.h
index 84ed513..8bdf018 100644
--- a/arch/arm/mach-mx2/devices.h
+++ b/arch/arm/mach-mx2/devices.h
@@ -29,6 +29,7 @@ extern struct platform_device mxc_i2c_device1;
extern struct platform_device mxc_sdhc_device0;
extern struct platform_device mxc_sdhc_device1;
extern struct platform_device mxc_otg_udc_device;
+extern struct platform_device mx27_camera_device;
extern struct platform_device mxc_otg_host;
extern struct platform_device mxc_usbh1;
extern struct platform_device mxc_usbh2;
--
1.7.0
--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 0/3] Driver for the i.MX2x CMOS Sensor Interface
This series contains a soc_camera driver for the i.MX25/i.MX27 CSI device, and platform code for the i.MX25 and i.MX27 chips. This driver is based on a driver for i.MX27 CSI from Sascha Hauer, that Alan Carvalho de Assis has posted in linux-media last December[1]. Since all I have is a i.MX25 PDK paltform I can't test the mx27 specific code. Testers and comment are welcome. [1] https://patchwork.kernel.org/patch/67636/ Baruch Siach (3): mx2_camera: Add soc_camera support for i.MX25/i.MX27 mx27: add support for the CSI device mx25: add support for the CSI device arch/arm/mach-mx2/clock_imx27.c |2 +- arch/arm/mach-mx2/devices.c | 31 + arch/arm/mach-mx2/devices.h |1 + arch/arm/mach-mx25/clock.c | 14 +- arch/arm/mach-mx25/devices.c | 22 + arch/arm/mach-mx25/devices.h |1 + arch/arm/plat-mxc/include/mach/memory.h |4 +- arch/arm/plat-mxc/include/mach/mx25.h|2 + arch/arm/plat-mxc/include/mach/mx2_cam.h | 41 + drivers/media/video/Kconfig | 14 + drivers/media/video/Makefile |1 + drivers/media/video/mx2_camera.c | 1396 ++ 12 files changed, 1524 insertions(+), 5 deletions(-) create mode 100644 arch/arm/plat-mxc/include/mach/mx2_cam.h create mode 100644 drivers/media/video/mx2_camera.c -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Avermedia AverTV Capture HD support
On 5/6/10 9:30 AM, deb wrote: On 05/06/2010 01:50 PM, Omer Uner GUCLU wrote: Hello All, I have AverMedia AverTV Capture HD card. This is a hibrid card. How can I use capture interface in Linux I can help to develop a driver Isn't there a Linux driver for your card on avermedia web site ? Hmm. No idea, have you looked? Do they have a driver? -- Steven Toth - 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: Avermedia AverTV Capture HD support
On 05/06/2010 01:50 PM, Omer Uner GUCLU wrote: Hello All, I have AverMedia AverTV Capture HD card. This is a hibrid card. How can I use capture interface in Linux I can help to develop a driver Isn't there a Linux driver for your card on avermedia web site ? -- 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: [videobuf] Query: Condition bytesize limit in videobuf_reqbufs -> buf_setup() call?
> Mauro Carvalho Chehab [mailto:mche...@redhat.com] wrote: > >Pawel Osciak wrote: >> Hi, >> >>> Aguirre, Sergio wrote: >>> Basically, when calling VIDIOC_REQBUFS with a certain buffer >>> Count, we had a software limit for total size, calculated depending on: >>> >>> Total bytesize = bytesperline x height x count >>> >>> So, we had an arbitrary limit to, say 32 MB, which was generic. >>> >>> Now, we want to condition it ONLY when MMAP buffers will be used. >>> Meaning, we don't want to keep that policy when the kernel is not >>> allocating the space >>> >>> But the thing is that, according to videobuf documentation, buf_setup is >>> the one who should put a RAM usage limit. BUT the memory type passed to >>> reqbufs is not propagated to buf_setup, therefore forcing me to go to a >>> non-standard memory limitation in my reqbufs callback function, instead >>> of doing it properly inside buf_setup. >> >> buf_setup is called during REQBUFS and is indeed the place to limit the >> size and actually allocate the buffers as well, or at least try to do so, >> as V4L2 API requires. This is not currently the case with videobuf, but >> right now we are working to change it. > >I can't see the problem you're mentioning. Drivers apply (or should apply) >the maximum size limit at buffer setup. For example bttv driver seems to do >the right thing: Not really a problem. You are right about setup. I meant that videobuf behaves differently in regard to when it actually allocates the buffers. Best regards -- Pawel Osciak Linux Platform Group Samsung Poland R&D Center -- 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: [videobuf] Query: Condition bytesize limit in videobuf_reqbufs -> buf_setup() call?
Laurent Pinchart wrote:
> Hi Mauro,
>
> On Thursday 06 May 2010 14:38:36 Mauro Carvalho Chehab wrote:
>> Laurent Pinchart wrote:
>>> On Thursday 06 May 2010 01:29:54 Aguirre, Sergio wrote:
> -Original Message-
> From: Mauro Carvalho Chehab [mailto:mche...@redhat.com]
> Sent: Wednesday, May 05, 2010 6:24 PM
> To: Aguirre, Sergio
> Cc: linux-media@vger.kernel.org
> Subject: Re: [videobuf] Query: Condition bytesize limit in
> videobuf_reqbufs -> buf_setup() call?
>
> Aguirre, Sergio wrote:
>> Hi all,
>>
>> While working on an old port of the omap3 camera-isp driver,
>> I have faced some problem.
>>
>> Basically, when calling VIDIOC_REQBUFS with a certain buffer
>>
>> Count, we had a software limit for total size, calculated depending on:
>> Total bytesize = bytesperline x height x count
>>
>> So, we had an arbitrary limit to, say 32 MB, which was generic.
>>
>> Now, we want to condition it ONLY when MMAP buffers will be used.
>> Meaning, we don't want to keep that policy when the kernel is not
>> allocating the space
>>
>> But the thing is that, according to videobuf documentation, buf_setup
>> is the one who should put a RAM usage limit. BUT the memory type
>> passed to reqbufs is not propagated to buf_setup, therefore forcing me
>> to go to a non-standard memory limitation in my reqbufs callback
>> function, instead of doing it properly inside buf_setup.
>>
>> Is this scenario a good consideration to change buf_setup API, and
>> propagate buffers memory type aswell?
> I don't see any problem on propagating the memory type to buffer_setup,
> if this is really needed. Yet, I can't see why you would restrict the
> buffer size to 32 MB on one case, and not restrict the size at all with
> non-MMAP types.
Ok, my reason for doing that is because I thought that there should be a
memory limit in whichever place you're doing the buffer allocations.
MMAP is allocating buffers in kernel, so kernel should provide a memory
restriction, if applies.
USERPTR is allocating buffers in userspace, so userspace should provide
a memory restriction, if applies.
>>> I agree with the intend here, but not with the current implementation
>>> which has a hardcoded arbitrary limit. Do you think it would be possible
>>> to compute a meaningful default limit in the V4L2 core, with a way for
>>> userspace to modify it (with root privileges of course) ?
>> On almost all drivers, the limit is not arbitrary. It is a reasonable
>> number of buffers (like 16 buffers). A limit in terms of the number of
>> buffers is meaningful for V4L2 API, and also, has a "physical meaning":
>> considering that almost all drivers that use videobuf can do at maximum 30
>> fps, 16 buffers mean that the maximum delay that the driver will apply to
>> the stream is 533 ms.
>>
>> Some drivers even provide a modprobe parameter to allow changing this limit
>> (for example, bttv allows changing it up to 32 buffers), but only during
>> module load time. I can't foresee any use case where this maximum limit
>> would need to be dynamically adjusted. Root can always change it by
>> removing and re-inserting the module with a new maximum size.
>
> I wasn't talking about the limit on the number of buffers, but on the amount
> of memory. That's what Sergio was mentioning, and that's what is done in the
> OMAP3 ISP driver.
The memory consumption is basically dictated by the maximum size of an image
(resolution x bpp / 8) and the number of buffers. An arbitrary value in terms
of megabytes is meaningless: it is just a random number above some reasonable
limit.
The proper way to limit memory is to do something like:
#define MAX_HRES1920
#define MAX_VRES1650
#define MAX_DEPTH 3
#define MAX_BUFS4
#define MAX_MEMSIZE (MAX_HRES * MAX_VRES * MAX_DEPTH * MAX_BUFS)
buf_setup(...)
{
if (size > MAX_MEMSIZE)
fix_it_by_reducing_number_of_buffers();
}
--
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: Philips/NXP channel decoders
Hello Steven, > I can test your TDA10048 patches and add sign-off for merge. Looking > at the list it appears that you have a few nice cleanups. I'll draw > all of these together this weekend and run some tests. Thanks a lot. By the way, I found the read_ber function not fully defined. I guess this subject has already been addressed on this list but cannot pinpoint where in the archives. Did I miss something ? First, *ber is an unsigned integer type, then the bit-error-rate (<=1) has obviously to be made higher than 1. I have decided to multiply the actual ber into 1e8 for two reasons: - 1e-8 offers a good precision and is compatible with what can give the TDA10046/TDA10048 for the VBER - the theoretical max value (1 -> 1e8) fits into the u32 type Naturally, this factor of 1e8 should be defined to be homogeneous for all channel decoders as the read_ber function is exposed. Second, the returned BER is the channel bit-error-rate which is the BER estimation before the Viterbi decoder (for DVB-T). Why this choice ? Thanks in advance for clarifying. -- Guillaume -- 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: Avermedia AverTV Capture HD support
On Thu, May 6, 2010 at 9:05 AM, Omer Uner GUCLU wrote: > I need frame grabber or capture card which has 1080i support for one > application. > Can you give me advice which card(s) suitable for our application. The only device supported under Linux which can support HD capture is the Hauppauge HD-PVR. Cheers, 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
[PATCH 1/3] mx2_camera: Add soc_camera support for i.MX25/i.MX27
This is the soc_camera support developed by Sascha Hauer for the i.MX27. Alan
Carvalho de Assis modified the original driver to get it working on more recent
kernels. I modified it further to add support for i.MX25. This driver has only
been tested on the i.MX25 platform.
Signed-off-by: Baruch Siach
---
arch/arm/plat-mxc/include/mach/memory.h |4 +-
arch/arm/plat-mxc/include/mach/mx2_cam.h | 41 +
drivers/media/video/Kconfig | 14 +
drivers/media/video/Makefile |1 +
drivers/media/video/mx2_camera.c | 1396 ++
5 files changed, 1454 insertions(+), 2 deletions(-)
create mode 100644 arch/arm/plat-mxc/include/mach/mx2_cam.h
create mode 100644 drivers/media/video/mx2_camera.c
diff --git a/arch/arm/plat-mxc/include/mach/memory.h
b/arch/arm/plat-mxc/include/mach/memory.h
index c4b40c3..5803836 100644
--- a/arch/arm/plat-mxc/include/mach/memory.h
+++ b/arch/arm/plat-mxc/include/mach/memory.h
@@ -44,12 +44,12 @@
*/
#define CONSISTENT_DMA_SIZE SZ_8M
-#elif defined(CONFIG_MX1_VIDEO)
+#elif defined(CONFIG_MX1_VIDEO) || defined(CONFIG_MX2_VIDEO)
/*
* Increase size of DMA-consistent memory region.
* This is required for i.MX camera driver to capture at least four VGA frames.
*/
#define CONSISTENT_DMA_SIZE SZ_4M
-#endif /* CONFIG_MX1_VIDEO */
+#endif /* CONFIG_MX1_VIDEO || CONFIG_MX2_VIDEO */
#endif /* __ASM_ARCH_MXC_MEMORY_H__ */
diff --git a/arch/arm/plat-mxc/include/mach/mx2_cam.h
b/arch/arm/plat-mxc/include/mach/mx2_cam.h
new file mode 100644
index 000..01b3bdc
--- /dev/null
+++ b/arch/arm/plat-mxc/include/mach/mx2_cam.h
@@ -0,0 +1,41 @@
+/*
+mx2-cam.h - i.MX27/i.MX25 camera driver header file
+
+Copyright (C) 2003, Intel Corporation
+Copyright (C) 2008, Sascha Hauer
+Copyright (C) 2010, Baruch Siach
+
+This program is free software; you can redistribute it and/or modify
+it under the terms of the GNU General Public License as published by
+the Free Software Foundation; either version 2 of the License, or
+(at your option) any later version.
+
+This program is distributed in the hope that it will be useful,
+but WITHOUT ANY WARRANTY; without even the implied warranty of
+MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+GNU General Public License for more details.
+
+You should have received a copy of the GNU General Public License
+along with this program; if not, write to the Free Software
+Foundation, Inc., 51 Franklin St - Fifth Floor, Boston, MA 02110-1301 USA.
+*/
+
+#ifndef __MACH_MX2_CAM_H_
+#define __MACH_MX2_CAM_H_
+
+#define MX2_CAMERA_SWAP16 (1 << 0)
+#define MX2_CAMERA_EXT_VSYNC (1 << 1)
+#define MX2_CAMERA_CCIR(1 << 2)
+#define MX2_CAMERA_CCIR_INTERLACE (1 << 3)
+#define MX2_CAMERA_HSYNC_HIGH (1 << 4)
+#define MX2_CAMERA_GATED_CLOCK (1 << 5)
+#define MX2_CAMERA_INV_DATA(1 << 6)
+#define MX2_CAMERA_PCLK_SAMPLE_RISING (1 << 7)
+#define MX2_CAMERA_PACK_DIR_MSB(1 << 8)
+
+struct mx2_camera_platform_data {
+ unsigned long flags;
+ unsigned long clk;
+};
+
+#endif /* __MACH_MX2_CAM_H_ */
diff --git a/drivers/media/video/Kconfig b/drivers/media/video/Kconfig
index f8fc865..4e230b8 100644
--- a/drivers/media/video/Kconfig
+++ b/drivers/media/video/Kconfig
@@ -949,6 +949,20 @@ config VIDEO_OMAP2
---help---
This is a v4l2 driver for the TI OMAP2 camera capture interface
+config MX2_VIDEO
+bool
+
+config VIDEO_MX2
+ tristate "i.MX27/i.MX25 Camera Sensor Interface driver"
+ depends on VIDEO_DEV && (MACH_MX27 || ARCH_MX25)
+ select SOC_CAMERA
+ select VIDEOBUF_DMA_CONTIG
+ select MX2_VIDEO
+ ---help---
+ This is a v4l2 driver for the i.MX27 and the i.MX25 Camera Sensor
+ Interface
+
+
#
# USB Multimedia device configuration
#
diff --git a/drivers/media/video/Makefile b/drivers/media/video/Makefile
index b88b617..177af1a 100644
--- a/drivers/media/video/Makefile
+++ b/drivers/media/video/Makefile
@@ -156,6 +156,7 @@ obj-$(CONFIG_SOC_CAMERA)+= soc_camera.o
soc_mediabus.o
obj-$(CONFIG_SOC_CAMERA_PLATFORM) += soc_camera_platform.o
# soc-camera host drivers have to be linked after camera drivers
obj-$(CONFIG_VIDEO_MX1)+= mx1_camera.o
+obj-$(CONFIG_VIDEO_MX2)+= mx2_camera.o
obj-$(CONFIG_VIDEO_MX3)+= mx3_camera.o
obj-$(CONFIG_VIDEO_PXA27x) += pxa_camera.o
obj-$(CONFIG_VIDEO_SH_MOBILE_CEU) += sh_mobile_ceu_camera.o
diff --git a/drivers/media/video/mx2_camera.c b/drivers/media/video/mx2_camera.c
new file mode 100644
index 000..5d6fb08
--- /dev/null
+++ b/drivers/media/video/mx2_camera.c
@@ -0,0 +1,1396 @@
+/*
+ * V4L2 Driver for i.MX27/i.MX25 camera host
+ *
+ * Copyright (C) 2008, Sascha Hauer, Pengutronix
+ *
+ * This program is free software;
Re: [videobuf] Query: Condition bytesize limit in videobuf_reqbufs -> buf_setup() call?
Pawel Osciak wrote:
> Hi,
>
>> Aguirre, Sergio wrote:
>> Basically, when calling VIDIOC_REQBUFS with a certain buffer
>> Count, we had a software limit for total size, calculated depending on:
>>
>> Total bytesize = bytesperline x height x count
>>
>> So, we had an arbitrary limit to, say 32 MB, which was generic.
>>
>> Now, we want to condition it ONLY when MMAP buffers will be used.
>> Meaning, we don't want to keep that policy when the kernel is not
>> allocating the space
>>
>> But the thing is that, according to videobuf documentation, buf_setup is
>> the one who should put a RAM usage limit. BUT the memory type passed to
>> reqbufs is not propagated to buf_setup, therefore forcing me to go to a
>> non-standard memory limitation in my reqbufs callback function, instead
>> of doing it properly inside buf_setup.
>
> buf_setup is called during REQBUFS and is indeed the place to limit the
> size and actually allocate the buffers as well, or at least try to do so,
> as V4L2 API requires. This is not currently the case with videobuf, but
> right now we are working to change it.
I can't see the problem you're mentioning. Drivers apply (or should apply)
the maximum size limit at buffer setup. For example bttv driver seems to do
the right thing:
static unsigned int gbuffers = 8;
static unsigned int gbufsize = 0x208000;
...
MODULE_PARM_DESC(gbuffers,"number of capture buffers. range 2-32, default 8");
MODULE_PARM_DESC(gbufsize,"size of the capture buffers, default is 0x208000");
...
static int
buffer_setup(struct videobuf_queue *q, unsigned int *count, unsigned int *size)
{
struct bttv_fh *fh = q->priv_data;
*size = fh->fmt->depth*fh->width*fh->height >> 3;
if (0 == *count)
*count = gbuffers;
if (*size * *count > gbuffers * gbufsize)
*count = (gbuffers * gbufsize) / *size;
return 0;
}
> buf_prepare() is called on QBUF
> and it is definitely too late to do things like that then. It is the
> REQBUFS that should be failing if the requested number of buffers is too
> high.
Yes, it is too late. Restrictions like that should be done at REQBUFS.
--
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: Avermedia AverTV Capture HD support
I need frame grabber or capture card which has 1080i support for one application. Can you give me advice which card(s) suitable for our application. Thanks, Omer 2010/5/6 Steven Toth : > On Thu, May 6, 2010 at 8:44 AM, Omer Uner GUCLU > wrote: >> Steven, >> >> I do not know this card is same with you. lspci output is like that. >> >> 02:00.0 Multimedia video controller: Device 1a0a:6200 (rev 01) > > Don't remove the mailing list cc, I've added it back. > > Unless you have the datasheet for the TM6200 PCIe bridge then this > cannot happen, last I checked it was not freely available. So, I do > not think this is possible. > > Regards, > > -- > Steven Toth - 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: [videobuf] Query: Condition bytesize limit in videobuf_reqbufs -> buf_setup() call?
Hi Mauro, On Thursday 06 May 2010 14:38:36 Mauro Carvalho Chehab wrote: > Laurent Pinchart wrote: > > On Thursday 06 May 2010 01:29:54 Aguirre, Sergio wrote: > >>> -Original Message- > >>> From: Mauro Carvalho Chehab [mailto:mche...@redhat.com] > >>> Sent: Wednesday, May 05, 2010 6:24 PM > >>> To: Aguirre, Sergio > >>> Cc: linux-media@vger.kernel.org > >>> Subject: Re: [videobuf] Query: Condition bytesize limit in > >>> videobuf_reqbufs -> buf_setup() call? > >>> > >>> Aguirre, Sergio wrote: > Hi all, > > While working on an old port of the omap3 camera-isp driver, > I have faced some problem. > > Basically, when calling VIDIOC_REQBUFS with a certain buffer > > Count, we had a software limit for total size, calculated depending on: > Total bytesize = bytesperline x height x count > > So, we had an arbitrary limit to, say 32 MB, which was generic. > > Now, we want to condition it ONLY when MMAP buffers will be used. > Meaning, we don't want to keep that policy when the kernel is not > allocating the space > > But the thing is that, according to videobuf documentation, buf_setup > is the one who should put a RAM usage limit. BUT the memory type > passed to reqbufs is not propagated to buf_setup, therefore forcing me > to go to a non-standard memory limitation in my reqbufs callback > function, instead of doing it properly inside buf_setup. > > Is this scenario a good consideration to change buf_setup API, and > propagate buffers memory type aswell? > >>> > >>> I don't see any problem on propagating the memory type to buffer_setup, > >>> if this is really needed. Yet, I can't see why you would restrict the > >>> buffer size to 32 MB on one case, and not restrict the size at all with > >>> non-MMAP types. > >> > >> Ok, my reason for doing that is because I thought that there should be a > >> memory limit in whichever place you're doing the buffer allocations. > >> > >> MMAP is allocating buffers in kernel, so kernel should provide a memory > >> restriction, if applies. > >> > >> USERPTR is allocating buffers in userspace, so userspace should provide > >> a memory restriction, if applies. > > > > I agree with the intend here, but not with the current implementation > > which has a hardcoded arbitrary limit. Do you think it would be possible > > to compute a meaningful default limit in the V4L2 core, with a way for > > userspace to modify it (with root privileges of course) ? > > On almost all drivers, the limit is not arbitrary. It is a reasonable > number of buffers (like 16 buffers). A limit in terms of the number of > buffers is meaningful for V4L2 API, and also, has a "physical meaning": > considering that almost all drivers that use videobuf can do at maximum 30 > fps, 16 buffers mean that the maximum delay that the driver will apply to > the stream is 533 ms. > > Some drivers even provide a modprobe parameter to allow changing this limit > (for example, bttv allows changing it up to 32 buffers), but only during > module load time. I can't foresee any use case where this maximum limit > would need to be dynamically adjusted. Root can always change it by > removing and re-inserting the module with a new maximum size. I wasn't talking about the limit on the number of buffers, but on the amount of memory. That's what Sergio was mentioning, and that's what is done in the OMAP3 ISP driver. -- Regards, Laurent Pinchart -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Avermedia AverTV Capture HD support
On Thu, May 6, 2010 at 8:44 AM, Omer Uner GUCLU wrote: > Steven, > > I do not know this card is same with you. lspci output is like that. > > 02:00.0 Multimedia video controller: Device 1a0a:6200 (rev 01) Don't remove the mailing list cc, I've added it back. Unless you have the datasheet for the TM6200 PCIe bridge then this cannot happen, last I checked it was not freely available. So, I do not think this is possible. Regards, -- Steven Toth - 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] dvb_frontend: fix typos in comments and one function
On Thu, May 6, 2010 at 8:30 AM, Guillaume Audirac wrote: > Hello, > > Trivial patch for typos. Thanks Guillaume. I've had an open TDA10048 bug on my list for quite a while, I think you've already made reference to this in an earlier email. Essentially I'm told my a number of Australian users that the 10048 isn't broad-locking when tuned +- 167Khz away from the carrier, which it should definitely do. If you're in the mood for patching the 10048 and want to find and flip the broad-locking bit then I'd be certainly thrilled to test this. :) Regards, -- Steven Toth - 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: Avermedia AverTV Capture HD support
> Hello All, Hi, > I have AverMedia AverTV Capture HD card. This is a hibrid card. How > can I use capture interface in Linux > I can help to develop a driver > Thanks, Assuming I'm thinking about the same card, last I checked the TM6200 PCIe bridge didn't have a freely available public datasheet. Can you help with this? Regards, -- Steven Toth - 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: [videobuf] Query: Condition bytesize limit in videobuf_reqbufs -> buf_setup() call?
Laurent Pinchart wrote: > Hi Sergio, > > On Thursday 06 May 2010 01:29:54 Aguirre, Sergio wrote: >>> -Original Message- >>> From: Mauro Carvalho Chehab [mailto:mche...@redhat.com] >>> Sent: Wednesday, May 05, 2010 6:24 PM >>> To: Aguirre, Sergio >>> Cc: linux-media@vger.kernel.org >>> Subject: Re: [videobuf] Query: Condition bytesize limit in >>> videobuf_reqbufs -> buf_setup() call? >>> >>> Aguirre, Sergio wrote: Hi all, While working on an old port of the omap3 camera-isp driver, I have faced some problem. Basically, when calling VIDIOC_REQBUFS with a certain buffer Count, we had a software limit for total size, calculated depending on: Total bytesize = bytesperline x height x count So, we had an arbitrary limit to, say 32 MB, which was generic. Now, we want to condition it ONLY when MMAP buffers will be used. Meaning, we don't want to keep that policy when the kernel is not allocating the space But the thing is that, according to videobuf documentation, buf_setup is the one who should put a RAM usage limit. BUT the memory type passed to reqbufs is not propagated to buf_setup, therefore forcing me to go to a non-standard memory limitation in my reqbufs callback function, instead of doing it properly inside buf_setup. Is this scenario a good consideration to change buf_setup API, and propagate buffers memory type aswell? >>> I don't see any problem on propagating the memory type to buffer_setup, >>> if this is really needed. Yet, I can't see why you would restrict the >>> buffer size to 32 MB on one case, and not restrict the size at all with >>> non-MMAP types. >> Ok, my reason for doing that is because I thought that there should be a >> memory limit in whichever place you're doing the buffer allocations. >> >> MMAP is allocating buffers in kernel, so kernel should provide a memory >> restriction, if applies. >> >> USERPTR is allocating buffers in userspace, so userspace should provide a >> memory restriction, if applies. > > I agree with the intend here, but not with the current implementation which > has a hardcoded arbitrary limit. Do you think it would be possible to compute > a meaningful default limit in the V4L2 core, with a way for userspace to > modify it (with root privileges of course) ? > On almost all drivers, the limit is not arbitrary. It is a reasonable number of buffers (like 16 buffers). A limit in terms of the number of buffers is meaningful for V4L2 API, and also, has a "physical meaning": considering that almost all drivers that use videobuf can do at maximum 30 fps, 16 buffers mean that the maximum delay that the driver will apply to the stream is 533 ms. Some drivers even provide a modprobe parameter to allow changing this limit (for example, bttv allows changing it up to 32 buffers), but only during module load time. I can't foresee any use case where this maximum limit would need to be dynamically adjusted. Root can always change it by removing and re-inserting the module with a new maximum size. -- 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: Philips/NXP channel decoders
> I am starting first in diving into the tda10048 driver (DVB-T) to become > familiar with the API. In case you know some existing issues, please > report them to me, I would be glad to investigate and help. > > Last but not least, I don't have any hardware yet, is it blocking to > eventually send patches ? I can test your TDA10048 patches and add sign-off for merge. Looking at the list it appears that you have a few nice cleanups. I'll draw all of these together this weekend and run some tests. Regards, -- Steven Toth - 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
[PATCH] dvb_frontend: fix typos in comments and one function
Hello,
Trivial patch for typos.
Signed-off-by: Guillaume Audirac
---
drivers/media/dvb/dvb-core/dvb_frontend.c | 10 +-
1 files changed, 5 insertions(+), 5 deletions(-)
diff --git a/drivers/media/dvb/dvb-core/dvb_frontend.c
b/drivers/media/dvb/dvb-core/dvb_frontend.c
index 55ea260..e12a0f9 100644
--- a/drivers/media/dvb/dvb-core/dvb_frontend.c
+++ b/drivers/media/dvb/dvb-core/dvb_frontend.c
@@ -460,7 +460,7 @@ static void dvb_frontend_swzigzag(struct dvb_frontend
*fe)
if ((fepriv->state & FESTATE_SEARCHING_FAST) || (fepriv->state &
FESTATE_RETUNE)) {
fepriv->delay = fepriv->min_delay;
- /* peform a tune */
+ /* perform a tune */
retval = dvb_frontend_swzigzag_autotune(fe,
fepriv->check_wrapped);
if (retval < 0) {
@@ -783,7 +783,7 @@ static int dvb_frontend_start(struct dvb_frontend *fe)
return 0;
}
-static void dvb_frontend_get_frequeny_limits(struct dvb_frontend *fe,
+static void dvb_frontend_get_frequency_limits(struct dvb_frontend *fe,
u32 *freq_min, u32 *freq_max)
{
*freq_min = max(fe->ops.info.frequency_min,
fe->ops.tuner_ops.info.frequency_min);
@@ -807,7 +807,7 @@ static int dvb_frontend_check_parameters(struct
dvb_frontend *fe,
u32 freq_max;
/* range check: frequency */
- dvb_frontend_get_frequeny_limits(fe, &freq_min, &freq_max);
+ dvb_frontend_get_frequency_limits(fe, &freq_min, &freq_max);
if ((freq_min && parms->frequency < freq_min) ||
(freq_max && parms->frequency > freq_max)) {
printk(KERN_WARNING "DVB: adapter %i frontend %i frequency %u
out of
range (%u..%u)\n",
@@ -1620,7 +1620,7 @@ static int dvb_frontend_ioctl_legacy(struct inode
*inode, struct file *file,
case FE_GET_INFO: {
struct dvb_frontend_info* info = parg;
memcpy(info, &fe->ops.info, sizeof(struct dvb_frontend_info));
- dvb_frontend_get_frequeny_limits(fe, &info->frequency_min,
&info->frequency_max);
+ dvb_frontend_get_frequency_limits(fe, &info->frequency_min,
&info->frequency_max);
/* Force the CAN_INVERSION_AUTO bit on. If the frontend doesn't
* do it, it is done for it. */
@@ -1719,7 +1719,7 @@ static int dvb_frontend_ioctl_legacy(struct inode
*inode, struct file *file,
* (stv0299 for instance) take longer than 8msec to
* respond to a set_voltage command. Those switches
* need custom routines to switch properly. For all
-* other frontends, the following shoule work ok.
+* other frontends, the following should work ok.
* Dish network legacy switches (as used by Dish500)
* are controlled by sending 9-bit command words
* spaced 8msec apart.
--
1.6.3.3
--
Guillaume
--
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] tda10048: clear the uncorrected packet registers when saturated
Hello, Use the register CLUNC to reset the CPTU registers (LSB & MSB) when they saturate at 0x. Fixes as well a few register typos. Signed-off-by: Guillaume Audirac --- drivers/media/dvb/frontends/tda10048.c | 11 +++ 1 files changed, 7 insertions(+), 4 deletions(-) diff --git a/drivers/media/dvb/frontends/tda10048.c b/drivers/media/dvb/frontends/tda10048.c index 9a0ba30..93f6a75 100644 --- a/drivers/media/dvb/frontends/tda10048.c +++ b/drivers/media/dvb/frontends/tda10048.c @@ -50,8 +50,8 @@ #define TDA10048_CONF_C4_1 0x1E #define TDA10048_CONF_C4_2 0x1F #define TDA10048_CODE_IN_RAM 0x20 -#define TDA10048_CHANNEL_INFO_1_R 0x22 -#define TDA10048_CHANNEL_INFO_2_R 0x23 +#define TDA10048_CHANNEL_INFO1_R 0x22 +#define TDA10048_CHANNEL_INFO2_R 0x23 #define TDA10048_CHANNEL_INFO1 0x24 #define TDA10048_CHANNEL_INFO2 0x25 #define TDA10048_TIME_ERROR_R 0x26 @@ -64,8 +64,8 @@ #define TDA10048_IT_STAT 0x32 #define TDA10048_DSP_AD_LSB0x3C #define TDA10048_DSP_AD_MSB0x3D -#define TDA10048_DSP_REF_LSB 0x3E -#define TDA10048_DSP_REF_MSB 0x3F +#define TDA10048_DSP_REG_LSB 0x3E +#define TDA10048_DSP_REG_MSB 0x3F #define TDA10048_CONF_TRISTATE10x44 #define TDA10048_CONF_TRISTATE20x45 #define TDA10048_CONF_POLARITY 0x46 @@ -1033,6 +1033,9 @@ static int tda10048_read_ucblocks(struct dvb_frontend *fe, u32 *ucblocks) *ucblocks = tda10048_readreg(state, TDA10048_UNCOR_CPT_MSB) << 8 | tda10048_readreg(state, TDA10048_UNCOR_CPT_LSB); + /* clear the uncorrected TS packets counter when saturated */ + if (*ucblocks == 0x) + tda10048_writereg(state, TDA10048_UNCOR_CTRL, 0x80); return 0; } -- 1.6.3.3 -- Guillaume -- 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] tda10048: fix bitmask for the transmission mode
Hello,
Add a missing bit for reading the transmission mode (2K/8K) in
tda10048_get_tps
Signed-off-by: Guillaume Audirac
---
drivers/media/dvb/frontends/tda10048.c |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/drivers/media/dvb/frontends/tda10048.c
b/drivers/media/dvb/frontends/tda10048.c
index 9006107..9a0ba30 100644
--- a/drivers/media/dvb/frontends/tda10048.c
+++ b/drivers/media/dvb/frontends/tda10048.c
@@ -689,7 +689,7 @@ static int tda10048_get_tps(struct tda10048_state *state,
p->guard_interval = GUARD_INTERVAL_1_4;
break;
}
- switch (val & 0x02) {
+ switch (val & 0x03) {
case 0:
p->transmission_mode = TRANSMISSION_MODE_2K;
break;
--
1.6.3.3
--
Guillaume
--
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
Avermedia AverTV Capture HD support
Hello All, I have AverMedia AverTV Capture HD card. This is a hibrid card. How can I use capture interface in Linux I can help to develop a driver Thanks, Omer Uner Guclu -- 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: stv090x vs stv0900
Hi Pascal, > I was adding support for a non working version of DVBWorld HD 2104 > > It is listed on > http://www.linuxtv.org/wiki/index.php/DVBWorld_HD_2104_FTA_USB_Box as : > > = > for new solution : 2104B (Sharp0169 Tuner) > > * STV6110A tuner > * ST0903 demod > * Cyrix CY7C68013A USB controller > = > > The 2104A is supposed to be working and also have ST0903 but uses > stv0900, so I tried using it too but did not manage to get it working. > > I now have some working code by using stv090x + stv6110x (copied config > from budget) but I am wondering why do we have 2 drivers for stv0900, > and is stv0900 supposed to handle stv0903 devices or is either the code > or the wki wrong about 2104A? > > Also, are they both maintained ? I wrote a patch to add get_frontend to > stv090x but stv0900 also does not have it and I don't know which one > should get new code. > > And stv6110x seems to also handle stv6110 which also exists as a > separate module... Hehe, you are not only one who is fooled by current situation regarding demods stv0900/stv0903 and plls stv6110. Current status-quo is not good. Same question is asked here again and again. Interesting that it is against usual rule having only one driver for every chip in kernel, but this time that rather strong rule was not applied. Dunno why. May be someone from "knowings" can answer that on wiki? /Honza PS: FYI I'm also using BOTH variants in 2 projects. For me both look very similar and work w/o probs. So I can't tell you which is better :) -- 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
stv090x vs stv0900
Hi, I was adding support for a non working version of DVBWorld HD 2104 It is listed on http://www.linuxtv.org/wiki/index.php/DVBWorld_HD_2104_FTA_USB_Box as : = for new solution : 2104B (Sharp0169 Tuner) * STV6110A tuner * ST0903 demod * Cyrix CY7C68013A USB controller = The 2104A is supposed to be working and also have ST0903 but uses stv0900, so I tried using it too but did not manage to get it working. I now have some working code by using stv090x + stv6110x (copied config from budget) but I am wondering why do we have 2 drivers for stv0900, and is stv0900 supposed to handle stv0903 devices or is either the code or the wki wrong about 2104A? Also, are they both maintained ? I wrote a patch to add get_frontend to stv090x but stv0900 also does not have it and I don't know which one should get new code. And stv6110x seems to also handle stv6110 which also exists as a separate module... -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 1/1] staging: cx25821: cx25821-alsa.c: cleanup
Signed-off-by: Boris Popov
---
drivers/staging/cx25821/cx25821-alsa.c | 80 +---
1 files changed, 42 insertions(+), 38 deletions(-)
diff --git a/drivers/staging/cx25821/cx25821-alsa.c
b/drivers/staging/cx25821/cx25821-alsa.c
index 061add3..c73061e 100644
--- a/drivers/staging/cx25821/cx25821-alsa.c
+++ b/drivers/staging/cx25821/cx25821-alsa.c
@@ -29,7 +29,7 @@
#include
#include
-#include
+#include
#include
#include
#include
@@ -42,10 +42,10 @@
#define AUDIO_SRAM_CHANNEL SRAM_CH08
-#define dprintk(level,fmt, arg...) if (debug >= level) \
+#define dprintk(level, fmt, arg...)if (debug >= level) \
printk(KERN_INFO "%s/1: " fmt, chip->dev->name , ## arg)
-#define dprintk_core(level,fmt, arg...)if (debug >= level) \
+#define dprintk_core(level, fmt, arg...) if (debug >= level) \
printk(KERN_DEBUG "%s/1: " fmt, chip->dev->name , ## arg)
/
@@ -90,8 +90,8 @@ typedef struct cx25821_audio_dev snd_cx25821_card_t;
static int index[SNDRV_CARDS] = SNDRV_DEFAULT_IDX; /* Index 0-MAX */
static char *id[SNDRV_CARDS] = SNDRV_DEFAULT_STR; /* ID for this card */
-static int enable[SNDRV_CARDS] = { 1,[1 ... (SNDRV_CARDS - 1)] = 1 };
-
+static int enable[SNDRV_CARDS] = {1,[1...(SNDRV_CARDS - 1)] = 1};
+`
module_param_array(enable, bool, NULL, 0444);
MODULE_PARM_DESC(enable, "Enable cx25821 soundcard. default enabled.");
@@ -105,7 +105,7 @@ MODULE_PARM_DESC(index, "Index value for cx25821 capture
interface(s).");
MODULE_DESCRIPTION("ALSA driver module for cx25821 based capture cards");
MODULE_AUTHOR("Hiep Huynh");
MODULE_LICENSE("GPL");
-MODULE_SUPPORTED_DEVICE("{{Conexant,25821}"); //"{{Conexant,23881},"
+MODULE_SUPPORTED_DEVICE("{{Conexant,25821}"); /* "{{Conexant,23881}, */
static unsigned int debug;
module_param(debug, int, 0644);
@@ -135,7 +135,7 @@ MODULE_PARM_DESC(debug, "enable debug messages");
* BOARD Specific: Sets audio DMA
*/
-static int _cx25821_start_audio_dma(snd_cx25821_card_t * chip)
+static int _cx25821_start_audio_dma(snd_cx25821_card_t *chip)
{
struct cx25821_buffer *buf = chip->buf;
struct cx25821_dev *dev = chip->dev;
@@ -143,7 +143,7 @@ static int _cx25821_start_audio_dma(snd_cx25821_card_t *
chip)
&cx25821_sram_channels[AUDIO_SRAM_CHANNEL];
u32 tmp = 0;
- // enable output on the GPIO 0 for the MCLK ADC (Audio)
+ /* enable output on the GPIO 0 for the MCLK ADC (Audio) */
cx25821_set_gpiopin_direction(chip->dev, 0, 0);
/* Make sure RISC/FIFO are off before changing FIFO/RISC settings */
@@ -158,18 +158,22 @@ static int _cx25821_start_audio_dma(snd_cx25821_card_t *
chip)
cx_write(AUD_A_LNGTH, buf->bpl);
/* reset counter */
- cx_write(AUD_A_GPCNT_CTL, GP_COUNT_CONTROL_RESET);
//GP_COUNT_CONTROL_RESET = 0x3
+ cx_write(AUD_A_GPCNT_CTL, GP_COUNT_CONTROL_RESET);
+ /* GP_COUNT_CONTROL_RESET = 0x3 */
atomic_set(&chip->count, 0);
- //Set the input mode to 16-bit
+ /* Set the input mode to 16-bit */
tmp = cx_read(AUD_A_CFG);
cx_write(AUD_A_CFG,
tmp | FLD_AUD_DST_PK_MODE | FLD_AUD_DST_ENABLE |
FLD_AUD_CLK_ENABLE);
- //printk(KERN_INFO "DEBUG: Start audio DMA, %d B/line,
cmds_start(0x%x)= %d lines/FIFO, %d periods, %d "
- // "byte buffer\n", buf->bpl, audio_ch->cmds_start,
cx_read(audio_ch->cmds_start + 12)>>1,
- // chip->num_periods, buf->bpl * chip->num_periods);
+ /* printk(KERN_INFO "DEBUG: Start audio DMA, %d B/line,
+* cmds_start(0x%x)= %d lines/FIFO, %d periods, %d "
+* "byte buffer\n", buf->bpl, audio_ch->cmds_start,
+* cx_read(audio_ch->cmds_start + 12)>>1,
+* chip->num_periods, buf->bpl * chip->num_periods);
+*/
/* Enables corresponding bits at AUD_INT_STAT */
cx_write(AUD_A_INT_MSK,
@@ -182,7 +186,7 @@ static int _cx25821_start_audio_dma(snd_cx25821_card_t *
chip)
/* enable audio irqs */
cx_set(PCI_INT_MSK, chip->dev->pci_irqmask | PCI_MSK_AUD_INT);
- // Turn on audio downstream fifo and risc enable 0x101
+ /* Turn on audio downstream fifo and risc enable 0x101 */
tmp = cx_read(AUD_INT_DMA_CTL);
cx_set(AUD_INT_DMA_CTL,
tmp | (FLD_AUD_DST_A_RISC_EN | FLD_AUD_DST_A_FIFO_EN));
@@ -194,7 +198,7 @@ static int _cx25821_start_audio_dma(snd_cx25821_card_t *
chip)
/*
* BOARD Specific: Resets audio DMA
*/
-static int _cx25821_stop_audio_dma(snd_cx25821_card_t * chip)
+static int _cx25821_stop_audio_dma(snd_cx25821_card_t *chip)
{
struct cx25821_dev *dev = chip->dev;
@@ -232,13 +236,12 @@ static char *cx25821_aud_irqs[32] = {
/*
* BOARD Specific: Threats IRQ audio specific calls
*/
-static void cx25821_aud_irq(snd_cx25821_card_t * chip, u32 status, u3
Re: [videobuf] Query: Condition bytesize limit in videobuf_reqbufs -> buf_setup() call?
Hi Sergio, On Thursday 06 May 2010 01:29:54 Aguirre, Sergio wrote: > > -Original Message- > > From: Mauro Carvalho Chehab [mailto:mche...@redhat.com] > > Sent: Wednesday, May 05, 2010 6:24 PM > > To: Aguirre, Sergio > > Cc: linux-media@vger.kernel.org > > Subject: Re: [videobuf] Query: Condition bytesize limit in > > videobuf_reqbufs -> buf_setup() call? > > > > Aguirre, Sergio wrote: > > > Hi all, > > > > > > While working on an old port of the omap3 camera-isp driver, > > > I have faced some problem. > > > > > > Basically, when calling VIDIOC_REQBUFS with a certain buffer > > > > > > Count, we had a software limit for total size, calculated depending on: > > > Total bytesize = bytesperline x height x count > > > > > > So, we had an arbitrary limit to, say 32 MB, which was generic. > > > > > > Now, we want to condition it ONLY when MMAP buffers will be used. > > > Meaning, we don't want to keep that policy when the kernel is not > > > allocating the space > > > > > > But the thing is that, according to videobuf documentation, buf_setup > > > is the one who should put a RAM usage limit. BUT the memory type > > > passed to reqbufs is not propagated to buf_setup, therefore forcing me > > > to go to a non-standard memory limitation in my reqbufs callback > > > function, instead of doing it properly inside buf_setup. > > > > > > Is this scenario a good consideration to change buf_setup API, and > > > propagate buffers memory type aswell? > > > > I don't see any problem on propagating the memory type to buffer_setup, > > if this is really needed. Yet, I can't see why you would restrict the > > buffer size to 32 MB on one case, and not restrict the size at all with > > non-MMAP types. > > Ok, my reason for doing that is because I thought that there should be a > memory limit in whichever place you're doing the buffer allocations. > > MMAP is allocating buffers in kernel, so kernel should provide a memory > restriction, if applies. > > USERPTR is allocating buffers in userspace, so userspace should provide a > memory restriction, if applies. I agree with the intend here, but not with the current implementation which has a hardcoded arbitrary limit. Do you think it would be possible to compute a meaningful default limit in the V4L2 core, with a way for userspace to modify it (with root privileges of course) ? -- Regards, Laurent Pinchart -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: [videobuf] Query: Condition bytesize limit in videobuf_reqbufs -> buf_setup() call?
Hi, >Aguirre, Sergio wrote: >Basically, when calling VIDIOC_REQBUFS with a certain buffer >Count, we had a software limit for total size, calculated depending on: > > Total bytesize = bytesperline x height x count > >So, we had an arbitrary limit to, say 32 MB, which was generic. > >Now, we want to condition it ONLY when MMAP buffers will be used. >Meaning, we don't want to keep that policy when the kernel is not >allocating the space > >But the thing is that, according to videobuf documentation, buf_setup is >the one who should put a RAM usage limit. BUT the memory type passed to >reqbufs is not propagated to buf_setup, therefore forcing me to go to a >non-standard memory limitation in my reqbufs callback function, instead >of doing it properly inside buf_setup. buf_setup is called during REQBUFS and is indeed the place to limit the size and actually allocate the buffers as well, or at least try to do so, as V4L2 API requires. This is not currently the case with videobuf, but right now we are working to change it. buf_prepare() is called on QBUF and it is definitely too late to do things like that then. It is the REQBUFS that should be failing if the requested number of buffers is too high. You could also (although it's very hacky) just take one of the buffers from vq passed to buf_setup and check its memory field. >Is this scenario a good consideration to change buf_setup API, and >propagate buffers memory type aswell? I agree with Mauro that there should not be a restriction for MMAP only, for the same reasons he already pointed out. As I mentioned, an intensive work is underway to change the buf_* API in videobuf at the moment, so if you have any recommendation/requirements that you feel would be useful, please let us know. Best regards -- Pawel Osciak Linux Platform Group Samsung Poland R&D Center -- 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
