RE: Problems with analog sound on Pinnacle Dazzle TV hybrid USB stick
Hello, I'm having similar issue with another em28xx based analog tv tuner: USB KWorld PVR-TV 305U I will start separate thread for my issue Could you let me know what version of kernel and ALSA are you using? Thanks, tosiara Cite: --- Hi all, I have read serveral newsgroups about this problem and did not find any solution. The closest to a solution was a suggestion to install a em28xx-new module but it is no longer available. I have loaded em28xx em28xx-alsa and em28xx-dvb with this output ( I have forced the card on 56 using options em28xx card=56) [51556.500765] em28xx: New device USB 2881 Video @ 480 Mbps (eb1a:2881, interface 0, class 0) [51556.500949] em28xx #0: chip ID is em2882/em2883 [51556.687042] em28xx #0: i2c eeprom 00: 1a eb 67 95 1a eb 81 28 58 12 5c 00 6a 20 6a 00 [51556.687056] em28xx #0: i2c eeprom 10: 00 00 04 57 64 57 00 00 60 f4 00 00 02 02 00 00 [51556.687068] em28xx #0: i2c eeprom 20: 56 00 01 00 00 00 02 00 b8 00 00 00 5b 1e 00 00 [51556.687080] em28xx #0: i2c eeprom 30: 00 00 20 40 20 80 02 20 10 02 00 00 00 00 00 00 [51556.687091] em28xx #0: i2c eeprom 40: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 [51556.687102] em28xx #0: i2c eeprom 50: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 [51556.687114] em28xx #0: i2c eeprom 60: 00 00 00 00 00 00 00 00 00 00 20 03 55 00 53 00 [51556.687125] em28xx #0: i2c eeprom 70: 42 00 20 00 32 00 38 00 38 00 31 00 20 00 56 00 [51556.687137] em28xx #0: i2c eeprom 80: 69 00 64 00 65 00 6f 00 00 00 00 00 00 00 00 00 [51556.687148] em28xx #0: i2c eeprom 90: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 [51556.687160] em28xx #0: i2c eeprom a0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 [51556.687171] em28xx #0: i2c eeprom b0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 [51556.687182] em28xx #0: i2c eeprom c0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 [51556.687194] em28xx #0: i2c eeprom d0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 [51556.687205] em28xx #0: i2c eeprom e0: 5a 00 55 aa 79 55 54 03 00 17 98 01 00 00 00 00 [51556.687216] em28xx #0: i2c eeprom f0: 0c 00 00 01 00 00 00 00 00 00 00 00 00 00 00 00 [51556.687229] em28xx #0: EEPROM ID= 0x9567eb1a, EEPROM hash = 0xb8846b20 [51556.687232] em28xx #0: EEPROM info: [51556.687234] em28xx #0: AC97 audio (5 sample rates) [51556.687236] em28xx #0: USB Remote wakeup capable [51556.687238] em28xx #0: 500mA max power [51556.687241] em28xx #0: Table at 0x04, strings=0x206a, 0x006a, 0x [51556.687915] em28xx #0: Identified as Pinnacle Hybrid Pro (card=53) [51556.690103] tvp5150 1-005c: chip found @ 0xb8 (em28xx #0) [51556.694727] tuner 1-0061: chip found @ 0xc2 (em28xx #0) [51556.694862] xc2028 1-0061: creating new instance [51556.694864] xc2028 1-0061: type set to XCeive xc2028/xc3028 tuner [51556.694872] usb 2-6: firmware: requesting xc3028-v27.fw [51556.696352] xc2028 1-0061: Loading 80 firmware images from xc3028-v27.fw, type: xc2028 firmware, ver 2.7 [51556.752531] xc2028 1-0061: Loading firmware for type=BASE (1), id . [51557.679461] xc2028 1-0061: Loading firmware for type=(0), id b700. [51557.693080] SCODE (2000), id b700: [51557.693088] xc2028 1-0061: Loading SCODE for type=MONO SCODE HAS_IF_4320 (60008000), id 8000. [51557.900062] em28xx #0: Config register raw data: 0x58 [51557.900812] em28xx #0: AC97 vendor ID = 0x [51557.901178] em28xx #0: AC97 features = 0x6a90 [51557.901181] em28xx #0: Empia 202 AC97 audio processor detected [51558.050427] tvp5150 1-005c: tvp5150am1 detected. [51558.153287] em28xx #0: v4l2 driver version 0.1.2 [51558.237283] em28xx #0: V4L2 video device registered as /dev/video1 [51558.237287] em28xx #0: V4L2 VBI device registered as /dev/vbi1 [51558.250087] usbcore: registered new interface driver em28xx [51558.250092] em28xx driver loaded [51558.420877] xc2028 1-0061: attaching existing instance [51558.420881] xc2028 1-0061: type set to XCeive xc2028/xc3028 tuner [51558.420884] em28xx #0/2: xc3028 attached [51558.420888] DVB: registering new adapter (em28xx #0) [51558.420893] DVB: registering adapter 0 frontend 0 (Zarlink ZL10353 DVB-T)... [51558.421536] Successfully loaded em28xx-dvb [51558.421540] Em28xx: Initialized (Em28xx dvb Extension) extension [51558.421968] Em28xx: Initialized (Em28xx Audio Extension) extension [51560.520457] tvp5150 1-005c: tvp5150am1 detected. [51561.024168] tvp5150 1-005c: tvp5150am1 detected. [51561.332517] xc2028 1-0061: Loading firmware for type=BASE F8MHZ (3), id . [51562.259446] (0), id 00ff: [51562.259452] xc2028 1-0061: Loading firmware for type=(0), id 00010007. [51562.273059] xc2028 1-0061: Loading SCODE for type=MONO SCODE HAS_IF_5320 (60008000), id 000f000 I can get video. I see in alsa a third card (in fact I have a second internal TV capture card) But I cannot get sound out of it. I
em28xx based analog tv tuner USB KWorld PVR-TV 305U (eb1a:e305): no sound
Hello I've made tests with my *KWorld* usb tuner: *Model*: USB KWorld PVR-TV 305U *Vendor/Product id*: [eb1a:e305]. *Tests made*: - Analog video [Worked] - Analog audio [not working, details attached below] Hardware and system details: # lsusb -s 002:003 Bus 002 Device 003: ID eb1a:e305 eMPIA Technology, Inc. # uname -a Linux vista.linuks.lan 2.6.34.7-0.7-desktop #1 SMP PREEMPT 2010-12-13 11:13:53 +0100 i686 athlon i386 GNU/Linux # cat /etc/issue Welcome to openSUSE 11.3 Teal - Kernel \r (\l). ALSA version: 1.0.24.1-72.1 Build latest dvb drivers from linuxtv.org: # lsmod Module Size Used by aes_i5867396 1 aes_generic27151 1 aes_i586 fuse 65789 3 ip6t_LOG5150 11 xt_tcpudp 2107 25 xt_pkttype 912 4 xt_physdev 1539 2 ipt_LOG 5119 11 xt_limit1705 22 rfcomm 69557 4 vboxnetadp 7018 0 vboxnetflt 16967 0 sco16711 2 af_packet 19512 4 bridge 71700 1 stp 1719 1 bridge llc 5093 2 bridge,stp bnep 14764 2 vboxdrv 204362 2 vboxnetadp,vboxnetflt l2cap 53658 16 rfcomm,bnep snd_pcm_oss47613 0 snd_mixer_oss 16751 1 snd_pcm_oss snd_seq57343 0 snd_seq_device 6598 1 snd_seq edd 8720 0 vmnet 46129 13 ppdev 8444 0 parport_pc 33475 0 parport34052 2 ppdev,parport_pc vmblock11886 1 vsock 41336 0 vmci 59117 1 vsock vmmon 76038 0 ip6t_REJECT 4311 3 nf_conntrack_ipv6 18225 4 ip6table_raw1187 1 xt_NOTRACK 816 4 ipt_REJECT 2152 3 xt_state1162 8 iptable_raw 1246 1 iptable_filter 1418 1 ip6table_mangle 1588 0 nf_conntrack_netbios_ns 1382 0 nf_conntrack_ipv4 8691 4 nf_conntrack 75628 5 nf_conntrack_ipv6,xt_NOTRACK,xt_state,nf_conntrack_netbios_ns,nf_conntrack_ipv4 nf_defrag_ipv4 1201 1 nf_conntrack_ipv4 ip_tables 12172 2 iptable_raw,iptable_filter ip6table_filter 1359 1 cpufreq_conservative10064 0 cpufreq_userspace 2583 0 cpufreq_powersave914 0 ip6_tables 13508 4 ip6t_LOG,ip6table_raw,ip6table_mangle,ip6table_filter x_tables 17098 17 ip6t_LOG,xt_tcpudp,xt_pkttype,xt_physdev,ipt_LOG,xt_limit,ip6t_REJECT,ip6table_raw,xt_NOTRACK,ipt_REJECT,xt_state,iptable_raw,iptable_filter,ip6table_mangle,ip_tables,ip6table_filter,ip6_tables powernow_k818707 0 mperf 1255 1 powernow_k8 loop 14694 0 dm_mod 73457 0 em28xx_alsa 6316 0 arc41281 2 tuner_xc2028 20652 1 ecb 1967 2 tuner 18636 1 snd_hda_codec_atihdmi 2591 1 ir_lirc_codec 4075 0 lirc_dev 15476 1 ir_lirc_codec tvp515015288 1 ir_sony_decoder 2005 0 snd_hda_codec_idt 58593 1 ir_jvc_decoder 2098 0 ir_rc6_decoder 2450 0 firewire_ohci 23817 0 firewire_core 52354 1 firewire_ohci crc_itu_t 1435 1 firewire_core snd_hda_intel 24950 3 rc_rc6_mce 1230 0 snd_hda_codec 98635 3 snd_hda_codec_atihdmi,snd_hda_codec_idt,snd_hda_intel snd_hwdep 6164 1 snd_hda_codec em28xx 89777 1 em28xx_alsa snd_pcm87882 4 snd_pcm_oss,em28xx_alsa,snd_hda_intel,snd_hda_codec ir_rc5_decoder 1970 0 ath5k 135497 0 mac80211 248390 1 ath5k ath 8743 1 ath5k ohci1394 30324 0 snd_timer 21669 2 snd_seq,snd_pcm ene_ir 14962 0 snd65788 17 snd_pcm_oss,snd_mixer_oss,snd_seq,snd_seq_device,em28xx_alsa,snd_hda_codec_idt,snd_hda_intel,snd_hda_codec,snd_hwdep,snd_pcm,snd_timer ir_nec_decoder 2386 0 hp_wmi 5882 0 cfg80211 156087 3 ath5k,mac80211,ath v4l2_common10269 3 tuner,tvp5150,em28xx videobuf_vmalloc4868 1 em28xx videobuf_core 18232 2 em28xx,videobuf_vmalloc jmb38x_ms 12491 0 sdhci_pci 7110 0 sdhci 20020 1 sdhci_pci hp_accel 12712 0 lis3lv02d 7908 1 hp_accel uvcvideo 60566 0 soundcore 7379 1 snd snd_page_alloc 8041 2 snd_hda_intel,snd_pcm video 21205 0 btusb 15667 2 bluetooth 96350 9 rfcomm,sco,bnep,l2cap,btusb rfkill 17298 4
Re: [PATCH] Ngene cam device name
Oliver Endriss wrote: Hi, On Saturday 12 March 2011 14:29:08 Andreas Oberritter wrote: On 03/11/2011 10:44 PM, Martin Vidovic wrote: Andreas Oberritter wrote: It's rather unintuitive that some CAMs appear as ca0, while others as cam0. Ngene CI appears as both ca0 and cam0 (or sec0). The ca0 node is used as usual, to setup the CAM. The cam0 (or sec0) node is used to read/write transport stream. To me it looks like an extension of the current API. I see. This raises another problem. How to find out, which ca device cam0 relates to, in case there are more ca devices than cam devices? Hm, I do not see a problem here. The API extension is simple: (1) camX is optional. If camX exists, it is tied to caX. (2) If there is no camX, the CI/CAM operates in 'legacy mode'. (3) If camX exists, the encrypted transport stream of the CI/CAM is sent through camX, and the decrypted stream is received from camX. caX behaves the same way as in (2). Btw, we should choose a more meaningful name for 'camX'. I would prefer something like cainoutX or caioX or cinoutX or cioX. I agree, camX could be misleading since it's not necessarily a CAM application. According to EN 50221 the two interfaces are named Command Interface (for caX) and Transport Stream Interface (for camX). Then maybe 'tsiX' would be an appropriate name? Anyway, 'cioX' sounds good too. Regards, Martin -- 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: WinTV 1400 broken with recent versions?
It means the i2c bus failed to get an ACK back when talking to the xc3028. It could be a number of different things: * broken cx23885 i2c master implementation * bug in the xc3028 driver * screwed up GPIOs causing the xc3028 to be held in reset * i2c bus wedged Ah. Thanks. Now i know what to search for. Also, nobody has any idea what i could try (except for what i already did, including reverting patches and downgrading the kernel)? If you're knowledgeable enough to downgrade the kernel, then your best bet is to learn how to use git bisect so you can identify exactly which patch introduced the regression. Yup, started to try that yesterday, however, going back from today to 2008 will take some time. I'll let you know if i made any progress. Thanks so far. -- 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: [ANN] First draft of the agenda for the Warsaw meeting
On Wednesday, March 09, 2011 21:58:15 Laurent Pinchart wrote: Hi Hans, On Wednesday 09 March 2011 08:47:01 Hans Verkuil wrote: On Wednesday, March 09, 2011 08:08:43 Jaeryul Oh wrote: Hi, Hans We want to confirm if it is possible to discuss our concerning points at each item of 1st draft that you made as below. Our concerning items that we want to discuss are : 1. Issues when using V4l2 control framework with codec : http://www.spinics.net/lists/linux-media/msg27975.html : Can we discuss 'V4l2 control framework to support codec' in your : first agenda ? (Compressed format API for MPEG, H.264, etc. xxx) : We will post related contents in mailing list before joining Warsaw meeting. Certainly. If I am not mistaken the required control framework changes you refer to in the supplied link are actually done in Laurent's media controller/OMAP3 patch series, so these should appear any day now. Im' afraid it's not there yet. The OMAP3 ISP code that requires this feature isn't ready yet, we're still working on it. I've got two patches that implement control handlers at the file handler level for subdevs. I'll send them to the list (as RFC) to be used as a starting point for control handler support at the v4l2_fh level. I did some work on this as well yesterday: http://git.linuxtv.org/hverkuil/media_tree.git?a=shortlog;h=refs/heads/ctrl-event See patch v4l2-ioctl: add ctrl_handler to v4l2_fh I needed this for my work on control-change events. That patch should do what you need provided your code uses struct v4l2_fh for each open file handle. Regards, Hans -- Hans Verkuil - video4linux developer - sponsored by 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
[ANN] Agenda for the Warsaw meeting.
Agenda for V4L2 brainstorm meeting in Warsaw, March 16-18 2011. Purpose of the meeting: to brainstorm about current V4L2 API limitations with regards to required functionality. Ideally the results of the meeting are actual solutions to these problems, but at the very least we should have a concensus of what direction to take and who will continue working on each problem. The hope is that this meeting will save us endless email and irc discussions. It is *not* a summit meeting, so any conclusions need to be discussed and approved on the mailinglist. The basic outline is the same as during previous meetings: the first day we go through all the agenda points and make sure everyone understands the problem. Smaller issues will be discussed and decided, more complex issues are just discussed. The second day we go in depth into the complex issues and try to come up with ideas that might work. The last day we translate the all agenda items into actions. This approach worked well in the past and it ensures that we end up with something concrete. Those who have a vested interest in an agenda item should be prepared to explain their take on it and if necessary have a presentation ready. Besides the main agenda I also added a few items falling under the category 'if time permits'. Attendees: Samsung Poland RD Center: Kamil Debski k.deb...@samsung.com Sylwester Nawrocki s.nawro...@samsung.com Tomasz Stanislawski t.stanisl...@samsung.com Marek Szyprowski (Organizer) m.szyprow...@samsung.com Cisco Systems Norway: Martin Bugge marbu...@cisco.com Hans Verkuil (Chair) hverk...@xs4all.nl Nokia: Sakari Ailus sakari.ai...@maxwell.research.nokia.com Ideas On Board: Laurent Pinchart laurent.pinch...@ideasonboard.com ST-Ericsson: Willy Poisson willy.pois...@stericsson.com Samsung System.LSI Korea Jonghun Han jonghun@samsung.com Jaeryul Oh jaeryul...@samsung.com Samsung DMC Korea: Seung-Woo Kim sw0312@samsung.com Freelance: Guennadi Liakhovetski g.liakhovet...@gmx.de Agenda: 1) Compressed format API for MPEG, H.264, etc. Also need to discuss what to do with weird 'H.264 inside MJPEG' muxed formats. (Hans, Laurent, Samsung) 2) Small architecture enhancements: - Acquiring subdevs from other devices using subdev pool http://www.mail-archive.com/linux-media@vger.kernel.org/msg21831.html (Tomasz) - Introducing subdev hierarchy. Below there is a link to driver using it: http://thread.gmane.org/gmane.linux.drivers.video-input-infrastructure/28885/focus=28890 (Tomasz) - Allow per-filehandle control handlers. http://www.spinics.net/lists/linux-media/msg27975.html (Jaeryul) - How to control FrameBuffer device as v4l2 sub-device? http://thread.gmane.org/gmane.linux.drivers.video-input-infrastructure/29442/focus=29570 (Jaeryul) - Which interface is better for Mixer of Exynos, frame buffer or V4l2? http://www.mail-archive.com/linux-media@vger.kernel.org/msg28549.html (Jaeryul) - Entity information ioctl Some drivers (namely the uvcvideo driver) will need to report driver-specific information about each entity (the UVC entity GUID, the UVC controls it supports, ...). We need an API for that. (Laurent) 3) Pipeline configuration, cropping and scaling: http://www.mail-archive.com/linux-media@vger.kernel.org/msg27956.html http://www.mail-archive.com/linux-media@vger.kernel.org/msg26630.html (Everyone) 4) HDMI receiver/transmitter API support Some hotplug/CEC code can be found here: http://www.mail-archive.com/linux-media@vger.kernel.org/msg28549.html CEC RFC from Cisco Systems Norway: http://www.mail-archive.com/linux-media@vger.kernel.org/msg29241.html Hopefully we can post an initial HDMI RFC as well on Monday. (Martin, Hans, Samsung, ST-Ericsson) 5) Sensor/Flash/Snapshot functionality. http://www.mail-archive.com/linux-media@vger.kernel.org/msg28192.html http://www.mail-archive.com/linux-media@vger.kernel.org/msg28490.html - Sensor blanking/pixel-clock/frame-rate settings (including enumeration/discovery) - Multiple video buffer queues per device (currently implemented in the OMAP 3 ISP driver in non-standard way). - Synchronising parameters (e.g. exposure time and gain) on given frames. Some sensors support this on hardware. There are many use cases which benefit from this, for example this one: URL:http://fcam.garage.maemo.org/ - Flash synchronisation (might fall under the above topic). - Frame metadata. It is important for the control algorithms (exposure, white balance, for example), to know which sensor settings have been used to expose a given frame. Many sensors do support this. Do we want to parse this in the kernel or does it belong to user space? The metadata formats are
Re: em28xx based analog tv tuner USB KWorld PVR-TV 305U (eb1a:e305): no sound
Also tried latest openSUSE 11.4 uname -a Linux linux-tecd.site 2.6.37.1-1.2-desktop #1 SMP PREEMPT 2011-02-21 10:34:10 +0100 i686 athlon i386 GNU/Linux alsa 1.0.24.1-3.1 Still the same issue, Error reading audio: Input/output error On Sun, Mar 13, 2011 at 10:36, tosiara tosi...@gmail.com wrote: Hello I've made tests with my *KWorld* usb tuner: *Model*: USB KWorld PVR-TV 305U *Vendor/Product id*: [eb1a:e305]. *Tests made*: - Analog video [Worked] - Analog audio [not working, details attached below] Hardware and system details: # lsusb -s 002:003 Bus 002 Device 003: ID eb1a:e305 eMPIA Technology, Inc. # uname -a Linux vista.linuks.lan 2.6.34.7-0.7-desktop #1 SMP PREEMPT 2010-12-13 11:13:53 +0100 i686 athlon i386 GNU/Linux # cat /etc/issue Welcome to openSUSE 11.3 Teal - Kernel \r (\l). ALSA version: 1.0.24.1-72.1 Build latest dvb drivers from linuxtv.org: # lsmod Module Size Used by aes_i586 7396 1 aes_generic 27151 1 aes_i586 fuse 65789 3 ip6t_LOG 5150 11 xt_tcpudp 2107 25 xt_pkttype 912 4 xt_physdev 1539 2 ipt_LOG 5119 11 xt_limit 1705 22 rfcomm 69557 4 vboxnetadp 7018 0 vboxnetflt 16967 0 sco 16711 2 af_packet 19512 4 bridge 71700 1 stp 1719 1 bridge llc 5093 2 bridge,stp bnep 14764 2 vboxdrv 204362 2 vboxnetadp,vboxnetflt l2cap 53658 16 rfcomm,bnep snd_pcm_oss 47613 0 snd_mixer_oss 16751 1 snd_pcm_oss snd_seq 57343 0 snd_seq_device 6598 1 snd_seq edd 8720 0 vmnet 46129 13 ppdev 8444 0 parport_pc 33475 0 parport 34052 2 ppdev,parport_pc vmblock 11886 1 vsock 41336 0 vmci 59117 1 vsock vmmon 76038 0 ip6t_REJECT 4311 3 nf_conntrack_ipv6 18225 4 ip6table_raw 1187 1 xt_NOTRACK 816 4 ipt_REJECT 2152 3 xt_state 1162 8 iptable_raw 1246 1 iptable_filter 1418 1 ip6table_mangle 1588 0 nf_conntrack_netbios_ns 1382 0 nf_conntrack_ipv4 8691 4 nf_conntrack 75628 5 nf_conntrack_ipv6,xt_NOTRACK,xt_state,nf_conntrack_netbios_ns,nf_conntrack_ipv4 nf_defrag_ipv4 1201 1 nf_conntrack_ipv4 ip_tables 12172 2 iptable_raw,iptable_filter ip6table_filter 1359 1 cpufreq_conservative 10064 0 cpufreq_userspace 2583 0 cpufreq_powersave 914 0 ip6_tables 13508 4 ip6t_LOG,ip6table_raw,ip6table_mangle,ip6table_filter x_tables 17098 17 ip6t_LOG,xt_tcpudp,xt_pkttype,xt_physdev,ipt_LOG,xt_limit,ip6t_REJECT,ip6table_raw,xt_NOTRACK,ipt_REJECT,xt_state,iptable_raw,iptable_filter,ip6table_mangle,ip_tables,ip6table_filter,ip6_tables powernow_k8 18707 0 mperf 1255 1 powernow_k8 loop 14694 0 dm_mod 73457 0 em28xx_alsa 6316 0 arc4 1281 2 tuner_xc2028 20652 1 ecb 1967 2 tuner 18636 1 snd_hda_codec_atihdmi 2591 1 ir_lirc_codec 4075 0 lirc_dev 15476 1 ir_lirc_codec tvp5150 15288 1 ir_sony_decoder 2005 0 snd_hda_codec_idt 58593 1 ir_jvc_decoder 2098 0 ir_rc6_decoder 2450 0 firewire_ohci 23817 0 firewire_core 52354 1 firewire_ohci crc_itu_t 1435 1 firewire_core snd_hda_intel 24950 3 rc_rc6_mce 1230 0 snd_hda_codec 98635 3 snd_hda_codec_atihdmi,snd_hda_codec_idt,snd_hda_intel snd_hwdep 6164 1 snd_hda_codec em28xx 89777 1 em28xx_alsa snd_pcm 87882 4 snd_pcm_oss,em28xx_alsa,snd_hda_intel,snd_hda_codec ir_rc5_decoder 1970 0 ath5k 135497 0 mac80211 248390 1 ath5k ath 8743 1 ath5k ohci1394 30324 0 snd_timer 21669 2 snd_seq,snd_pcm ene_ir 14962 0 snd 65788 17 snd_pcm_oss,snd_mixer_oss,snd_seq,snd_seq_device,em28xx_alsa,snd_hda_codec_idt,snd_hda_intel,snd_hda_codec,snd_hwdep,snd_pcm,snd_timer ir_nec_decoder 2386 0 hp_wmi 5882 0 cfg80211 156087 3 ath5k,mac80211,ath v4l2_common 10269 3 tuner,tvp5150,em28xx videobuf_vmalloc 4868 1 em28xx videobuf_core 18232 2 em28xx,videobuf_vmalloc jmb38x_ms 12491 0
RE: em28xx based analog tv tuner USB KWorld PVR-TV 305U (eb1a:e305): no sound
similar problem with pinnacle dazzle tv hybrid lsusb : ID eb1a:2881 eMPIA Technology, Inc. EM2881 Video Controller kernel : Linux GCV 2.6.32-25-generic #45-Ubuntu SMP Sat Oct 16 19:52:42 UTC 2010 x86_64 GNU/Linux cardlist : arecord -l List of CAPTURE Hardware Devices card 0: Intel [HDA Intel], device 0: ALC883 Analog [ALC883 Analog] Subdevices: 1/1 Subdevice #0: subdevice #0 card 0: Intel [HDA Intel], device 2: ALC883 Analog [ALC883 Analog] Subdevices: 1/1 Subdevice #0: subdevice #0 card 1: Bt878 [Brooktree Bt878], device 0: Bt87x Digital [Bt87x Digital] Subdevices: 1/1 Subdevice #0: subdevice #0 card 1: Bt878 [Brooktree Bt878], device 1: Bt87x Analog [Bt87x Analog] Subdevices: 1/1 Subdevice #0: subdevice #0 card 2: Video [USB 2881 Video], device 0: USB Audio [USB Audio] Subdevices: 1/1 Subdevice #0: subdevice #0 dmesg output [51556.500765] em28xx: New device USB 2881 Video @ 480 Mbps (eb1a:2881, interface 0, class 0) [51556.500949] em28xx #0: chip ID is em2882/em2883 [51556.687042] em28xx #0: i2c eeprom 00: 1a eb 67 95 1a eb 81 28 58 12 5c 00 6a 20 6a 00 [51556.687056] em28xx #0: i2c eeprom 10: 00 00 04 57 64 57 00 00 60 f4 00 00 02 02 00 00 [51556.687068] em28xx #0: i2c eeprom 20: 56 00 01 00 00 00 02 00 b8 00 00 00 5b 1e 00 00 [51556.687080] em28xx #0: i2c eeprom 30: 00 00 20 40 20 80 02 20 10 02 00 00 00 00 00 00 [51556.687091] em28xx #0: i2c eeprom 40: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 [51556.687102] em28xx #0: i2c eeprom 50: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 [51556.687114] em28xx #0: i2c eeprom 60: 00 00 00 00 00 00 00 00 00 00 20 03 55 00 53 00 [51556.687125] em28xx #0: i2c eeprom 70: 42 00 20 00 32 00 38 00 38 00 31 00 20 00 56 00 [51556.687137] em28xx #0: i2c eeprom 80: 69 00 64 00 65 00 6f 00 00 00 00 00 00 00 00 00 [51556.687148] em28xx #0: i2c eeprom 90: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 [51556.687160] em28xx #0: i2c eeprom a0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 [51556.687171] em28xx #0: i2c eeprom b0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 [51556.687182] em28xx #0: i2c eeprom c0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 [51556.687194] em28xx #0: i2c eeprom d0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 [51556.687205] em28xx #0: i2c eeprom e0: 5a 00 55 aa 79 55 54 03 00 17 98 01 00 00 00 00 [51556.687216] em28xx #0: i2c eeprom f0: 0c 00 00 01 00 00 00 00 00 00 00 00 00 00 00 00 [51556.687229] em28xx #0: EEPROM ID= 0x9567eb1a, EEPROM hash = 0xb8846b20 [51556.687232] em28xx #0: EEPROM info: [51556.687234] em28xx #0: AC97 audio (5 sample rates) [51556.687236] em28xx #0: USB Remote wakeup capable [51556.687238] em28xx #0: 500mA max power [51556.687241] em28xx #0: Table at 0x04, strings=0x206a, 0x006a, 0x [51556.687915] em28xx #0: Identified as Pinnacle Hybrid Pro (card=53) [51556.690103] tvp5150 1-005c: chip found @ 0xb8 (em28xx #0) [51556.694727] tuner 1-0061: chip found @ 0xc2 (em28xx #0) [51556.694862] xc2028 1-0061: creating new instance [51556.694864] xc2028 1-0061: type set to XCeive xc2028/xc3028 tuner [51556.694872] usb 2-6: firmware: requesting xc3028-v27.fw [51556.696352] xc2028 1-0061: Loading 80 firmware images from xc3028-v27.fw, type: xc2028 firmware, ver 2.7 [51556.752531] xc2028 1-0061: Loading firmware for type=BASE (1), id . [51557.679461] xc2028 1-0061: Loading firmware for type=(0), id b700. [51557.693080] SCODE (2000), id b700: [51557.693088] xc2028 1-0061: Loading SCODE for type=MONO SCODE HAS_IF_4320 (60008000), id 8000. [51557.900062] em28xx #0: Config register raw data: 0x58 [51557.900812] em28xx #0: AC97 vendor ID = 0x [51557.901178] em28xx #0: AC97 features = 0x6a90 [51557.901181] em28xx #0: Empia 202 AC97 audio processor detected [51558.050427] tvp5150 1-005c: tvp5150am1 detected. [51558.153287] em28xx #0: v4l2 driver version 0.1.2 [51558.237283] em28xx #0: V4L2 video device registered as /dev/video1 [51558.237287] em28xx #0: V4L2 VBI device registered as /dev/vbi1 [51558.250087] usbcore: registered new interface driver em28xx [51558.250092] em28xx driver loaded [51558.420877] xc2028 1-0061: attaching existing instance [51558.420881] xc2028 1-0061: type set to XCeive xc2028/xc3028 tuner [51558.420884] em28xx #0/2: xc3028 attached [51558.420888] DVB: registering new adapter (em28xx #0) [51558.420893] DVB: registering adapter 0 frontend 0 (Zarlink ZL10353 DVB-T)... [51558.421536] Successfully loaded em28xx-dvb [51558.421540] Em28xx: Initialized (Em28xx dvb Extension) extension [51558.421968] Em28xx: Initialized (Em28xx Audio Extension) extension [51560.520457] tvp5150 1-005c: tvp5150am1 detected. [51561.024168] tvp5150 1-005c: tvp5150am1 detected. [51561.332517] xc2028 1-0061: Loading firmware for type=BASE F8MHZ (3), id . [51562.259446] (0), id 00ff: [51562.259452] xc2028 1-0061: Loading firmware for type=(0), id
[cron job] v4l-dvb daily build: ERRORS
This message is generated daily by a cron job that builds v4l-dvb for the kernels and architectures in the list below. Results of the daily build of v4l-dvb: date:Sun Mar 13 19:00:20 CET 2011 git hash:41f3becb7bef489f9e8c35284dd88a1ff59b190c gcc version: i686-linux-gcc (GCC) 4.5.1 host hardware:x86_64 host os: 2.6.32.5 linux-git-armv5: OK linux-git-armv5-davinci: OK linux-git-armv5-ixp: OK linux-git-armv5-omap2: OK linux-git-i686: OK linux-git-m32r: OK linux-git-mips: WARNINGS linux-git-powerpc64: OK linux-git-x86_64: OK linux-2.6.31.12-i686: ERRORS linux-2.6.32.6-i686: ERRORS linux-2.6.33-i686: WARNINGS linux-2.6.34-i686: WARNINGS linux-2.6.35.3-i686: WARNINGS linux-2.6.36-i686: WARNINGS linux-2.6.37-i686: WARNINGS linux-2.6.31.12-x86_64: ERRORS linux-2.6.32.6-x86_64: ERRORS linux-2.6.33-x86_64: WARNINGS linux-2.6.34-x86_64: WARNINGS linux-2.6.35.3-x86_64: WARNINGS linux-2.6.36-x86_64: WARNINGS linux-2.6.37-x86_64: WARNINGS spec-git: OK sparse: ERRORS Detailed results are available here: http://www.xs4all.nl/~hverkuil/logs/Sunday.log Full logs are available here: http://www.xs4all.nl/~hverkuil/logs/Sunday.tar.bz2 The V4L-DVB specification from this daily build is here: http://www.xs4all.nl/~hverkuil/spec/media.html -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Problem with saa7134: Asus Tiger revision 1.0, subsys 1043:4857
I seem to have fixed the problem for now. It's the hoary old problem of Mythtv's backend coming up and accessing the cards before the firmware has loaded onto the cards. Adding in a startup delay to myth-backend's init script has solved the problem, for now. The firmware seems to load now on Mythbuntu 10.04 without a problem. Is there some way to put a lock in the driver or even speed up the process of loading the firmware with some command line arguments when the saa7134 driver is 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
Re: Problem with saa7134: Asus Tiger revision 1.0, subsys 1043:4857
Jason Hecker jwhec...@gmail.com wrote: I seem to have fixed the problem for now. It's the hoary old problem of Mythtv's backend coming up and accessing the cards before the firmware has loaded onto the cards. Adding in a startup delay to myth-backend's init script has solved the problem, for now. The firmware seems to load now on Mythbuntu 10.04 without a problem. Is there some way to put a lock in the driver or even speed up the process of loading the firmware with some command line arguments when the saa7134 driver is 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 The ivtv and cx18 driver have that sort of logic in them. Look for init_on_first_open and serialized_open functions that set some firmware loading related bit flags. I'm not sure what saa7134 does, but devloping a patch to add something similar shouldn't be rocket science for anyone with time, test hardware, and motivation. -Andy -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: compilation warnings/errors
On Fri, 11 Mar 2011, Mike Isely wrote: On Fri, 11 Mar 2011, Mauro Carvalho Chehab wrote: /home/mchehab/new_build/v4l/pvrusb2-v4l2.c: In function 'pvr2_v4l2_do_ioctl': /home/mchehab/new_build/v4l/pvrusb2-v4l2.c:798:23: warning: variable 'cap' set but not used [-Wunused-but-set-variable] I will look into these. I'm a little puzzled right now since silly stuff like this usually doesn't get by me. Unfortunately I can't look at it right this minute. Expect to hear from me on Sunday. I looked at these two warnings. It's dead code that should be removed. Amazingly enough, this particular bit of crap has been in the driver, unnoticed, since 2008! I have a pull request coming for more pvrusb2 patches, probably in a few more hours, once I'm done testing. A fix for this will be in the patch set. -Mike -- Mike Isely isely @ isely (dot) net PGP: 03 54 43 4D 75 E5 CC 92 71 16 01 E2 B5 F5 C1 E8 -- 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: Dib7000/mt2266 help
Hi Patrick, Thank you for replying. In answer to your questions: Are you sure it is a driver problem? No but given the very same device on the very same antenna system works ok under Windows it seemed like a good place to start. If the BER stays at this value it could also mean that the channel-configuration is wrong. Are you using a channels.conf which has all parameters set, or are you doing a channel-scan-like tune (all values are set to AUTO). I have attached a copy of the channels.conf file I have been using. It was generated by hand based because the scan and w_scan commands would time out for all stations except C31. The information was obtained from a variety of sources on the internet but mostly from http://igorfuna.com/dvb-t/australia/ I am located in Melbourne Australia. Looking in the file you can see that most paramaters are defined except for inversion which is left as auto. There are usually some adaptations board-designing companies do to improve reception quality (adding external LNAs and things like that) that are of course handled by the Window-driver, because it is created by the manufacturer and not by the Linux-driver, because (in this case) the driver was released by the chip-manufacturer. I agree this could be the case and indeed changing the force_lna_activation module parameter seemed to do nothing which would make me suspect that the lna control GPIO on this device is not that same as what is implemented in the driver. Challenge is there seems to be no information around about the DIB7000 or the MT2266 otherwise I would just trace the connections manually using device pinouts. Is the device toggling between FE_HAS_LOCK and no FE_HAS_LOCK or does it stay constantly at The device stays constantly on FE LOCK after the initial tune. Attached are brief snapshots of tuning using tzap for the different frequencies. Whilst this only shows a few seconds worth of data, the output is more or less the same over an extended period. Please try whether you can achieve the BER lowering by moving the antenna or using a better one. If this helps, it really means that the windows-driver does something more the board. Not really practical to move the antenna its up on a mast and indeed as the existing analogue stations are still transmitting from the same tower I know that I have a good signal with no multipath. Other TV sets with digital tuners on the same antenna also report excellent signal levels. I doubt that the chip-driver needs to be changed, more likely the GPIOs of the dib0700 (in dib0700_core.c) or of the dib7000 are used to turn on or off a frequency switch or a LNA. Yes, I suspect that you are right. Challenge is that without any documentation on the devices you are flying blind to reverse engineer the design. Good point, what are the frequencies you're tuning ? The frequencies I have been tuning are listed below but also of interest is that they all use 64QAM whereas the station that works uses QPSK which to me says this is a signal problem and as you state above, probably tied in with a LNA as QPSK is more robust in comparison to 64QAM which is why it has probably been used by C31 as they don't have the need for the higher throughput and have a more modest transmission power compared to the others.So they get more bang for their buck but have the down side of only a single SD stream. C31 557.625 MHz QPSK Works ok. ABC 226.5 MHz 64QAMDoesn't work 7 177.5 MHz 64QAMDoesn't work 9 191.625 MHz 64QAMDoesn't work 10219.5 MHz 64QAMDoesn't work SBS 536.625 Mhz 64QAMDoesn't work Happy to hear your or anyone else's thoughts. Regards Pete From: pboettc...@kernellabs.com To: peter_tille...@hotmail.com; linux-media@vger.kernel.org Subject: Re: Dib7000/mt2266 help Date: Sat, 12 Mar 2011 16:47:40 +0100 Hi Peter, (adding back the list to CC) On Saturday 12 March 2011 11:48:38 Peter Tilley wrote: Hi Patrick, My sincerest apologies for coming to you directly but I have tried the Linux mailing list and received no response and noticed you seem to have been heavily involved with much of the Dibcom driver development. I have an issue with a dual tuner which is sold under the brand of Kaiser Baas KBA01004 but identifies itself as 1164:1e8c which is a Yaun device and this device seems to have already been included in the driver files. It loads ok and reports not problems. It tunes ok and reports FE lock on all channels however on all but one channel upon receiving FE lock the BER stays at 1 instead of dropping to a low number which would indicate I am not getting viterbi. The device is fitted with pairs of MT2266 and DIB7000 which I have positive identified by opening the USB stick. am more than happy to try and work this out myself however the amount of detail around in support of the Linux drivers is extremely
Re: [linux-dvb] Simultaneous recordings from one frontend
Me TV (https://launchpad.net/me-tv). -- 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: [ANN] Agenda for the Warsaw meeting.
B) Use of V4L2 as a frontend for SW/DSP codecs (Laurent) This would be good. Realtek's RT2832U chip can tune to and possibly demodulate DAB/DAB+ and FM along with the usual DVB-T. Realtek does support DAB and FM in Windows with this part but not in Linux and in spite of promises from one of their developers I haven't seen anything from them. I think it'd be good to get this part talking to the DAB processing routines in OpenDAB or OpenMoko as I strongly suspect the part can tune to and provide a digital version of the bandband signal for demodulation of DAB or FM in user space. It might be a good opportunity to get a signal processing framework into the driver but I suspect an API to allow a user space demodulator to read ADC baseband data from such a device would be best and safest. -- 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/8] ARM: S5PV310: Add clock support for MFC v5.1
Hi Kgene,
I see, I will re-work based on lastest 'for-next' ASAP.
Thanks.
BRs.
/jtpark
-Original Message-
From: linux-samsung-soc-ow...@vger.kernel.org [mailto:linux-samsung-soc-
ow...@vger.kernel.org] On Behalf Of Kukjin Kim
Sent: Saturday, March 12, 2011 11:41 AM
To: 'Jeongtae Park'; linux-media@vger.kernel.org; linux-samsung-
s...@vger.kernel.org
Cc: k.deb...@samsung.com; jaeryul...@samsung.com; ben-li...@fluff.org;
jonghun@samsung.com; 'Marek Szyprowski'
Subject: RE: [PATCH v2 2/8] ARM: S5PV310: Add clock support for MFC v5.1
Jeongtae Park wrote:
This patch adds clock support for MFC v5.1.
Reviewed-by: Peter Oh jaeryul...@samsung.com
Signed-off-by: Jeongtae Park jtp.p...@samsung.com
Cc: Marek Szyprowski m.szyprow...@samsung.com
Cc: Kamil Debski k.deb...@samsung.com
---
arch/arm/mach-s5pv310/clock.c | 68
+++
arch/arm/mach-s5pv310/include/mach/regs-clock.h |3 +
2 files changed, 71 insertions(+), 0 deletions(-)
diff --git a/arch/arm/mach-s5pv310/clock.c
b/arch/arm/mach-s5pv310/clock.c
index fc7c2f8..88c7943 100644
--- a/arch/arm/mach-s5pv310/clock.c
+++ b/arch/arm/mach-s5pv310/clock.c
@@ -86,6 +86,11 @@ static int s5pv310_clk_ip_cam_ctrl(struct clk *clk,
int
enable)
return s5p_gatectrl(S5P_CLKGATE_IP_CAM, clk, enable);
}
+static int s5pv310_clk_ip_mfc_ctrl(struct clk *clk, int enable)
+{
+ return s5p_gatectrl(S5P_CLKGATE_IP_MFC, clk, enable);
+}
+
static int s5pv310_clk_ip_image_ctrl(struct clk *clk, int enable)
{
return s5p_gatectrl(S5P_CLKGATE_IP_IMAGE, clk, enable);
@@ -417,6 +422,11 @@ static struct clk init_clocks_off[] = {
.enable = s5pv310_clk_ip_cam_ctrl,
.ctrlbit= (1 2),
}, {
+ .name = mfc,
+ .id = -1,
+ .enable = s5pv310_clk_ip_mfc_ctrl,
+ .ctrlbit= (1 0),
+ }, {
.name = fimc,
.id = 3,
.enable = s5pv310_clk_ip_cam_ctrl,
@@ -643,6 +653,54 @@ static struct clksrc_sources clkset_group = {
.nr_sources = ARRAY_SIZE(clkset_group_list),
};
+static struct clk *clkset_mout_mfc0_list[] = {
+ [0] = clk_mout_mpll.clk,
+ [1] = clk_sclk_apll.clk,
+};
+
+static struct clksrc_sources clkset_mout_mfc0 = {
+ .sources= clkset_mout_mfc0_list,
+ .nr_sources = ARRAY_SIZE(clkset_mout_mfc0_list),
+};
+
+static struct clksrc_clk clk_mout_mfc0 = {
+ .clk= {
+ .name = mout_mfc0,
+ .id = -1,
+ },
+ .sources= clkset_mout_mfc0,
+ .reg_src= { .reg = S5P_CLKSRC_MFC, .shift = 0, .size = 1 },
+};
+
+static struct clk *clkset_mout_mfc1_list[] = {
+ [0] = clk_mout_epll.clk,
+ [1] = clk_sclk_vpll.clk,
+};
+
+static struct clksrc_sources clkset_mout_mfc1 = {
+ .sources= clkset_mout_mfc1_list,
+ .nr_sources = ARRAY_SIZE(clkset_mout_mfc1_list),
+};
+
+static struct clksrc_clk clk_mout_mfc1 = {
+ .clk= {
+ .name = mout_mfc1,
+ .id = -1,
+ },
+ .sources= clkset_mout_mfc1,
+ .reg_src= { .reg = S5P_CLKSRC_MFC, .shift = 4, .size = 1 },
+};
+
+static struct clk *clkset_mout_mfc_list[] = {
+ [0] = clk_mout_mfc0.clk,
+ [1] = clk_mout_mfc1.clk,
+};
+
+static struct clksrc_sources clkset_mout_mfc = {
+ .sources= clkset_mout_mfc_list,
+ .nr_sources = ARRAY_SIZE(clkset_mout_mfc_list),
+};
+
static struct clk *clkset_mout_g2d0_list[] = {
[0] = clk_mout_mpll.clk,
[1] = clk_sclk_apll.clk,
@@ -814,6 +872,14 @@ static struct clksrc_clk clksrcs[] = {
.reg_div = { .reg = S5P_CLKDIV_CAM, .shift = 28, .size = 4
},
}, {
.clk= {
+ .name = sclk_mfc,
+ .id = -1,
+ },
+ .sources = clkset_mout_mfc,
+ .reg_src = { .reg = S5P_CLKSRC_MFC, .shift = 8, .size = 1 },
+ .reg_div = { .reg = S5P_CLKDIV_MFC, .shift = 0, .size = 4 },
+ }, {
+ .clk= {
.name = sclk_cam,
.id = 0,
.enable = s5pv310_clksrc_mask_cam_ctrl,
@@ -1018,6 +1084,8 @@ static struct clksrc_clk *sysclks[] = {
clk_dout_mmc2,
clk_dout_mmc3,
clk_dout_mmc4,
+ clk_mout_mfc0,
+ clk_mout_mfc1,
};
static int xtal_rate;
diff --git a/arch/arm/mach-s5pv310/include/mach/regs-clock.h
b/arch/arm/mach-
s5pv310/include/mach/regs-clock.h
index b5c4ada..27b02e8 100644
--- a/arch/arm/mach-s5pv310/include/mach/regs-clock.h
+++ b/arch/arm/mach-s5pv310/include/mach/regs-clock.h
@@ -33,6 +33,7 @@
#define S5P_CLKSRC_TOP0
Re: [ANN] Agenda for the Warsaw meeting.
On Sun, Mar 13, 2011 at 8:31 AM, Hans Verkuil hverk...@xs4all.nl wrote: Agenda for V4L2 brainstorm meeting in Warsaw, March 16-18 2011. Purpose of the meeting: to brainstorm about current V4L2 API limitations with regards to required functionality. Ideally the results of the meeting are actual solutions to these problems, but at the very least we should have a concensus of what direction to take and who will continue working on each problem. The hope is that this meeting will save us endless email and irc discussions. It is *not* a summit meeting, so any conclusions need to be discussed and approved on the mailinglist. The basic outline is the same as during previous meetings: the first day we go through all the agenda points and make sure everyone understands the problem. Smaller issues will be discussed and decided, more complex issues are just discussed. The second day we go in depth into the complex issues and try to come up with ideas that might work. The last day we translate the all agenda items into actions. This approach worked well in the past and it ensures that we end up with something concrete. Those who have a vested interest in an agenda item should be prepared to explain their take on it and if necessary have a presentation ready. Besides the main agenda I also added a few items falling under the category 'if time permits'. Attendees: Samsung Poland RD Center: Kamil Debski k.deb...@samsung.com Sylwester Nawrocki s.nawro...@samsung.com Tomasz Stanislawski t.stanisl...@samsung.com Marek Szyprowski (Organizer) m.szyprow...@samsung.com Cisco Systems Norway: Martin Bugge marbu...@cisco.com Hans Verkuil (Chair) hverk...@xs4all.nl Nokia: Sakari Ailus sakari.ai...@maxwell.research.nokia.com Ideas On Board: Laurent Pinchart laurent.pinch...@ideasonboard.com ST-Ericsson: Willy Poisson willy.pois...@stericsson.com Samsung System.LSI Korea Jonghun Han jonghun@samsung.com Jaeryul Oh jaeryul...@samsung.com Samsung DMC Korea: Seung-Woo Kim sw0312@samsung.com Freelance: Guennadi Liakhovetski g.liakhovet...@gmx.de Agenda: 1) Compressed format API for MPEG, H.264, etc. Also need to discuss what to do with weird 'H.264 inside MJPEG' muxed formats. (Hans, Laurent, Samsung) 2) Small architecture enhancements: - Acquiring subdevs from other devices using subdev pool http://www.mail-archive.com/linux-media@vger.kernel.org/msg21831.html (Tomasz) - Introducing subdev hierarchy. Below there is a link to driver using it: http://thread.gmane.org/gmane.linux.drivers.video-input-infrastructure/28885/focus=28890 (Tomasz) - Allow per-filehandle control handlers. http://www.spinics.net/lists/linux-media/msg27975.html (Jaeryul) - How to control FrameBuffer device as v4l2 sub-device? http://thread.gmane.org/gmane.linux.drivers.video-input-infrastructure/29442/focus=29570 (Jaeryul) - Which interface is better for Mixer of Exynos, frame buffer or V4l2? http://www.mail-archive.com/linux-media@vger.kernel.org/msg28549.html (Jaeryul) - Entity information ioctl Some drivers (namely the uvcvideo driver) will need to report driver-specific information about each entity (the UVC entity GUID, the UVC controls it supports, ...). We need an API for that. (Laurent) 3) Pipeline configuration, cropping and scaling: http://www.mail-archive.com/linux-media@vger.kernel.org/msg27956.html http://www.mail-archive.com/linux-media@vger.kernel.org/msg26630.html (Everyone) 4) HDMI receiver/transmitter API support Some hotplug/CEC code can be found here: http://www.mail-archive.com/linux-media@vger.kernel.org/msg28549.html CEC RFC from Cisco Systems Norway: http://www.mail-archive.com/linux-media@vger.kernel.org/msg29241.html Hopefully we can post an initial HDMI RFC as well on Monday. (Martin, Hans, Samsung, ST-Ericsson) 5) Sensor/Flash/Snapshot functionality. http://www.mail-archive.com/linux-media@vger.kernel.org/msg28192.html http://www.mail-archive.com/linux-media@vger.kernel.org/msg28490.html - Sensor blanking/pixel-clock/frame-rate settings (including enumeration/discovery) - Multiple video buffer queues per device (currently implemented in the OMAP 3 ISP driver in non-standard way). - Synchronising parameters (e.g. exposure time and gain) on given frames. Some sensors support this on hardware. There are many use cases which benefit from this, for example this one: URL:http://fcam.garage.maemo.org/ - Flash synchronisation (might fall under the above topic). - Frame metadata. It is important for the control algorithms (exposure, white balance, for example), to know which sensor settings have been used to expose a given frame. Many sensors do support
[GIT PATCHES FOR 2.6.39] pvrusb2 driver fixes / improvements
Mauro: Please pull the following patches. Note also that the Implement support for Terratec Grabster AV400 is not as big of a change as it might sound. The work to implement that really amounted to just some extra table entries, plus those changes have been out in the wild via the standalone pvrusb2 driver for quite some time. Getting that into the kernel is long overdue. -Mike The following changes since commit 41f3becb7bef489f9e8c35284dd88a1ff59b190c: Hans Verkuil (1): [media] V4L DocBook: update V4L2 version are available in the git repository at: git://git.linuxtv.org/mcisely/pvrusb2-dev.git pvrusb2-merge-2 Mike Isely (2): pvrusb2: Implement support for Terratec Grabster AV400 pvrusb2: Remove dead code Xiaochen Wang (1): pvrusb2: check kmalloc return value drivers/media/video/pvrusb2/pvrusb2-cx2584x-v4l.c | 18 +++ drivers/media/video/pvrusb2/pvrusb2-devattr.c | 24 + drivers/media/video/pvrusb2/pvrusb2-hdw.c | 24 ++--- drivers/media/video/pvrusb2/pvrusb2-v4l2.c|2 - 4 files changed, 58 insertions(+), 10 deletions(-) -- Mike Isely isely @ isely (dot) net PGP: 03 54 43 4D 75 E5 CC 92 71 16 01 E2 B5 F5 C1 E8 -- 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: Yet another memory provider: can linaro organize a meeting?
On Tue, Mar 8, 2011 at 12:23 PM, Hans Verkuil hverk...@xs4all.nl wrote: On Tuesday, March 08, 2011 15:01:10 Andy Walls wrote: On Tue, 2011-03-08 at 09:13 +0100, Hans Verkuil wrote: Hi all, We had a discussion yesterday regarding ways in which linaro can assist V4L2 development. One topic was that of sorting out memory providers like GEM and HWMEM. Today I learned of yet another one: UMP from ARM. http://blogs.arm.com/multimedia/249-making-the-mali-gpu-device-driver-open-source/page__cid__133__show__newcomment/ This is getting out of hand. I think that organizing a meeting to solve this mess should be on the top of the list. Companies keep on solving the same problem time and again and since none of it enters the mainline kernel any driver using it is also impossible to upstream. All these memory-related modules have the same purpose: make it possible to allocate/reserve large amounts of memory and share it between different subsystems (primarily framebuffer, GPU and V4L). I'm not sure that's the entire story regarding what the current allocators for GPU do. TTM and GEM create in kernel objects that can be passed between applications. TTM apparently has handling for VRAM (video RAM). GEM uses anonymous userspace memory that can be swapped out. TTM: http://lwn.net/Articles/257417/ http://www.x.org/wiki/ttm http://nouveau.freedesktop.org/wiki/TTMMemoryManager?action=AttachFiledo=gettarget=mm.pdf http://nouveau.freedesktop.org/wiki/TTMMemoryManager?action=AttachFiledo=gettarget=xdevconf2006.pdf GEM: http://lwn.net/Articles/283798/ GEM vs. TTM: http://lwn.net/Articles/283793/ The current TTM and GEM allocators appear to have API and buffer processing and management functions tied in with memory allocation. TTM has fences for event notification of buffer processing completion. (maybe something v4l2 can do with v4l2_events?) GEM tries avoid mapping buffers to userspace. (sounds like the v4l2 mem to mem API?) Thanks to the good work of developers on the LMML in the past year or two, V4L2 has separated out some of that functionality from video buffer allocation: video buffer queue management and userspace access (videobuf2) memory to memory buffer transformation/movement (m2m) event notification (VIDIOC_SUBSCRIBE_EVENT) http://lwn.net/Articles/389081/ http://lwn.net/Articles/420512/ It really shouldn't be that hard to get everyone involved together and settle on a single solution (either based on an existing proposal or create a 'the best of' vendor-neutral solution). Single might be making the problem impossibly hard to solve well. One-size-fits-all solutions have a tendency to fall short on meeting someone's critical requirement. I will agree that less than n, for some small n, is certainly desirable. Actually, I think we really need one solution. I don't see how you can have it any other way without requiring e.g. gstreamer to support multiple 'solutions'. The memory allocators and managers are ideally satisfying the requirements imposed by device hardware, what userspace applications are expected to do with the buffers, and system performance. (And maybe the platform architecture, I/O bus, and dedicated video memory?) We discussed this before at the V4L2 brainstorm meeting in Oslo. The idea was to have opaque buffer IDs (more like cookies) that both kernel and userspace can use. You have some standard operations you can do with that and tied to the buffer is the knowledge (probably a set of function pointers in practice) of how to do each operation. So a buffer referring to video memory might have different code to e.g. obtain the virtual address compared to a buffer residing in regular memory. This way you would hide all these details while still have enough flexibility. It also allows you to support 'hidden' memory. It is my understanding that on some platforms (particular those used for set-top boxes) the video buffers are on memory that is not accessible from the CPU (rights management related). But apparently you still have to be able to refer to it. I may be wrong, it's something I was told. A related example is vram on GPUs. Often, the CPU can only mmap the region of vram that is covered by the PCI framebuffer BAR, but the GPU can access the entire vram pool. As such in order to access the buffer using the CPU, you either have to migrate it to a mappable region of vram using the GPU (using a dma engine or a blit), or migrate the buffer to another memory pool (such as gart memory - system memory that is remapped into a linear aperture on the GPU). Alex I am currently aware of the following solutions floating around the net that all solve different parts of the problem: In the kernel: GEM and TTM. Out-of-tree: HWMEM, UMP, CMA, VCM, CMEM, PMEM. Prior to a meeting one would probably want to capture for each allocator: 1. What are
Re: Yet another memory provider: can linaro organize a meeting?
On Tue, Mar 8, 2011 at 9:01 AM, Andy Walls awa...@md.metrocast.net wrote: On Tue, 2011-03-08 at 09:13 +0100, Hans Verkuil wrote: Hi all, We had a discussion yesterday regarding ways in which linaro can assist V4L2 development. One topic was that of sorting out memory providers like GEM and HWMEM. Today I learned of yet another one: UMP from ARM. http://blogs.arm.com/multimedia/249-making-the-mali-gpu-device-driver-open-source/page__cid__133__show__newcomment/ This is getting out of hand. I think that organizing a meeting to solve this mess should be on the top of the list. Companies keep on solving the same problem time and again and since none of it enters the mainline kernel any driver using it is also impossible to upstream. All these memory-related modules have the same purpose: make it possible to allocate/reserve large amounts of memory and share it between different subsystems (primarily framebuffer, GPU and V4L). I'm not sure that's the entire story regarding what the current allocators for GPU do. TTM and GEM create in kernel objects that can be passed between applications. TTM apparently has handling for VRAM (video RAM). GEM uses anonymous userspace memory that can be swapped out. TTM can handle pretty much any type of memory, it's just a basic memory manager. You specify things cacheability attributes when you set up the pools. Generally on GPUs we see 3 types of buffers: 1. video ram connected to the GPU. Often some or all of that pool is not accessible by the CPU. The GPU usually provides a mechanism to migrate the buffer to a pool or region that is accessible to the CPU. Vram buffers are usually mapped uncached write-combined. 2. GART/GTT (Graphics Address Remapping Table) memory. This is DMAable system memory that is mapped into the GPU's address space and remapped to look linear to the GPU. It can either be cached or uncached pages depending on the GPU's capabilities and what the buffers are used for. 3. unpinned system pages. Depending on the GPU, they have to be copied to DMAable memory before the GPU can access them. The DRI protocol (used for communication between GPU acceleration drivers) doesn't really care what the underlying memory manager is. It just passes around handles. Alex TTM: http://lwn.net/Articles/257417/ http://www.x.org/wiki/ttm http://nouveau.freedesktop.org/wiki/TTMMemoryManager?action=AttachFiledo=gettarget=mm.pdf http://nouveau.freedesktop.org/wiki/TTMMemoryManager?action=AttachFiledo=gettarget=xdevconf2006.pdf GEM: http://lwn.net/Articles/283798/ GEM vs. TTM: http://lwn.net/Articles/283793/ The current TTM and GEM allocators appear to have API and buffer processing and management functions tied in with memory allocation. TTM has fences for event notification of buffer processing completion. (maybe something v4l2 can do with v4l2_events?) GEM tries avoid mapping buffers to userspace. (sounds like the v4l2 mem to mem API?) Thanks to the good work of developers on the LMML in the past year or two, V4L2 has separated out some of that functionality from video buffer allocation: video buffer queue management and userspace access (videobuf2) memory to memory buffer transformation/movement (m2m) event notification (VIDIOC_SUBSCRIBE_EVENT) http://lwn.net/Articles/389081/ http://lwn.net/Articles/420512/ It really shouldn't be that hard to get everyone involved together and settle on a single solution (either based on an existing proposal or create a 'the best of' vendor-neutral solution). Single might be making the problem impossibly hard to solve well. One-size-fits-all solutions have a tendency to fall short on meeting someone's critical requirement. I will agree that less than n, for some small n, is certainly desirable. The memory allocators and managers are ideally satisfying the requirements imposed by device hardware, what userspace applications are expected to do with the buffers, and system performance. (And maybe the platform architecture, I/O bus, and dedicated video memory?) I am currently aware of the following solutions floating around the net that all solve different parts of the problem: In the kernel: GEM and TTM. Out-of-tree: HWMEM, UMP, CMA, VCM, CMEM, PMEM. Prior to a meeting one would probably want to capture for each allocator: 1. What are the attributes of the memory allocated by this allocator? 2. For what domain was this allocator designed: GPU, video capture, video decoder, etc. 3. How are applications expected to use objects from this allocator? 4. What are the estimated sizes and lifetimes of objects that would be allocated this allocator? 5. Beyond memory allocation, what other functionality is built into this allocator: buffer queue management, event notification, etc.? 6. Of the requirements that this allocator satisfies, what are the performance critical requirements? Maybe there are
