SkyStar HD2 tv playback runs jerky - Subsystem: Device 1ae4:0003
Hello, i have a Technisat SkyStar HD2 DVB-S2 tv card and it is working rather poorly on my Linux Ubuntu 11.04 system (Linux Kernel version 2.6.38 that is shipped via the official Ubuntu repository) Scanning for channels worked. TV programs show up, but they're out of sync and audio shatters extremely and runs jerky. Recording the TV program or just watching it is a waste of time because of the above quality problems. I tested several dvb player software like mplayer, xine, vlc, kaffeine and totem (with dvb plugin) but all have the same problem. On Windows this card works perfectly with the dvbviewer application. On http://linuxtv.org/wiki/index.php/Azurewave_AD_SP400_CI_%28VP-1041% 29#Identification i found the following text: Note also that a different subsystem ID for a Skystar HD2 (1ae4:0003) has been reported for some cards at http://www.linuxtv.org/pipermail/linux-dvb/2008-July/027261.html so perhaps a change needs to be made to allow for this possibility too. and i also read the additional mailinglist report: http://www.linuxtv.org/pipermail/linux-dvb/2008-July/027261.html http://www.linuxtv.org/pipermail/linux-dvb/2008-July/027279.html And i can confirm that, what is in this report. My Skystar HD2 has the ID (1ae4:0003) too. lspci -vv 05:00.0 Multimedia controller: Twinhan Technology Co. Ltd Mantis DTV PCI Bridge Controller [Ver 1.0] (rev 01) Subsystem: Device 1ae4:0003 Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- DisINTx- Status: Cap- 66MHz- UDF- FastB2B- ParErr- DEVSEL=medium TAbort- TAbort- MAbort- SERR- PERR- INTx- Latency: 32 (2000ns min, 63750ns max) Interrupt: pin A routed to IRQ 20 Region 0: Memory at f220 (32-bit, prefetchable) [size=4K] Kernel driver in use: Mantis Kernel modules: mantis lspci -vvn 05:00.0 0480: 1822:4e35 (rev 01) Subsystem: 1ae4:0003 Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- DisINTx- Status: Cap- 66MHz- UDF- FastB2B- ParErr- DEVSEL=medium TAbort- TAbort- MAbort- SERR- PERR- INTx- Latency: 32 (2000ns min, 63750ns max) Interrupt: pin A routed to IRQ 20 Region 0: Memory at f220 (32-bit, prefetchable) [size=4K] Kernel driver in use: Mantis Kernel modules: mantis lsmod | grep mantis mantis 23328 0 mantis_core40423 1 mantis dvb_core 110487 1 mantis_core rc_core26918 7 ir_lirc_codec,mantis_core,ir_sony_decoder,ir_jvc_decoder,ir_rc6_decoder,ir_rc5_decoder,ir_nec_decoder ls -l /dev/dvb/adapter0/ insgesamt 0 crw-rw+ 1 root video 212, 0 2012-02-23 08:17 demux0 crw-rw+ 1 root video 212, 1 2012-02-23 08:17 dvr0 crw-rw+ 1 root video 212, 3 2012-02-23 08:17 frontend0 crw-rw+ 1 root video 212, 2 2012-02-23 08:17 net0 dmesg [6.240921] Mantis :05:00.0: PCI INT A - GSI 20 (level, low) - IRQ 20 [6.241985] DVB: registering new adapter (Mantis DVB adapter) ... [0.331995] pci :05:00.0: [1822:4e35] type 0 class 0x000480 [0.332008] pci :05:00.0: reg 10: [mem 0xf220-0xf2200fff pref] [0.332070] pci :05:02.0: [1102:0004] type 0 class 0x000401 [0.332086] pci :05:02.0: reg 10: [io 0xd000-0xd03f] [0.332146] pci :05:02.0: supports D1 D2 [0.332161] pci :05:02.1: [1102:7003] type 0 class 0x000980 [0.332176] pci :05:02.1: reg 10: [io 0xd100-0xd107] [0.332236] pci :05:02.1: supports D1 D2 [0.332255] pci :05:02.2: [1102:4001] type 0 class 0x000c00 [0.332272] pci :05:02.2: reg 10: [mem 0xf2104000-0xf21047ff] [0.332281] pci :05:02.2: reg 14: [mem 0xf210-0xf2103fff] [0.332337] pci :05:02.2: supports D1 D2 [0.332339] pci :05:02.2: PME# supported from D0 D1 D2 D3hot [0.332343] pci :05:02.2: PME# disabled Undloading and Loading the kernel module: ~$ sudo modprobe -r mantis ~$ lsmod | grep mantis ~$ sudo modprobe -v mantis insmod /lib/modules/2.6.38-13-generic/kernel/drivers/media/dvb/dvb-core/dvb-core.ko insmod /lib/modules/2.6.38-13-generic/kernel/drivers/media/dvb/mantis/mantis_core.ko insmod /lib/modules/2.6.38-13-generic/kernel/drivers/media/dvb/mantis/mantis.ko ~$ lsmod | grep mantis mantis 23328 0 mantis_core40423 1 mantis dvb_core 110487 1 mantis_core rc_core26918 7 mantis_core,ir_lirc_codec,ir_sony_decoder,ir_jvc_decoder,ir_rc6_decoder,ir_rc5_decoder,ir_nec_decoder ~$ kern.log syslog shows then: Feb 23 09:56:17 xxx kernel: [ 5934.470544] Mantis :05:00.0: PCI INT A disabled Feb 23 09:57:19 xxx kernel: [ 5995.614854] Mantis :05:00.0: PCI INT A - GSI 20 (level, low) - IRQ 20 Feb 23 09:57:19 xxx kernel: [ 5995.616286] DVB: registering new adapter (Mantis DVB adapter) Feb 23 09:57:19 xxx kernel: [ 5996.541357] stb0899_attach: Attaching STB0899 Feb 23 09:57:19 xxx
Re: [PATCH 0/3] Support for AF9035/AF9033
Hi Hans, I also have an AF9035 based device, the Asus 3100 Mini Plus. It has an AF9035B demodulator and uses an FCI2580 tuner. I've used the driver supplied by afa in the past, but haven't tested it in the last few months. I have a git repository for that driver at http://git.schinagl.nl/AF903x_SRC.git (it is also linked from http://www.linuxtv.org/wiki/index.php/Asus_U3100_Mini_plus_DVB-T). So when you say it is also coupled with the same tuner, that's not true :) With that driver there where a bunch of other tuners that are used with this chip. I think the Asus EEEPC supported a USB dvb tuner at some point and there are reverences in that code for it. As of the legality of the code, that is uncertain. The module (compiled from all these sources) is very specifically marked as GPL. Most headers/source files have no copyright notice at all, some however do, but no license in it. I asked about afa-tech and there driver status a while ago, but I guess there is no news as of yet? To summarize, I would love to test your driver, and I think i can code something up for my tuner, once these are split? Oliver On 22-02-12 23:20, Hans-Frieder Vogt wrote: I have written a driver for the AF9035 AF9033 (called af903x), based on the various drivers and information floating around for these chips. Currently, my driver only supports the devices that I am able to test. These are - Terratec T5 Ver.2 (also known as T6) - Avermedia Volar HD Nano (A867) The driver supports: - diversity and dual tuner (when the first frontend is used, it is in diversity mode, when two frontends are used in dual tuner mode) - multiple devices - pid filtering - remote control in NEC and RC-6 mode (currently not switchable, but depending on device) - support for kernel 3.1, 3.2 and 3.3 series I have not tried to split the driver in a DVB-T receiver (af9035) and a frontend (af9033), because I do not see the sense in doing that for a demodulator, that seems to be always used in combination with the very same receiver. The patch is split in three parts: Patch 1: support for tuner fitipower FC0012 Patch 2: basic driver Patch 3: firmware Hans-Frieder Vogt e-mail: hfvogtat gmx .dot. net -- 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: [PATCH 3/3] Firmware for AF9035/AF9033 driver
Hi Hans, I'm supprised the AF9035/AF9033 driver requires a firmware. The Asus U3100 Mini plus doesn't require a 'firmware' really. The firmware that is loaded, only contains an IR mapping table. Oliver On 22-02-12 23:22, Hans-Frieder Vogt wrote: Firmware for the AF9035/AF9033 driver. irmware format for af903x driver: copied from it9135-driver by Jason Dong (C) 2011 ITE Technologies, INC. : 8 chars AF9035BXIdentifier of firmware 0008: 4 bytes LE length of firmware following this: 32 + 4 + 4 + 4 + 4 + 4 + Firmware_CODELENGTH + Firmware_SEGMENTLENGTH * Firmware_PARTITIONLENGTH * 5 + 5 + 2 + Firmware_scriptSets[0] * 5; 000C: 32 chars firmware release version 002C: 4 bytes BE link version 0030: 4 bytes BE ofdm version 0034: 4 bytes LE firmware code length (Firmware_CODELENGTH) 0038: 1 bytes number of firmware segments (Firmware_SEGMENTLENGTH) 0039: 3 bytes filler (0) 003C: 1 bytes number of firmware partitions (Firmware_PARTITIONLENGTH) 003D: 3 bytes filler (0) 0040: Firmware_CODELENGTH bytes abcd: description of firmware segments, for each segment in every partition: 1 byte segment type (0: download firmware, 1: copy firmware, else: direct write firmware) 4 bytes LE segment length bcde: 1 byte Firmware_SEGMENTLENGTH check bcdf: 1 byte Firmware_PARTITIONLENGTH check bce0: 3 bytes filler (0) bce3: 2 bytes LE number of firmware (demodulator) scripts bce5: list of firmware scripts, for each entry: 4 bytes LE address 1 byte value Signed-off-by: Hans-Frieder Vogthfv...@gmx.net http://home.arcor.de/hfvogt/af903x/dvb-usb-af9035-03.fw = for Terratec T5 Ver. 2 / T6 http://home.arcor.de/hfvogt/af903x/dvb-usb-af9035-04.fw = for Avermedia A867 Hans-Frieder Vogt e-mail: hfvogtat gmx .dot. net -- 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: Cine CT v6
Thanks Lars, dvb-fe-tool worked great, appreciate the help. Regards Edd On 22/02/2012 17:38, Lars Hanisch wrote: Hi, Am 22.02.2012 14:05, schrieb Edd Barker: Hi Members I've just got a Cine CT v6 card and have having a bit of trouble. I want to use dvb-t only, I've followed the instructions here... http://linuxtv.org/wiki/index.php/Digital_Devices_DuoFlex_C%26T The card is now appearing in /dev/dvb/adapter0 /dev/dvb/adapter1. However only one frontend is showing up and if I try to scan dvb-t I get an error that I'm sure means I'm trying to use dvb-c tuner. WARNING: frontend type (QAM) is not compatible with requested tuning type (OFDM) I'm running on Ubuntu 11.10, 3.0.0-16 kernal. Is this something anyone else has come across or knows what I can do to use the dvb-t frontend? You can use dvb-fe-tool to switch the type of delivery system used as a default for old applications. In the near past the drivers of hybrid cards were changed so there's only one frontend for all delivery systems, since they can only be opened mutually exclusive. There should be an PPA at Launchpad with a recent version of the tools/utils, but I don't have the URL at the moment. Regards, Lars. Thanks Edd -- 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: S5P-TV: Warning for regulator unbalanced disables
Hi Tushar, On Thursday, February 23, 2012 5:43 AM You wrote: After implementing genpd framework for EXYNOS4, (Ref commit 91cfbd4 ARM: EXYNOS: Hook up power domains to generic power domain infrastructure in Kukjin's for-next branch), we are getting following warning from s5p-hdmi driver. The test was done on Origen board with code based on 3.3-rc4 and Kukjin's for-next branch. [1] [ cut here ] WARNING: at drivers/regulator/core.c:1503 _regulator_disable+0xf8/0x164() (snipped) Thanks for the report. We know about this issue. It is not really related to regulators nor s5p-tv driver. There is something broken (or misused) in the gen_pd driver and its implementation for Exysno4 hw. If you dig a bit into the problem You can observe the following call sequence on device probe: exynos4_genpd_enable() s5p_tv_runtime_disable() exynos4_genpd_disable() So the call to s5p_tv_runtime_disable is not balanced with s5p_tv_runtime_resume() what causes the error you have posted. It looks that runtime pw framework makes some wrong assumptions about the state of the device once power domain has been registered. The same problem appears for s5p-fimc and s5p-mfc, although it is not observed as kernel error, but these devices also suffers from it - their clocks get disabled one time too much so they do not operate correctly. We are investigating this issue further. Best regards -- Marek Szyprowski Samsung Poland RD Center The above message is intended solely for the named addressee and may contain trade secret, industrial technology or privileged and confidential information otherwise protected under applicable law. Any unauthorized dissemination, distribution, copying or use of the information contained in this communication is strictly prohibited. If you have received this communication in error, please notify sender by email and delete this communication immediately. Powyższa wiadomość przeznaczona jest wyłącznie dla adresata niniejszej wiadomości i może zawierać informacje będące tajemnicą handlową, tajemnicą przedsiębiorstwa oraz informacje o charakterze poufnym chronione obowiązującymi przepisami prawa. Jakiekolwiek nieuprawnione ich rozpowszechnianie, dystrybucja, kopiowanie lub użycie informacji zawartych w powyższej wiadomości jest zabronione. Jeśli otrzymałeś powyższą wiadomość omyłkowo, uprzejmie proszę poinformuj o tym fakcie drogą mailową nadawcę tej wiadomości oraz niezwłocznie usuń powyższą wiadomość ze swojego komputera.
Re: [PATCH 0/3] Support for AF9035/AF9033
Il 22/02/2012 23:20, Hans-Frieder Vogt ha scritto: I have written a driver for the AF9035 AF9033 (called af903x), based on the various drivers and information floating around for these chips. Currently, my driver only supports the devices that I am able to test. These are - Terratec T5 Ver.2 (also known as T6) - Avermedia Volar HD Nano (A867) The driver supports: - diversity and dual tuner (when the first frontend is used, it is in diversity mode, when two frontends are used in dual tuner mode) - multiple devices - pid filtering - remote control in NEC and RC-6 mode (currently not switchable, but depending on device) - support for kernel 3.1, 3.2 and 3.3 series I have not tried to split the driver in a DVB-T receiver (af9035) and a frontend (af9033), because I do not see the sense in doing that for a demodulator, that seems to be always used in combination with the very same receiver. The patch is split in three parts: Patch 1: support for tuner fitipower FC0012 Patch 2: basic driver Patch 3: firmware Hans-Frieder Vogt e-mail: hfvogt at gmx .dot. net Hi Hans, thank you for the new af903x driver. A few comments: 1) I think you should set up a git repository with your driver and then send a PULL request to the list; as it is, the first patch is affected by line-wrapping problems so it must be manually edited to be applicable, and the second patch is compressed so it will be ignored by patchwork. 2) There are a couple of small errors in the patches (see my attached patches): in the dvb-usb Makefile, DVB_USB_AF903X must be replaced by CONFIG_DVB_USB_AF903X otherwise the driver will not compile; also, in the dvb_frontend_ops struct, the field info.type should be removed for kernels = 3.3.0. 3) The USB VID/PID IDs should be moved into dvb-usb-ids.h (see patch 3); I also added a few IDs from the Avermedia A867 driver*. As your driver supports both AF9007 and mxl5007t tuners I think this is safe. *http://www.avermedia.com/Support/DownloadCount.aspx?FDFId=4591 4) the driver also looks for a firmware file called af35irtbl.bin that comes from the official ITEtech driver (if it's not present the driver works anyway, but it prints an error message); I tested the driver with an Avermedia A867 stick (it's an OEM stick also known as the Sky Italia Digital Key with blue led: 07ca:a867) on a Ubuntu 10.04 system with kernel 2.6.32-38-generic-pae and the latest media_build tree installed. The good news: the driver loads properly, and, using Kaffeine, I could watch several channels with a small portable antenna; I could also perform a full frequency scan, finding several UHF and VHF stations. Signal strength and SNR reports works really well, and they seems to give a realistic figure of the signal quality (with both the portable and the rooftop antenna). When the stick is unplugged from the USB port, the driver unloads properly. The bad news: the driver seems to lock the application when it tries to tune a weak channel: in this cases, Kaffeine becomes unresponsive and sometimes it gives a stream error; for the same reason, the full scan fails to find all stations and takes a long time to complete. Also, when I tried to extract the stick from the USB port during one of this freezing periods, the system crashed :-( I reproduced this bug 3 times, and the last time I was able to see a kernel dump for a moment: the function that crashed the kernel was af903x_streaming_ctrl. Neither of those issues are present with the Avermedia A867 original driver or Antti Palosaari's af9035 driver modified to support the A867 stick. I hope this feedback will be useful to improve the driver. Best regards, Gianluca Gennari [PATCH 1/3] af903x: fixed Makefile Signed-off-by: Gianluca Gennari gennar...@gmail.com --- drivers/media/dvb/dvb-usb/Makefile |2 +- 1 files changed, 1 insertions(+), 1 deletions(-) diff --git a/drivers/media/dvb/dvb-usb/Makefile b/drivers/media/dvb/dvb-usb/Makefile index 75780e2..49c5425 100644 --- a/drivers/media/dvb/dvb-usb/Makefile +++ b/drivers/media/dvb/dvb-usb/Makefile @@ -76,7 +76,7 @@ dvb-usb-af9015-objs = af9015.o obj-$(CONFIG_DVB_USB_AF9015) += dvb-usb-af9015.o dvb-usb-af903x-objs = af903x-core.o af903x-devices.o af903x-fe.o af903x-tuners.o -obj-$(DVB_USB_AF903X) += dvb-usb-af903x.o +obj-$(CONFIG_DVB_USB_AF903X) += dvb-usb-af903x.o dvb-usb-cinergyT2-objs = cinergyT2-core.o cinergyT2-fe.o obj-$(CONFIG_DVB_USB_CINERGY_T2) += dvb-usb-cinergyT2.o -- 1.7.0.4 [PATCH 2/3] af903x: removed frontend info.type for kernels = 3.3.0 Signed-off-by: Gianluca Gennari gennar...@gmail.com --- drivers/media/dvb/dvb-usb/af903x-fe.c |2 ++ 1 files changed, 2 insertions(+), 0 deletions(-) diff --git a/drivers/media/dvb/dvb-usb/af903x-fe.c b/drivers/media/dvb/dvb-usb/af903x-fe.c index a782c96..8d58efb 100644 --- a/drivers/media/dvb/dvb-usb/af903x-fe.c +++ b/drivers/media/dvb/dvb-usb/af903x-fe.c @@ -2110,7 +2110,9 @@ static struct
Video Capture Issue
Hi, 1) I am trying to get a HDMI to CSI Bridge chip working with OMAP4 ISS. The issue is the captured frames are completely green in color. 2) The Chip is configured to output VGA Color bar sequence with YUV422-8Bit and uses datalane 0 only. 3) The Format on OMAP4 ISS is UYVY (Register 0x52001074 = 0x0A1E) I am trying to directly dump the data into memory without ISP processing. Please advice. -- Regards, Sriram -- 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: Video Capture Issue
Hi Sriram, On Thu, Feb 23, 2012 at 11:25 AM, Sriram V vshrir...@gmail.com wrote: Hi, 1) I am trying to get a HDMI to CSI Bridge chip working with OMAP4 ISS. The issue is the captured frames are completely green in color. Sounds like the buffer is all zeroes, can you confirm? 2) The Chip is configured to output VGA Color bar sequence with YUV422-8Bit and uses datalane 0 only. 3) The Format on OMAP4 ISS is UYVY (Register 0x52001074 = 0x0A1E) I am trying to directly dump the data into memory without ISP processing. Please advice. Just to be clear on your environment, which branch/commitID are you based on? Regards, Sergio -- Regards, Sriram -- 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: Video Capture Issue
Hi, 1) An Hexdump of the captured file shows 0x55 at all locations. Is there any buffer location i need to check. 2) I have tried with devel branch. 3) Changing the polarities doesnt help either. 4) The sensor is giving out YUV422 8Bit Mode, Will 0x52001074 = 0x0A1E (UYVY Format) it bypass the ISP and dump directly into memory. On 2/23/12, Aguirre, Sergio saagui...@ti.com wrote: Hi Sriram, On Thu, Feb 23, 2012 at 11:25 AM, Sriram V vshrir...@gmail.com wrote: Hi, 1) I am trying to get a HDMI to CSI Bridge chip working with OMAP4 ISS. The issue is the captured frames are completely green in color. Sounds like the buffer is all zeroes, can you confirm? 2) The Chip is configured to output VGA Color bar sequence with YUV422-8Bit and uses datalane 0 only. 3) The Format on OMAP4 ISS is UYVY (Register 0x52001074 = 0x0A1E) I am trying to directly dump the data into memory without ISP processing. Please advice. Just to be clear on your environment, which branch/commitID are you based on? Regards, Sergio -- Regards, Sriram -- 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 -- Regards, Sriram -- 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 0/3] Support for AF9035/AF9033
On 23.02.2012 00:20, Hans-Frieder Vogt wrote: I have written a driver for the AF9035 AF9033 (called af903x), based on the various drivers and information floating around for these chips. Currently, my driver only supports the devices that I am able to test. These are - Terratec T5 Ver.2 (also known as T6) - Avermedia Volar HD Nano (A867) The driver supports: - diversity and dual tuner (when the first frontend is used, it is in diversity mode, when two frontends are used in dual tuner mode) - multiple devices - pid filtering - remote control in NEC and RC-6 mode (currently not switchable, but depending on device) - support for kernel 3.1, 3.2 and 3.3 series I have not tried to split the driver in a DVB-T receiver (af9035) and a frontend (af9033), because I do not see the sense in doing that for a demodulator, that seems to be always used in combination with the very same receiver. That was how I originally implemented it. Reason for that is simple: af9033 demodulator exists as single chip. I think it is also used for dual tuner devices or is there 2 af9035 chips used, like one is master and one is slave and working as a demod? Situation is rather same for af9005/af9003 and af9015/af9013. Search from the mailing list and see there is devices using af9003 demod but as it is not split correctly from the af9005 those devices are never supported (due to fact af9003 demod is not split out). Reason behind my af9035/af9033 is not merged to the Kernel is that I never found people from ITE who was able to give permission to merge that. As it contains some vendor code I didn't want to merge it without permission. It is not many day work to write all vendor code out from the driver and get it clean. If you want I can do it for you and merge that to the Kernel. You can then take whole driver and start hacking if you wish. What do you think? I am currently busy as hell and I don't want more drivers to maintain so you can take maintaining responsibility. The patch is split in three parts: Patch 1: support for tuner fitipower FC0012 Patch 2: basic driver Patch 3: firmware Hans-Frieder Vogt e-mail: hfvogtat gmx .dot. net regards Antti -- http://palosaari.fi/ -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[question] USB video capture reference driver
Hi, I'm doing some work on easycap (staging) driver and I would like to ask which similar driver is available and/or recommended to follow code style and code design. Reading cx231xx driver I noticed that video buffer allocation and ioctl handling are done in a very different way using some v4l facilities. I believe this would be prefered over the current status, right? Thanks, Ezequiel. -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
cron job: media_tree daily build: WARNINGS
This message is generated daily by a cron job that builds media_tree for the kernels and architectures in the list below. Results of the daily build of media_tree: date:Thu Feb 23 19:00:24 CET 2012 git hash:a3db60bcf7671cc011ab4f848cbc40ff7ab52c1e gcc version: i686-linux-gcc (GCC) 4.6.2 host hardware:x86_64 host os: 3.1-2.slh.1-amd64 linux-git-arm-eabi-enoxys: WARNINGS linux-git-arm-eabi-omap: WARNINGS linux-git-armv5-ixp: WARNINGS linux-git-i686: WARNINGS linux-git-m32r: WARNINGS linux-git-mips: WARNINGS linux-git-powerpc64: WARNINGS linux-git-x86_64: WARNINGS linux-2.6.31.12-i686: WARNINGS linux-2.6.32.6-i686: WARNINGS linux-2.6.33-i686: WARNINGS linux-2.6.34-i686: WARNINGS linux-2.6.35.3-i686: WARNINGS linux-2.6.36-i686: WARNINGS linux-2.6.37-i686: WARNINGS linux-2.6.38.2-i686: WARNINGS linux-2.6.39.1-i686: WARNINGS linux-3.0-i686: WARNINGS linux-3.1-i686: WARNINGS linux-3.2.1-i686: WARNINGS linux-3.3-rc1-i686: WARNINGS linux-2.6.31.12-x86_64: WARNINGS linux-2.6.32.6-x86_64: WARNINGS linux-2.6.33-x86_64: WARNINGS linux-2.6.34-x86_64: WARNINGS linux-2.6.35.3-x86_64: WARNINGS linux-2.6.36-x86_64: WARNINGS linux-2.6.37-x86_64: WARNINGS linux-2.6.38.2-x86_64: WARNINGS linux-2.6.39.1-x86_64: WARNINGS linux-3.0-x86_64: WARNINGS linux-3.1-x86_64: WARNINGS linux-3.2.1-x86_64: WARNINGS linux-3.3-rc1-x86_64: WARNINGS apps: WARNINGS spec-git: WARNINGS sparse: 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: linux-next: Tree for Feb 23 (media/radio)
On 02/22/2012 07:37 PM, Stephen Rothwell wrote: Hi all, Changes since 20120222: on i386: Looks like several source files need to #include linux/slab.h: drivers/media/radio/radio-isa.c:246:3: error: implicit declaration of function 'kfree' drivers/media/radio/radio-aztech.c:72:9: error: implicit declaration of function 'kzalloc' drivers/media/radio/radio-aztech.c:72:22: warning: initialization makes pointer from integer without a cast drivers/media/radio/radio-typhoon.c:76:9: error: implicit declaration of function 'kzalloc' drivers/media/radio/radio-typhoon.c:76:23: warning: initialization makes pointer from integer without a cast drivers/media/radio/radio-terratec.c:57:2: error: implicit declaration of function 'kzalloc' drivers/media/radio/radio-terratec.c:57:2: warning: return makes pointer from integer without a cast drivers/media/radio/radio-aimslab.c:67:9: error: implicit declaration of function 'kzalloc' drivers/media/radio/radio-aimslab.c:67:22: warning: initialization makes pointer from integer without a cast drivers/media/radio/radio-zoltrix.c:80:9: error: implicit declaration of function 'kzalloc' drivers/media/radio/radio-zoltrix.c:80:24: warning: initialization makes pointer from integer without a cast drivers/media/radio/radio-gemtek.c:183:9: error: implicit declaration of function 'kzalloc' drivers/media/radio/radio-gemtek.c:183:22: warning: initialization makes pointer from integer without a cast drivers/media/radio/radio-trust.c:57:9: error: implicit declaration of function 'kzalloc' drivers/media/radio/radio-trust.c:57:21: warning: initialization makes pointer from integer without a cast -- ~Randy -- 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 0/3] Support for AF9035/AF9033
Am Donnerstag, 23. Februar 2012 schrieb Oliver Schinagl: Hi Hans, I also have an AF9035 based device, the Asus 3100 Mini Plus. It has an AF9035B demodulator and uses an FCI2580 tuner. I've used the driver supplied by afa in the past, but haven't tested it in the last few months. I have a git repository for that driver at http://git.schinagl.nl/AF903x_SRC.git (it is also linked from http://www.linuxtv.org/wiki/index.php/Asus_U3100_Mini_plus_DVB-T). So when you say it is also coupled with the same tuner, that's not true :) With that driver there where a bunch of other tuners that are used with this chip. I think the Asus EEEPC supported a USB dvb tuner at some point and there are reverences in that code for it. As of the legality of the code, that is uncertain. The module (compiled from all these sources) is very specifically marked as GPL. Most headers/source files have no copyright notice at all, some however do, but no license in it. I asked about afa-tech and there driver status a while ago, but I guess there is no news as of yet? To summarize, I would love to test your driver, and I think i can code something up for my tuner, once these are split? Oliver On 22-02-12 23:20, Hans-Frieder Vogt wrote: I have written a driver for the AF9035 AF9033 (called af903x), based on the various drivers and information floating around for these chips. Currently, my driver only supports the devices that I am able to test. These are - Terratec T5 Ver.2 (also known as T6) - Avermedia Volar HD Nano (A867) The driver supports: - diversity and dual tuner (when the first frontend is used, it is in diversity mode, when two frontends are used in dual tuner mode) - multiple devices - pid filtering - remote control in NEC and RC-6 mode (currently not switchable, but depending on device) - support for kernel 3.1, 3.2 and 3.3 series I have not tried to split the driver in a DVB-T receiver (af9035) and a frontend (af9033), because I do not see the sense in doing that for a demodulator, that seems to be always used in combination with the very same receiver. The patch is split in three parts: Patch 1: support for tuner fitipower FC0012 Patch 2: basic driver Patch 3: firmware Hans-Frieder Vogt e-mail: hfvogtat gmx .dot. net -- 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 Hi Oliver, the AF9035B is in fact a DVB-T demodulator with an integrated USB interface + further interfaces (I erroneously called it receiver). It needs a tuner to be a full DVB-T stick (it seems that the it9135 is basically the AF9035 + an integrated tuner). the Terratec T5 Rev. 2 and T6 consists of an AF9035B, an AF9033B (Second demodulator) and dual FC0012 tuners the Avermedia Volar HD Nano (A867) uses an AF9035B and an Mxl5007t tuner your Asus 3100 mini uses the FCI2580 tuner. If there is a driver for the FCI2580 tuner then it is not a big issue to make it usable with the af903x driver. I know of these Afatech drivers, but the main disadvantage of them is in my eyes that they - have a lot of useless and unused code - define own error codes (instead of using the standard error codes) - have a compiled in firmware - have all supported tuners directly compiled in, which means that they prevent tuner support to be shared between various drivers So, you see, there are good reasons to write a new driver for these devices. The point with the legality: I agree that the AF903X_SRC driver is unclear in that respect. The glue code (under src) is explicitly marked as GPL, but the api code (under api) isn't marked. Luckily, there is the it9135-driver from Jason Dong which is clearly GPL and which uses the same functions. Therefore there is effectivly example code from Afatech/Ite technology available that is under GPL. Cheers, Hans-Frieder Vogt e-mail: hfvogt at gmx .dot. net -- 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 0/3] Support for AF9035/AF9033
Am Donnerstag, 23. Februar 2012 schrieb Gianluca Gennari: Il 22/02/2012 23:20, Hans-Frieder Vogt ha scritto: I have written a driver for the AF9035 AF9033 (called af903x), based on the various drivers and information floating around for these chips. Currently, my driver only supports the devices that I am able to test. These are - Terratec T5 Ver.2 (also known as T6) - Avermedia Volar HD Nano (A867) The driver supports: - diversity and dual tuner (when the first frontend is used, it is in diversity mode, when two frontends are used in dual tuner mode) - multiple devices - pid filtering - remote control in NEC and RC-6 mode (currently not switchable, but depending on device) - support for kernel 3.1, 3.2 and 3.3 series I have not tried to split the driver in a DVB-T receiver (af9035) and a frontend (af9033), because I do not see the sense in doing that for a demodulator, that seems to be always used in combination with the very same receiver. The patch is split in three parts: Patch 1: support for tuner fitipower FC0012 Patch 2: basic driver Patch 3: firmware Hans-Frieder Vogt e-mail: hfvogt at gmx .dot. net Hi Hans, thank you for the new af903x driver. A few comments: 1) I think you should set up a git repository with your driver and then send a PULL request to the list; as it is, the first patch is affected by line-wrapping problems so it must be manually edited to be applicable, and the second patch is compressed so it will be ignored by patchwork. 2) There are a couple of small errors in the patches (see my attached patches): in the dvb-usb Makefile, DVB_USB_AF903X must be replaced by CONFIG_DVB_USB_AF903X otherwise the driver will not compile; also, in the dvb_frontend_ops struct, the field info.type should be removed for kernels = 3.3.0. 3) The USB VID/PID IDs should be moved into dvb-usb-ids.h (see patch 3); I also added a few IDs from the Avermedia A867 driver*. As your driver supports both AF9007 and mxl5007t tuners I think this is safe. *http://www.avermedia.com/Support/DownloadCount.aspx?FDFId=4591 4) the driver also looks for a firmware file called af35irtbl.bin that comes from the official ITEtech driver (if it's not present the driver works anyway, but it prints an error message); I tested the driver with an Avermedia A867 stick (it's an OEM stick also known as the Sky Italia Digital Key with blue led: 07ca:a867) on a Ubuntu 10.04 system with kernel 2.6.32-38-generic-pae and the latest media_build tree installed. The good news: the driver loads properly, and, using Kaffeine, I could watch several channels with a small portable antenna; I could also perform a full frequency scan, finding several UHF and VHF stations. Signal strength and SNR reports works really well, and they seems to give a realistic figure of the signal quality (with both the portable and the rooftop antenna). When the stick is unplugged from the USB port, the driver unloads properly. The bad news: the driver seems to lock the application when it tries to tune a weak channel: in this cases, Kaffeine becomes unresponsive and sometimes it gives a stream error; for the same reason, the full scan fails to find all stations and takes a long time to complete. Also, when I tried to extract the stick from the USB port during one of this freezing periods, the system crashed :-( I reproduced this bug 3 times, and the last time I was able to see a kernel dump for a moment: the function that crashed the kernel was af903x_streaming_ctrl. Neither of those issues are present with the Avermedia A867 original driver or Antti Palosaari's af9035 driver modified to support the A867 stick. I hope this feedback will be useful to improve the driver. Best regards, Gianluca Gennari Gianluca, thanks very much for your comments and patches. I will try the patches over the weekend. With respect to your comment about the locking: I suspect this is because I have used quite a lot of mutex locks. In particular the dual tuner stick behaves very sensitive to any code changes and I have fought for months (no joke) to get it working reasonably well (besides the bad reception problems). A lot of the complexity in the driver is for the dual tuner and to support the diversity feature. As to the af35irtbl.bin firmware: this is something I just copied from previous drivers. I will probably just throw it out, because, as you also saw, it is not needed (only needed for the HID mode of the remote control). Thanks very much for your input! Regards, Hans-Frieder Vogt e-mail: hfvogt at gmx .dot. net -- 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 0/3] Support for AF9035/AF9033
Am Donnerstag, 23. Februar 2012 schrieb Antti Palosaari: On 23.02.2012 00:20, Hans-Frieder Vogt wrote: I have written a driver for the AF9035 AF9033 (called af903x), based on the various drivers and information floating around for these chips. Currently, my driver only supports the devices that I am able to test. These are - Terratec T5 Ver.2 (also known as T6) - Avermedia Volar HD Nano (A867) The driver supports: - diversity and dual tuner (when the first frontend is used, it is in diversity mode, when two frontends are used in dual tuner mode) - multiple devices - pid filtering - remote control in NEC and RC-6 mode (currently not switchable, but depending on device) - support for kernel 3.1, 3.2 and 3.3 series I have not tried to split the driver in a DVB-T receiver (af9035) and a frontend (af9033), because I do not see the sense in doing that for a demodulator, that seems to be always used in combination with the very same receiver. That was how I originally implemented it. Reason for that is simple: af9033 demodulator exists as single chip. I think it is also used for dual tuner devices or is there 2 af9035 chips used, like one is master and one is slave and working as a demod? Situation is rather same for af9005/af9003 and af9015/af9013. Search from the mailing list and see there is devices using af9003 demod but as it is not split correctly from the af9005 those devices are never supported (due to fact af9003 demod is not split out). Reason behind my af9035/af9033 is not merged to the Kernel is that I never found people from ITE who was able to give permission to merge that. As it contains some vendor code I didn't want to merge it without permission. It is not many day work to write all vendor code out from the driver and get it clean. If you want I can do it for you and merge that to the Kernel. You can then take whole driver and start hacking if you wish. What do you think? I am currently busy as hell and I don't want more drivers to maintain so you can take maintaining responsibility. The patch is split in three parts: Patch 1: support for tuner fitipower FC0012 Patch 2: basic driver Patch 3: firmware Hans-Frieder Vogt e-mail: hfvogtat gmx .dot. net regards Antti Antti, of course I understand that the af9033 is a separate chip, but still I don't know of any device that uses the af9033 without the af9035. Clearly, the situation is very similar with the other Afatech chips and you managed the splitting job very well for the af9015/af9013 and for the af9005/af9003 chips. In fact, when you look at the EEPROM code and the register sequence (not the actual addresses, they have been moved), then it seems that in particular the af9015 and the af9035 have quite a lot in common (The main difference in the description on the afatech web page is the low power for the af9035). The main reason for me to leave the code together is rather the diversity code. I liked the idea of the driver selecting diversity and dual tuner code depending on how many tuners are actually used, and I simply struggled to make a clean split between frontend and main driver code. Thanks very much for your offer to support me in getting rid of vendor code. Honestly I was of the opinion that I already got rid of all of it, but if you still see some then I really appreciate if you can help me removing it once and for all. I am happy to do the maintainer job on that driver, but if it can be improved using some of your experience that would be great! Thanks very much! Regards, Hans-Frieder Vogt e-mail: hfvogt at gmx .dot. net -- 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 0/3] Support for AF9035/AF9033
pe 24.2.2012 0:28 Hans-Frieder Vogt kirjoitti: Am Donnerstag, 23. Februar 2012 schrieb Antti Palosaari: On 23.02.2012 00:20, Hans-Frieder Vogt wrote: I have written a driver for the AF9035 AF9033 (called af903x), based on the various drivers and information floating around for these chips. Currently, my driver only supports the devices that I am able to test. These are - Terratec T5 Ver.2 (also known as T6) - Avermedia Volar HD Nano (A867) The driver supports: - diversity and dual tuner (when the first frontend is used, it is in diversity mode, when two frontends are used in dual tuner mode) - multiple devices - pid filtering - remote control in NEC and RC-6 mode (currently not switchable, but depending on device) - support for kernel 3.1, 3.2 and 3.3 series I have not tried to split the driver in a DVB-T receiver (af9035) and a frontend (af9033), because I do not see the sense in doing that for a demodulator, that seems to be always used in combination with the very same receiver. That was how I originally implemented it. Reason for that is simple: af9033 demodulator exists as single chip. I think it is also used for dual tuner devices or is there 2 af9035 chips used, like one is master and one is slave and working as a demod? Situation is rather same for af9005/af9003 and af9015/af9013. Search from the mailing list and see there is devices using af9003 demod but as it is not split correctly from the af9005 those devices are never supported (due to fact af9003 demod is not split out). Reason behind my af9035/af9033 is not merged to the Kernel is that I never found people from ITE who was able to give permission to merge that. As it contains some vendor code I didn't want to merge it without permission. It is not many day work to write all vendor code out from the driver and get it clean. If you want I can do it for you and merge that to the Kernel. You can then take whole driver and start hacking if you wish. What do you think? I am currently busy as hell and I don't want more drivers to maintain so you can take maintaining responsibility. The patch is split in three parts: Patch 1: support for tuner fitipower FC0012 Patch 2: basic driver Patch 3: firmware Hans-Frieder Vogt e-mail: hfvogtat gmx .dot. net regards Antti Antti, of course I understand that the af9033 is a separate chip, but still I don't know of any device that uses the af9033 without the af9035. Clearly, the situation is very similar with the other Afatech chips and you managed the splitting job very well for the af9015/af9013 and for the af9005/af9003 chips. In fact, when you look at the EEPROM code and the register sequence (not the actual addresses, they have been moved), then it seems that in particular the af9015 and the af9035 have quite a lot in common (The main difference in the description on the afatech web page is the low power for the af9035). The main reason for me to leave the code together is rather the diversity code. I liked the idea of the driver selecting diversity and dual tuner code depending on how many tuners are actually used, and I simply struggled to make a clean split between frontend and main driver code. Thanks very much for your offer to support me in getting rid of vendor code. Honestly I was of the opinion that I already got rid of all of it, but if you still see some then I really appreciate if you can help me removing it once and for all. I am happy to do the maintainer job on that driver, but if it can be improved using some of your experience that would be great! Thanks very much! I have few days after 12.3. All the others are clear but diversity mode needs some work. I have currently no idea how it should be implemented. Antti -- 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
