[PULL] http://linuxtv.org/hg/~anttip/af9015/
Mauro, Please pull from http://linuxtv.org/hg/~anttip/af9015/ for the following: af9013: add support for firmware 5.1.0.0 get_dvb_firmware: update af9015 af9015: support for AverMedia AVerTV Volar M (A815Mac) af9013: program tuner before demodulator af9013: af9013_read_status() refactoring af9013: output fw version as four digit long af9013: fix comments 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
Re: [PULL] http://linuxtv.org/hg/~anttip/af9015/
On 07/16/2010 01:09 PM, Simon Kenyon wrote: On 14/07/2010 17:45, Antti Palosaari wrote: Mauro, Please pull from http://linuxtv.org/hg/~anttip/af9015/ for the following: af9013: add support for firmware 5.1.0.0 get_dvb_firmware: update af9015 af9015: support for AverMedia AVerTV Volar M (A815Mac) af9013: program tuner before demodulator af9013: af9013_read_status() refactoring af9013: output fw version as four digit long af9013: fix comments regards Antti can i ask what happened to the tda18218 support? i said i would send antti a stick if he wanted it it cost me €10 on ebay. i've been away on business but will send shortly. Look this message: http://www.mail-archive.com/linux-media@vger.kernel.org/msg18629.html You never replied, never send the the stick. 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
[GIT PULL] NXP TDA18218 silicon tuner driver
Moikka Mauro, Here is new silicon tuner driver. I hope all those GIT procedures are done correctly, it was rather pain to learn GIT and in-Kernel-tree compilation. Hoping I can still see old kind of out-Kernel-tree... Special thanks goes to Simon Kenyon si...@koala.ie for stick donate. The following changes since commit 9fe6206f400646a2322096b56c59891d530e8d51: Linux 2.6.35 (2010-08-01 15:11:14 -0700) are available in the git repository at: git://linuxtv.org/anttip/media_tree.git tda18218 Antti Palosaari (3): NXP TDA18218 silicon tuner driver af9013: add support for tda18218 silicon tuner af9015: add support for tda18218 silicon tuner drivers/media/common/tuners/Kconfig |7 + drivers/media/common/tuners/Makefile|1 + drivers/media/common/tuners/tda18218.c | 334 +++ drivers/media/common/tuners/tda18218.h | 45 drivers/media/common/tuners/tda18218_priv.h | 106 + drivers/media/dvb/dvb-usb/af9015.c | 14 +- drivers/media/dvb/frontends/af9013.c| 14 ++ drivers/media/dvb/frontends/af9013_priv.h |5 +- 8 files changed, 521 insertions(+), 5 deletions(-) create mode 100644 drivers/media/common/tuners/tda18218.c create mode 100644 drivers/media/common/tuners/tda18218.h create mode 100644 drivers/media/common/tuners/tda18218_priv.h t. 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
Re: Afatech AF9015 MaxLinear MXL5007T dual tuner
Moikka, It should be easy to add support AF9015 based MXL5007T since Linux drivers exists. I haven't added it due to lack of device. That support is asked very often in recent months. regards Antti poma wrote: Hi There, This email is carbon copied to: ITE: itesupp...@ite.com.tw MaxLinear: i...@maxlinear.com TerraTec: briefkas...@terratec.de terra...@terratec.de Lifeview: h...@lifeview.com.cn eur...@lifeview.it supp...@lifeview.hk sa...@lifeview.hk market...@lifeview.hk sopo...@lifeview.es ven...@lifeview.es Linux Media: linux-media@vger.kernel.org Antti Palosaari: cr...@iki.fi http://palosaari.fi/linux/ Devices: TerraTec http://www.terratec.net/en/products/Cinergy_T_Stick_Dual_RC_102261.html Lifeview http://www.notonlytv.net/p_lv52t.html ICs: Demodulators: ITE-Afatech: http://www.ite.com.tw/EN/products_more.aspx?CategoryID=6ID=15,62 AF9015A-N1 AF9013-N1 Tuners: MaxLinear: http://www.maxlinear.com/assets/pdfs/MxL5007T.pdf MXL5007T MXL5007T lsusb: Bus 002 Device 002: ID 15a4:9016 Afatech Technologies, Inc. AF9015 DVB-T USB2.0 stick dmesg: af9015_usb_probe: interface:0 : 2b a5 9b 0b 00 00 00 00 a4 15 16 90 00 02 01 02 +... 0010: 03 80 00 fa fa 0a 40 ef 01 30 31 30 31 30 39 32 ..@..0101092 0020: 31 30 39 30 30 30 30 31 ff ff ff ff ff ff ff ff 1091 0030: 00 01 3a 01 00 08 02 00 da 11 00 00 b1 ff ff ff ..:. 0040: ff ff ff ff ff 08 02 00 da 11 c4 04 b1 ff ff ff 0050: ff ff ff ff 10 26 00 00 04 03 09 04 10 03 41 00 .A. 0060: 66 00 61 00 74 00 65 00 63 00 68 00 10 03 44 00 f.a.t.e.c.h...D. 0070: 56 00 42 00 2d 00 54 00 20 00 32 00 20 03 30 00 V.B.-.T. .2. .0. 0080: 31 00 30 00 31 00 30 00 31 00 30 00 31 00 30 00 1.0.1.0.1.0.1.0. 0090: 36 00 30 00 30 00 30 00 30 00 31 00 00 ff ff ff 6.0.0.0.0.1. 00a0: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff 00b0: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff 00c0: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff 00d0: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff 00e0: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff 00f0: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff af9015_eeprom_hash: eeprom sum=403c71e6 af9015_read_config: IR mode:1 af9015_read_config: TS mode:1 af9015_read_config: [0] xtal:2 set adc_clock:28000 af9015_read_config: [0] IF1:4570 af9015_read_config: [0] MT2060 IF1:0 af9015: tuner id:177 not supported, please report! usbcore: registered new interface driver dvb_usb_af9015 Tanks for any help poma -- 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
Re: [PATCH] af9015: add USB ID for Terratec Cinergy T Stick RC MKII
Heissan Stefan, On 08/25/2010 04:08 PM, Stefan Lippers-Hollmann wrote: Adding the USB ID for my TerraTec Electronic GmbH Cinergy T RC MKII [0ccd:0097] and hooking it up into af9015, on top of your new NXP TDA18218 patches, makes it work for me. Patch is OK, I have just similar patch waiting here... Acked-by: Antti Palosaari cr...@iki.fi I have been waiting Mauro commit for TDA18218 driver which I send about 2 weeks ago. And few others too for the MXL5007T based devices. Mauro when you will commit TDA18218? Just the shipped IR remote control doesn't seem to create keycode events yet (tested with different remote=%d parameters), are there any hints to add support for that? My next plan is to move that remote controller to the new remote core system. I have done some tests and I can now read out raw remote codes from the device. Before that you can add keymap for that remote. There is many ways to get keycodes; 1) USB-sniff, 2) dump from Windows driver, 3) read from af9015 memory, 4) use some other IR receiver... regards Antti Signed-off-by: Stefan Lippers-Hollmanns@gmx.de --- This depends on the git pull request NXP TDA18218 silicon tuner driver from Antti Palosaaricr...@iki.fi and does not apply to -stable: * NXP TDA18218 silicon tuner driver * af9013: add support for tda18218 silicon tuner * af9015: add support for tda18218 silicon tuner -- 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
Re: Gigabyte 8300
On 09/03/2010 02:42 PM, Fernando Cassia wrote: Just FYI there´s two parts on that string, the vid (vendor ID) and the pid (product id) Vendor ID 1b80 is listed at the usb device id database as Afatech although the product ID is not listed (although all the products on that section seem to be Digital TV tuners). http://www.linux-usb.org/usb.ids -- 1b80 Afatech c810 MC810 [af9015] d393 DVB-T receiver [RTL2832U] d396 UB396-T [RTL2832U] d397 DVB-T receiver [RTL2832U] d398 DVB-T receiver [RTL2832U] d700 FM Radio SnapMusic Mobile 700 (FM700) e383 DVB-T UB383-T [af9015] e385 DVB-T UB385-T [af9015] e386 DVB-T UB385-T [af9015] e39a DVB-T395U [af9015] e39b DVB-T395U [af9015] Someone please correct me if Im wrong. You are correct. Someone added this wrong name about year back. In my understanding it should be KWorld instead of Afatech. I am not even 100% if it is KWorld since that VID is seen very many designs... IIRC it was me who added this to the dvb-usb-ids.h: #define USB_VID_KWORLD_20x1b80 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
Re: [GIT PULL FOR 2.6.37] new AF9015 devices
On 09/10/2010 03:54 AM, Stefan Lippers-Hollmann wrote: Another test and some further debugging of the IR core usedby the af9015 branch of this git tree led me to partial success. DVB-T functionality continues to be fine and I've now found the proper values for this remote, however once a key gets pressed, it is never released (unless another key gets pressed which is then struck or unless I ctrl-c it (only works on terminals). Likewise I'm not sure yet how to distinguish between the Cinergy T Dual and my Cinergy T RC MKII: Given that keys, once pressed, remain to be stuck, using both lirc's dev/input and without any dæmon trying to catch keypresses, I have not reached a functional configuration. That`s known issue. Chip configures USB HID polling interval wrongly and due to that HID starts repeating usually. There is USB-ID mapped quirks in HID driver to avoid that, but only for few ADF9015 IDs... I know how to fix that totally. I have been waiting new IR core merge before switch remote from broken HID + polling to memory read based one. But maybe I can do it just now and convert it later to IR core. 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
Re: Leadtek DTV2000DS remote
Leadtek WinFast DTV2000DS remote is not supported at all. Leadtek WinFast DTV Dongle Gold remote is. If you can compile and install latest drivers from http://git.linuxtv.org/anttip/media_tree.git af9015 tree I can add support for that remote rather easily. Antti On 09/15/2010 10:45 AM, Gregory Orange wrote: Shall I assume that noone has had any experience with one of these devices? From some input from other sources, I'm now not sure if I lack a kernel module, or perhaps the firmware for this device isn't supported (or somesuch - a bit confused on that). In any case, pretty well everything is now working including EIT at last. The remote is all I lack. I have no idea who else to ask or what to try, so I may try borrowing a different remote. I'm all Googled out (: Regards, Greg. On 9 September 2010 22:11, Gregory Orangegregory.ora...@gmail.com wrote: Hi all, first post. I have a newly purchased Leadtek DTV2000DS dual tuner card in my machine, configured and running in Mythbuntu 10.04 (after installing latest v4l-dvb from source). I am having a bit of trouble getting the supplied remote control working. Is anyone here able to assist? I asked on the LIRC sf.net list and after a bit of back and forth I was directed to see if you guys can help me. In particular I wonder if the author of dvb_usb_af9015 and af9013 is around - hmm, seems to be Antti Palosaari, who seems to be a fairly recent poster. Don't get me wrong though - anyone who can assist would be great (: I have confirmed that the hardware works - I installed the drivers in a Windows boot, and the remote works. In terms of driver support I'm not sure exactly what I'm looking for, but there is this line in dmesg: [ 22.263721] input: IR-receiver inside an USB DVB receiver as /devices/pci:00/:00:0e.0/:02:0a.2/usb2/2-1/input/input5 cat /proc/bus/input/devices yields I: Bus=0003 Vendor=0413 Product=6a04 Version=0200 N: Name=IR-receiver inside an USB DVB receiver P: Phys=usb-:02:0a.2-1/ir0 S: Sysfs=/devices/pci:00/:00:0e.0/:02:0a.2/usb2/2-1/input/input5 U: Uniq= H: Handlers=kbd event5 B: EV=3 B: KEY=108fc310 2802891 0 0 0 0 118000 200180 4803 e1680 0 10 ffe So I've been using /dev/input/event5 in my tests. I have tried using evtest, mode2, and irw to no avail. I get no indication of any signal coming from the remote. Am I missing a kernel driver module? Any further advice or specific experience with this device would be gratefully welcomed. Cheers, Greg. -- Gregory Orange -- 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
Re: Afatech AF9015 MaxLinear MXL5007T dual tuner 2
On 09/18/2010 04:44 PM, poma wrote: Problem: Boot from G2 (S5) aka Soft Off or Resume from G1 - S3 aka Suspend to RAM tuner #2 nonfunctional p.p.s. Boot from G2 (S5) aka Soft Off or Resume from G1 - S3 aka Suspend to RAM tuner #1 and tuner #2 functional WITH module option: dvb-core dvb_powerdown_on_sleep=0 namely dvb_powerdown_on_sleep: 0: do not power down, 1: turn LNB voltage off on sleep (default) (int) Antti, is this the same case with TerraTec Cinergy T Stick Dual RC and is this the only solution, to keep the tuners on with dvb-core dvb_powerdown_on_sleep=0? I think so. Must be GPIO problem. One of the last problematic part is GPIOs - feel free to reimplement. 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
Re: dvb-c usb device
On 09/18/2010 09:23 PM, Bert Haverkamp wrote: Every couple of months I scan this mailing list for the keywords usb and dvb-c, hoping that some new device has shown up that is supported Currently there is Anysee E30C Plus and Technotrend CT-3650. About Technotrend I am not 100% sure, but I have seen patch for adding DVB-C support for that device. There is many DRX-K devices, but no drivers yet. Also there is TDA10024 based Reddo available in Finland, but I haven't looked it. Thus only reliable one is Anysee. 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
Re: [PATCH] v4l/dvb: add support for AVerMedia AVerTV Red HD+ (A850T)
On 09/30/2010 12:18 AM, Yann E. MORIN wrote:
The AVerTV Red HD+ (A850T) is basically the same as the existing
AVerTV Volar Black HD 9A850), but is specific to the french market.
This is a collection of information gathered from the french support
forums for Ubuntu, which I tried to properly format:
http://forum.ubuntu-fr.org/viewtopic.php?pid=3322825
/* AverMedia AVerTV Volar Black HD (A850) device have bad EEPROM
- content :-( Override some wrong values here. */
+ content :-( Override some wrong values here. Ditto for the
+ AVerTV Red HD+ (A850T) device. */
if (le16_to_cpu(udev-descriptor.idVendor) == USB_VID_AVERMEDIA
- le16_to_cpu(udev-descriptor.idProduct) == USB_PID_AVERMEDIA_A850) {
+ ((le16_to_cpu(udev-descriptor.idProduct) ==
USB_PID_AVERMEDIA_A850) ||
+(le16_to_cpu(udev-descriptor.idProduct) ==
USB_PID_AVERMEDIA_A850T))) {
deb_info(%s: AverMedia A850: overriding config\n, __func__);
/* disable dual mode */
af9015_config.dual_mode = 0;
Are you sure it does also have such bad eeprom content? Is that really
needed? What it happens without this hack?
.name = AverMedia AVerTV Volar Black HD \
- (A850),
- .cold_ids = {af9015_usb_table[20], NULL},
+ (A850) / AVerTV Volar Red HD+ (A850T),
+ .cold_ids = {af9015_usb_table[20],
+ af9015_usb_table[33], NULL},
Add new entry for that device (and leave A850 as untouched).
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
Re: [PATCH] v4l/dvb: add support for AVerMedia AVerTV Red HD+ (A850T)
On 09/30/2010 08:56 PM, Yann E. MORIN wrote: OK. The number of supported devices is already 9 in all sections, so I guess I'll have to add a new entry in the af9015_properties array, before I can add a new device, right? Actually you are using too old code as base. You should take latest GIT media tree and 2.6.37 branch. IIRC max is currently 12 devices per entry. And what is the intrinsic difference between adding a new device section, compared to adding a new PID to an existing device (just curious) ? Not much more than a little bit different device name. Technically you can add all IDs to one device, but I feel better to add new entry per device. If device name is same but only ID is different it typically means different hw revision and in that case I would like to put those same for same entry. In that case device is also a little bit different - at least case colour. 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
Re: [PATCH] v4l/dvb: add support for AVerMedia AVerTV Red HD+ (A850T)
Moi Yann On 10/01/2010 12:09 AM, Yann E. MORIN wrote: Antti, All, On Thursday 30 September 2010 22:42:40 Antti Palosaari wrote: On 09/30/2010 08:56 PM, Yann E. MORIN wrote: OK. The number of supported devices is already 9 in all sections, so I guess I'll have to add a new entry in the af9015_properties array, before I can add a new device, right? Actually you are using too old code as base. You should take latest GIT media tree and 2.6.37 branch. I'm using the latest tree from: git://git.kernel.org/pub/scm/linux/kernel/git/mchehab/linux-2.6.git Is that OK? No, it is too old. Correct tree is staging/v2.6.37 at: http://git.linuxtv.org/media_tree.git IIRC max is currently 12 devices per entry. Yes, the array in the struct has 12 entries, but the comments in the af9015 code said: /* max 9 */. So I stuck to the comment. That`s since count is increased after comment. I have changed it already. I would make use of the entries left. The af9015_properties is an array with currently 3 entries. Each entries currently all have 9 device description. Do you prefer that I add the new description: - in the first entry, - just below the existing A850, (my pick) - or in the last entry? Add it to the first free slot find. It was TerraTec Cinergy T Dual RC I added lastly. If there is free space put it just behind that, otherwise to the first free slot in next entry. This entry/dev count really sucks a little bit, it should be fixed if possible... but as now we left it. And to answer your previous question: Are you sure it does also have such bad eeprom content? Is that really needed? What it happens without this hack? Yes, I just tried without the hack and it breaks. With the hack, it works. I can provide the failing dmesg output if needed (see working one below). OK, then hack is needed. And what is the intrinsic difference between adding a new device section, compared to adding a new PID to an existing device (just curious) ? Not much more than a little bit different device name. Technically you can add all IDs to one device, but I feel better to add new entry per device. If device name is same but only ID is different it typically means different hw revision and in that case I would like to put those same for same entry. In that case device is also a little bit different - at least case colour. OK, got it. I'm afraid the A850T is just a A850 re-branded for the french market. Here is the relevant dmesg output when I plug the stick (with my changes applied on a 2.6.35.6): [12547.002398] usb 3-3.1: new high speed USB device using ehci_hcd and address 9 [12547.090226] usb 3-3.1: New USB device found, idVendor=07ca, idProduct=850b [12547.090228] usb 3-3.1: New USB device strings: Mfr=1, Product=2, SerialNumber=3 [12547.090230] usb 3-3.1: Product: A850 DVBT [12547.090231] usb 3-3.1: Manufacturer: AVerMedia [12547.090232] usb 3-3.1: SerialNumber: 302970601989000 [12547.093558] input: AVerMedia A850 DVBT as /class/input/input14 [12547.093603] generic-usb 0003:07CA:850B.000A: input,hidraw6: USB HID v1.01 Keyboard [AVerMedia A850 DVBT] on usb-:07:02.2-3.1/input1 [12547.488128] dvb-usb: found a 'AverMedia AVerTV Red HD+' in cold state, will try to load a firmware [12547.492200] dvb-usb: downloading firmware from file 'dvb-usb-af9015.fw' [12547.563986] dvb-usb: found a 'AverMedia AVerTV Red HD+' in warm state. [12547.564032] dvb-usb: will pass the complete MPEG2 transport stream to the software demuxer. [12547.564372] DVB: registering new adapter (AverMedia AVerTV Red HD+) [12547.572230] af9013: firmware version:5.1.0 [12547.576731] DVB: registering adapter 0 frontend 0 (Afatech AF9013 DVB-T)... [12547.581615] MXL5005S: Attached at address 0xc6 [12547.581653] input: IR-receiver inside an USB DVB receiver as /class/input/input15 [12547.581656] dvb-usb: schedule remote query interval to 150 msecs. [12547.581658] dvb-usb: AverMedia AVerTV Red HD+ successfully initialized and connected. [12547.678851] usbcore: registered new interface driver dvb_usb_af9015 See the part that reads: input: AVerMedia A850 DVBT as /class/input/input14 ^^^ This is no kernel message, and (I guess) it comes as the ID string from the device. It also appears on a machine where I have no DVB support. Yes, it comes from eeprom, also lsusb should show it (lsusb -vvd usb-id) So I believe the patch is OK in the state, unless you really want a new device description, instead of adding to the existing A850 ( yes, granted, it's not the same color ;-] ). What is your final word? ;-) Hmm, now I like it when it is identified as AverMedia AVerTV Red HD+. Anyway, before you get action and push this patch, Eric helped in the testing so far. Maybe he'll want to add his tested-by? Thank you very much for your comments and guidance! Regards, Yann E. MORIN. If you can make patch against latest 2.6.37 pointed I it will be OK. Also possible remote could be nice... 2.6.37 af9015 have
Re: [PATCH 08/10] V4L/DVB: tda18271: allow restricting max out to 4 bytes
On 09/30/2010 09:52 PM, Michael Krufky wrote: On Tue, Sep 28, 2010 at 2:46 PM, Mauro Carvalho Chehab mche...@redhat.com wrote: By default, tda18271 tries to optimize I2C bus by updating all registers at the same time. Unfortunately, some devices doesn't support it. The current logic has a problem when small_i2c is equal to 8, since there are some transfers using 11 + 1 bytes. Fix the problem by enforcing the max size at the right place, and allows reducing it to max = 3 + 1. Signed-off-by: Mauro Carvalho Chehabmche...@redhat.com This looks to me as if it is working around a problem on the i2c master. I believe that a fix like this really belongs in the i2c master driver, it should be able to break the i2c transactions down into transactions that the i2c master can handle. I wouldn't want to merge this without a better explanation of why it is necessary in the tda18271 driver. It seems to be a band-aid to cover up a problem in the i2c master device driver code. Yes it is I2C provider limitation, but I think almost all I2C adapters have some limit. I suggest to set param for each tuner and demod driver which splits reads and writes to len adapter can handle. I did that for tda18218 write. But there is one major point you don't see. It is not simple to add this splitting limit to the provider. Provider does not have knowledge which is meaning of bytes it transfers to the bus. Without knowledge it breaks functionality surely in some point. There is commonly seen 1, 2 and 4 byte register address and same for register values. Also some chips like to send data as register-value pairs. 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
Re: [PATCH] v4l/dvb: add support for AVerMedia AVerTV Red HD+ (A850T)
On 10/04/2010 11:55 PM, Yann E. MORIN wrote: All, On Friday 01 October 2010 21:55:43 Yann E. MORIN wrote: The AVerTV Red HD+ (A850T) is basically the same as the existing AVerTV Volar Black HD (A850), but is specific to the french market. The A850T identifies itself as a A850, but has its own PID. It even suffers from the same EEPROM deficiencies. Ping? Is there something that I should still work on? No. I will pick it up and forward to the master. thanks Antti Regards, Yann E. MORIN. -- 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
Re: [linux-dvb] [bug] AF9015 message WARNING: tuning failed!!!
It is QT1010 tuner driver issue. None is working for that currently or in near future. Feel free to fix :] Antti On 10/06/2010 04:56 PM, Paul Gover wrote: I've a cheap USB DVB key that won't work with Kaffeine. It identifies itself as KWorld USB DVB-T TV Stick II (VS-DVB-T 395U). It shows up on Kaffeine's Configure Television dialog, but scanning for channels finds nothing, and tuning using an old channel list gives Sorry - no available device found I had Kaffeine working OK with a different USB TV key. dvbscan produces WARNING: tuning failed!!! messages. The key works on XP using KWorld's HyperMedia Center. Rebooting from there to Linux with warm USB key shows it contains 4.95.0 firmware. At one point, such a warm reboot enabled Kaffeine to show TV. That was with one of the early KDE4 Kaffeine candidates, and an older linux kernel (sorry, I forget which). Now using kernel modules in Linux version 2.6.34-gentoo-r6. Kaffeine 1.0, KDE 4.4.5. linuxtv-dvb-apps 1.1.1.20080317 on an ASUS EeePC 1000HE (Intel Atom processor). Diagnostic stuff lsusb -v : Bus 001 Device 023: ID 1b80:e396 Afatech Device Descriptor: bLength18 bDescriptorType 1 bcdUSB 2.00 bDeviceClass0 (Defined at Interface level) bDeviceSubClass 0 bDeviceProtocol 0 bMaxPacketSize064 idVendor 0x1b80 Afatech idProduct 0xe396 bcdDevice2.00 iManufacturer 1 Afatech iProduct2 DVB-T 2 iSerial 0 bNumConfigurations 1 Configuration Descriptor: bLength 9 bDescriptorType 2 wTotalLength 46 bNumInterfaces 1 bConfigurationValue 1 iConfiguration 0 bmAttributes 0x80 (Bus Powered) MaxPower 500mA Interface Descriptor: bLength 9 bDescriptorType 4 bInterfaceNumber0 bAlternateSetting 0 bNumEndpoints 4 bInterfaceClass 255 Vendor Specific Class bInterfaceSubClass 0 bInterfaceProtocol 0 iInterface 0 Endpoint Descriptor: bLength 7 bDescriptorType 5 bEndpointAddress 0x81 EP 1 IN bmAttributes2 Transfer TypeBulk Synch Type None Usage Type Data wMaxPacketSize 0x0200 1x 512 bytes bInterval 0 Endpoint Descriptor: bLength 7 bDescriptorType 5 bEndpointAddress 0x02 EP 2 OUT bmAttributes2 Transfer TypeBulk Synch Type None Usage Type Data wMaxPacketSize 0x0200 1x 512 bytes bInterval 0 Endpoint Descriptor: bLength 7 bDescriptorType 5 bEndpointAddress 0x84 EP 4 IN bmAttributes2 Transfer TypeBulk Synch Type None Usage Type Data wMaxPacketSize 0x0200 1x 512 bytes bInterval 0 Endpoint Descriptor: bLength 7 bDescriptorType 5 bEndpointAddress 0x85 EP 5 IN bmAttributes2 Transfer TypeBulk Synch Type None Usage Type Data wMaxPacketSize 0x0200 1x 512 bytes bInterval 0 Device Qualifier (for other device speed): bLength10 bDescriptorType 6 bcdUSB 2.00 bDeviceClass0 (Defined at Interface level) bDeviceSubClass 0 bDeviceProtocol 0 bMaxPacketSize064 bNumConfigurations 1 Device Status: 0x (Bus Powered) lsmod : Module Size Used by ppp_deflate 3156 0 zlib_deflate 17980 1 ppp_deflate zlib_inflate 14197 1 ppp_deflate bsd_comp4568 0 ppp_async 6283 1 crc_ccitt 1023 1 ppp_async ppp_generic14958 7 ppp_deflate,bsd_comp,ppp_async slhc4431 1 ppp_generic sr_mod 10825 0 cdrom 29800 1 sr_mod option 18224 1 usbserial 24352 4 option snd_seq_oss23625 0 snd_seq_midi_event 4280 1 snd_seq_oss snd_seq39723 4 snd_seq_oss,snd_seq_midi_event snd_seq_device 4109 2 snd_seq_oss,snd_seq snd_pcm_oss30331 0 snd_mixer_oss 12481 1 snd_pcm_oss snd_hda_codec_realtek 187652 1 qt1010 4461 1 snd_hda_intel
Re: [linux-dvb] [bug] AF9015 message WARNING: tuning failed!!!
On 10/06/2010 11:36 PM, dave cunningham wrote: In message 4cacd0f3.6030...@iki.fi, Antti Palosaari wrote It is QT1010 tuner driver issue. None is working for that currently or in near future. Feel free to fix :] The wiki appears to show this stick as working. http://linuxtv.org/wiki/index.php/Afatech_AF9015. Is this information incorrect or is it hit and miss depending on the host system? It works but performance is poor. Usually it locks when RF signal is weak. If you fix bug around line 381 in qt1010.c it will work much better. But if you fix that it will break devices zl10353+qt1010 since zl10353 driver misses AGC configuration. 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
[GIT PULL FOR 2.6.37] AF9013 + AF9015 changes, mostly remote controller
Moikka Mauro, This patch series mainly moves af9015 remote controllers to rc-core. Also some other changes which should not have visible effects. I did forced update since normal said: To prevent you from losing history, non-fast-forward updates were rejected. Hopefully it does not cause merging problems for you. t. Antti The following changes since commit c8dd732fd119ce6d562d5fa82a10bbe75a376575: V4L/DVB: gspca - sonixj: Have 0c45:6130 handled by sonixj instead of sn9c102 (2010-10-01 18:14:35 -0300) are available in the git repository at: git://linuxtv.org/anttip/media_tree.git af9015 Antti Palosaari (19): af9013: optimize code size af9013: cache some reg values to reduce reg reads af9015: make checkpatch.pl happy af9015: remove needless variable set TerraTec remote controller keytable MSI DIGIVOX mini III remote controller keytable TrekStor DVB-T USB Stick remote controller Digittrade DVB-T USB Stick remote controller keytable AverMedia RM-KS remote controller keytable LeadTek Y04G0051 remote controller keytable TwinHan AzureWave AD-TU700(704J) remote controller A-Link DTU(m) remote controller MSI DIGIVOX mini II remote controller rename rc-msi-digivox.c - rc-msi-digivox-iii.c Total Media In Hand remote controller fix MSI DIGIVOX mini III remote controller power buttons fix TerraTec remote controller PIP button fix A-Link DTU(m) remote controller PIP button af9015: move remote controllers to new RC core Yann E. MORIN (1): v4l/dvb: add support for AVerMedia AVerTV Red HD+ (A850T) drivers/media/IR/keymaps/Makefile | 10 + drivers/media/IR/keymaps/rc-alink-dtu-m.c | 68 drivers/media/IR/keymaps/rc-avermedia-rm-ks.c | 79 drivers/media/IR/keymaps/rc-azurewave-ad-tu700.c | 102 + drivers/media/IR/keymaps/rc-digittrade.c | 82 drivers/media/IR/keymaps/rc-leadtek-y04g0051.c| 99 + drivers/media/IR/keymaps/rc-msi-digivox-ii.c | 67 drivers/media/IR/keymaps/rc-msi-digivox-iii.c | 85 + drivers/media/IR/keymaps/rc-terratec-slim.c | 79 drivers/media/IR/keymaps/rc-total-media-in-hand.c | 85 + drivers/media/IR/keymaps/rc-trekstor.c| 80 drivers/media/dvb/dvb-usb/af9015.c| 253 +++-- drivers/media/dvb/dvb-usb/af9015.h| 418 + drivers/media/dvb/dvb-usb/dvb-usb-ids.h |1 + drivers/media/dvb/frontends/af9013.c | 92 ++--- drivers/media/dvb/frontends/af9013_priv.h | 69 ++-- include/media/rc-map.h| 10 + 17 files changed, 1062 insertions(+), 617 deletions(-) create mode 100644 drivers/media/IR/keymaps/rc-alink-dtu-m.c create mode 100644 drivers/media/IR/keymaps/rc-avermedia-rm-ks.c create mode 100644 drivers/media/IR/keymaps/rc-azurewave-ad-tu700.c create mode 100644 drivers/media/IR/keymaps/rc-digittrade.c create mode 100644 drivers/media/IR/keymaps/rc-leadtek-y04g0051.c create mode 100644 drivers/media/IR/keymaps/rc-msi-digivox-ii.c create mode 100644 drivers/media/IR/keymaps/rc-msi-digivox-iii.c create mode 100644 drivers/media/IR/keymaps/rc-terratec-slim.c create mode 100644 drivers/media/IR/keymaps/rc-total-media-in-hand.c create mode 100644 drivers/media/IR/keymaps/rc-trekstor.c -- 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
Re: [PATCH] Support or LME2510(C) DM04/QQBOX USB DVB-S BOXES.
On 09/02/2010 11:29 PM, tvbox wrote: DM04/QQBOX DVB-S USB BOX with LME2510C+SHARP:BS2F7HZ7395 or LME2510+LGTDQT-P001F tuner. +config DVB_USB_LME2510 + tristate LME DM04/QQBOX DVB-S USB2.0 support + depends on DVB_USB + select DVB_TDA10086 if !DVB_FE_CUSTOMISE + select DVB_TDA826X if !DVB_FE_CUSTOMISE + select DVB_STV0288 if !DVB_FE_CUSTOMISE + select DVB_IX2505V if !DVB_FE_CUSTOMISE + select IR_CORE + help + Say Y here to support the LME DM04/QQBOX DVB-S USB2.0 . Just for curious, is IR_CORE and DVB_USB both needed? DVB_USB also depends on IR_CORE ? This was only DVB-USB driver which does that. 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
Re: Skystar USB 2 Driver
Hei Ali, On 10/15/2010 11:10 AM, Ali Güller wrote: I have just participated in this mail group. I wonder if there is a driver for Technisat Skystar USB 2 . Thank you. There is also commonly available Cinergy S2 USB HD (USB DVB-S2). I tested it recently and it was rather working with s2-liplianin tree. Support is not added to the main Kernel for some reason, looks like Liplianin is delaying it for some reason. He didn't even answer mail when I asked reason for delay :-( http://mercurial.intuxication.org/hg/s2-liplianin-351/rev/97ae743b2035 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
Re: [RFC] Resource reservation for frontend - Was: Re: xc5000 and switch RF input
On 10/14/2010 11:41 AM, Devin Heitmueller wrote: On Thu, Oct 14, 2010 at 4:33 AM, Antti Palosaaricr...@iki.fi wrote: I haven't examined this yet enough, but for the background information I can say I have one device which needs this. There is tuner behind demodulator, but instead of normal I2C-gate switch, it is rather much likely repeater. All tuner commands are send to the demod which then writes those to the tuner. DD = demod I2C addr TT = tuner I2C addr Bn = payload data traditional I2C send to the tuner: TT B0 B1 B2 ... demod as repeater send to the tuner: DD TT B0 B1 B2 ... You can accomplish this by having the demod create an i2c adapter instance, which generates i2c commands to the bridge. Then when instantiating the tuner subdev, pass a pointer to the demod's i2c adapter instead of the i2c adapter provided by the bridge. No changes required to the core framework. Thank you Devin. I didn't realized that earlier. It worked just fine. 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
Re: AF9013/15 I2C problems
On 10/17/2010 01:47 PM, dave cunningham wrote: I'm currently on hg version 14319:37581bb7e6f1, on a debian-squeeze system, kernel 2.6.32. I've googled and found various people seeing similar problems but have yet to come across a solution. Would anyone have any suggestions (note if I switch back to firmware 4.65 with just the Tevion stick things are fine - I'd like to use the KWorld stick if possible though)? I have strong feeling this issue is fixed already. Install latest Git master driver from Linuxtv.org 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
[GIT PULL FOR 2.6.37] Anysee RC core
Moikka Mauro, Put Anysee remote to the RC core. t. Antti The following changes since commit 4c235b8ba0c25fab25163600da9dbbb082fcf62a: V4L/DVB: gp8psk: Add support for the Genpix Skywalker-2 (2010-10-16 15:37:13 -0300) are available in the git repository at: git://linuxtv.org/anttip/media_tree.git anysee Antti Palosaari (2): Anysee remote controller anysee: switch to RC core drivers/media/IR/keymaps/Makefile|1 + drivers/media/IR/keymaps/rc-anysee.c | 93 ++ drivers/media/dvb/dvb-usb/anysee.c | 87 include/media/rc-map.h |1 + 4 files changed, 116 insertions(+), 66 deletions(-) create mode 100644 drivers/media/IR/keymaps/rc-anysee.c -- 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
Re: Old patches sent via the Mailing list
On 10/18/2010 12:20 AM, Mauro Carvalho Chehab wrote: Hi, I did a large effort during this weekend to handle the maximum amount of patches, in order to have them ready for 2.6.37. While there are still some patches marked as NEW at patchwork, and a few pending pull requests (mostly related to more kABI changes), there are still a list of patches that are marked as Under review. Except for 4 patches from me, related to Doc (that I'm keeping in this list just to remind me that I'll need to fix them when I have some time - just some automation stuff at DocBook), all other patches marked as Under review are stuff that I basically depend on others. The last time I sent this list, I was about to travel, and I may have missed some comments, or maybe I may just forgot to update. But I suspect that, for the list bellow, most of them are stuff where the driver maintainer just forgot at limbo. From the list of patches under review, we have: == Waiting for Antti Palosaaricr...@iki.fi review == Mar,21 2010: af9015 : more robust eeprom parsing http://patchwork.kernel.org/patch/87243 matthieu castetcastet.matth...@free.fr Mark as dropped. 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
Re: rtl2832u support
On 10/19/2010 08:42 PM, Damjan Marion wrote: Is there any special reason why driver for rtl2832u DVB-T receiver chipset is not included into v4l-dvb? It is due to lack of developer making driver suitable for Kernel. I have done some work and have knowledge what is needed, but no time nor interest enough currently. It should be implement as one USB-interface driver and two demod drivers (RTL2830, RTL2832) to support for both RTL2831U and RTL2832U. 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
Re: rtl2832u support
On 10/19/2010 10:33 PM, Damjan Marion wrote: On Oct 19, 2010, at 9:10 PM, Antti Palosaari wrote: On 10/19/2010 08:42 PM, Damjan Marion wrote: Is there any special reason why driver for rtl2832u DVB-T receiver chipset is not included into v4l-dvb? It is due to lack of developer making driver suitable for Kernel. I have done some work and have knowledge what is needed, but no time nor interest enough currently. It should be implement as one USB-interface driver and two demod drivers (RTL2830, RTL2832) to support for both RTL2831U and RTL2832U. Can you share what you done so far? Look LinuxTV.org HG trees. There is Jan and my trees, both for RTL2831U. I split driver logically correct parts. Also I have some RTL2832U hacks here in my computer, I can give those for the person really continuing development. 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
Re: USB DVBT af9015: tuner id:177 not supported, please report!
Moikka Felix. It is already supported, will go the 2.6.37. Tuner ID 177 is MaxLinear MXL5007T. Antti On 10/21/2010 04:46 PM, Felix Droste wrote: I could not get this DVBT-Stick (USB) to work: auvisio USB-DVB-T-Receiver -Recorder DR-340 h t t p : / / w w w .pearl.de/product.jsp?pdid=HPM1520catid=8909vid=922curr=DEM dmesg: [25239.410175] usb 2-1: new high speed USB device using ehci_hcd and address 6 [25239.569729] Afatech DVB-T 2: Fixing fullspeed to highspeed interval: 10 - 7 [25239.570294] input: Afatech DVB-T 2 as /devices/pci:00/:00:1d.7/usb2/2-1/2-1:1.1/input/input12 [25239.570642] generic-usb 0003:15A4:9016.0003: input,hidraw2: USB HID v1.01 Keyboard [Afatech DVB-T 2] on usb-:00:1d.7-1/input1 [25239.982243] af9015: tuner id:177 not supported, please report! [25239.982339] usbcore: registered new interface driver dvb_usb_af9015 Cheers! -- 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 -- 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
[GIT PULL FOR 2.6.37] af9015 new device and remote controller changes
Moikka Mauro, PULL following changes to the 2.6.37-RC1. t. Antti The following changes since commit a348e9110ddb5d494e060d989b35dd1f35359d58: [media] cx25840: fix problem with Terratec Grabster AV400 (2010-10-18 04:11:44 -0200) are available in the git repository at: git://linuxtv.org/anttip/media_tree.git af9015 Antti Palosaari (4): af9015: RC fixes and improvements DigitalNow TinyTwin remote controller af9015: map DigitalNow TinyTwin v2 remote af9015: support for DigitalNow TinyTwin v3 [1f4d:9016] drivers/media/IR/keymaps/Makefile |1 + drivers/media/IR/keymaps/rc-digitalnow-tinytwin.c | 98 + drivers/media/dvb/dvb-usb/af9015.c| 88 +-- drivers/media/dvb/dvb-usb/dvb-usb-ids.h |2 + include/media/rc-map.h|1 + 5 files changed, 142 insertions(+), 48 deletions(-) create mode 100644 drivers/media/IR/keymaps/rc-digitalnow-tinytwin.c -- 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
Re: V4L/DVB/IR patches pending merge
On 10/30/2010 02:02 AM, Hernán Ordiales wrote: 2010/10/23 Mauro Carvalho Chehabmche...@redhat.com: This is the list of patches that weren't applied yet. I've made a big effort starting last weekend to handle everything I could. All pull requests were addressed. There are still 43 patches on my queue. Please help me to clean the list. This is what we have currently: [snip] == Waiting for Patrick Boettcherpboettc...@dibcom.fr review == May,25 2010: Adding support to the Geniatech/MyGica SBTVD Stick S870 remote control http://patchwork.kernel.org/patch/102314 Hernán Ordialesh.ordia...@gmail.com Jul,14 2010: [1/4] drivers/media/dvb: Remove dead Configs http://patchwork.kernel.org/patch/111972 Christian Dietrichqy03f...@stud.informatik.uni-erlangen.de Jul,14 2010: [2/4] drivers/media/dvb: Remove undead configs http://patchwork.kernel.org/patch/111973 Christian Dietrichqy03f...@stud.informatik.uni-erlangen.de The first patch is probably broken. Hernán, Could you please re-generate it? Yes, i'm sending it as attachment (regenerated agaisnt trunk, 15168 revision) Cheers Your keytable seems to be wrong since it have both keycode and its complement (which is used for error check normally). I think it is NEC remote? In that case address byte is typically same for all buttons. 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
Re: [linux-dvb] [bug] AF9015 message WARNING: tuning failed!!!
On 11/23/2010 10:11 PM, Paul Gover wrote: On Wednesday 06 October 2010 22:29:35 Antti Palosaari wrote: On 10/06/2010 11:36 PM, dave cunningham wrote: In message4cacd0f3.6030...@iki.fi, Antti Palosaari wrote It is QT1010 tuner driver issue. None is working for that currently or in near future. Feel free to fix :] The wiki appears to show this stick as working. http://linuxtv.org/wiki/index.php/Afatech_AF9015. Is this information incorrect or is it hit and miss depending on the host system? It works but performance is poor. Usually it locks when RF signal is weak. If you fix bug around line 381 in qt1010.c it will work much better. But if you fix that it will break devices zl10353+qt1010 since zl10353 driver misses AGC configuration. Antti Antti, I took a look at qt1010.c, but didn't see what the bug was. I was hoping to see a FIXME or BUG or some comment; any comment ;-) Look this, I think it does have that fixed. http://linuxtv.org/hg/~anttip/qt1010/ But then I went back to my traces. They said my AF9015 detected an MT2060 tuner, not a QT1010. Does this mean the QT1010 comment was wrong? The detection code that said so looks to be part of the AF9015/9013 support, maybe they use the same code. Whatever, you will know, and I certainly don't. The tuner code certainly uses the QT1010 driver and not the MT2060 driver, if I understood the traces correctly. You surely misunderstand something now. Look your first post: Quantek QT1010 successfully identified. FWIW, I think you are right about AGC; when Kaffeine scans for channels, it gives a few fleeting signal levels about 50% but fails to identify anything. My previous DVB-T stick, different older chip, produced 100% signal solidly, and Kaffeine identified more than 80 channels. I think this bug renders the AF9015 in this configuration virtually useless in Linux; the signal is enough for the Windoze tuner bloatware supplied with it to find all the channels, but not a thing in Linux. Sorry for coming back on this so much later; I've been busy doing house repair. Also, I stopped following the mailing list - I was getting swamped with stuff and it seems to make yahoo break KDE PIM. If I should post this via the list, please say, and I'll start obeying the rules! Thanks in advance for any guidance. -- 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 -- 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
Re: Disable IR on dvb_usb_af9015
There is no module or per device basis option for that. Use option from module dvb-usb. Antti On 11/28/2010 02:58 PM, Josu Lazkano wrote: Hello list! I have a Kworld U399U twin DVB-T adapter. It has a IR rceiver and I want to disable it from module on /etc/modprobe.d/options.conf Is any way to do this? I use to use the modprobe option to assign the number of the adapters: options dvb_usb_af9015 adapter_nr=4,5 It will be great to disable the IR. Thanks for all and best regards. -- 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
Re: problem af9015: tuner id:177 not supported, please report!
It is MxL5007T. Has gone to the 2.6.37. Antti On 11/28/2010 05:55 PM, helmut.neume...@gmx.de wrote: hello i have a prob lem with a tv-stick i get the error af9015: tuner id:177 not supported, please report! uname -r 2.6.32-25-generic-pae can anybody help me i have downloaded the actual source but i get the same error. -- 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
dvb-apps: update DVB-T intial tuning files for Finland (fi-*)
Moi Christoph, Updates all Finnish channels as today. I accidentally removed first fi-Smedsbole file since that was not generated by my scripts. Actually it is for the autonomy island named Åland [1] between Finland and Sweden. They have even own top level domain - ax. I think correct name for that is ax-Smedsbole instead of fi. [1] http://en.wikipedia.org/wiki/%C3%85land_Islands Antti -- http://palosaari.fi/ changeset: 1407:d38a19ce8521 tag: tip user:Antti Palosaari cr...@iki.fi date:Fri Dec 10 18:32:39 2010 +0200 summary: dvb-apps: update DVB-T intial tuning files for Finland (fi-*) diff -r c87abbb20491 -r d38a19ce8521 util/scan/dvb-t/fi-Aanekoski --- a/util/scan/dvb-t/fi-Aanekoski Sun Nov 28 21:24:42 2010 +0100 +++ b/util/scan/dvb-t/fi-Aanekoski Fri Dec 10 18:32:39 2010 +0200 @@ -2,5 +2,5 @@ # T freq bw fec_hi fec_lo mod transmission-mode guard-interval hierarchy T 61000 8MHz 2/3 NONE QAM64 8k 1/8 NONE T 73000 8MHz 2/3 NONE QAM64 8k 1/8 NONE -T 82600 8MHz 2/3 NONE QAM64 8k 1/8 NONE +T 53000 8MHz 2/3 NONE QAM64 8k 1/8 NONE T 68200 8MHz 2/3 NONE QAM64 8k 1/8 NONE diff -r c87abbb20491 -r d38a19ce8521 util/scan/dvb-t/fi-Aanekoski_Konginkangas --- a/util/scan/dvb-t/fi-Aanekoski_Konginkangas Sun Nov 28 21:24:42 2010 +0100 +++ b/util/scan/dvb-t/fi-Aanekoski_Konginkangas Fri Dec 10 18:32:39 2010 +0200 @@ -2,4 +2,5 @@ # T freq bw fec_hi fec_lo mod transmission-mode guard-interval hierarchy T 65800 8MHz 2/3 NONE QAM64 8k 1/8 NONE T 69000 8MHz 2/3 NONE QAM64 8k 1/8 NONE +T 60200 8MHz 2/3 NONE QAM64 8k 1/8 NONE T 76200 8MHz 2/3 NONE QAM64 8k 1/8 NONE diff -r c87abbb20491 -r d38a19ce8521 util/scan/dvb-t/fi-Enontekio_Ahovaara_Raattama --- a/util/scan/dvb-t/fi-Enontekio_Ahovaara_RaattamaSun Nov 28 21:24:42 2010 +0100 +++ /dev/null Thu Jan 01 00:00:00 1970 + @@ -1,4 +0,0 @@ -# automatically generated from http://www.digitv.fi/sivu.asp?path=1;8224;9519 -# T freq bw fec_hi fec_lo mod transmission-mode guard-interval hierarchy -T 51400 8MHz 2/3 NONE QAM64 8k 1/8 NONE -T 57000 8MHz 2/3 NONE QAM64 8k 1/8 NONE diff -r c87abbb20491 -r d38a19ce8521 util/scan/dvb-t/fi-Enontekio_Raattama --- /dev/null Thu Jan 01 00:00:00 1970 + +++ b/util/scan/dvb-t/fi-Enontekio_Raattama Fri Dec 10 18:32:39 2010 +0200 @@ -0,0 +1,4 @@ +# automatically generated from http://www.digitv.fi/sivu.asp?path=1;8224;9519 +# T freq bw fec_hi fec_lo mod transmission-mode guard-interval hierarchy +T 51400 8MHz 2/3 NONE QAM64 8k 1/8 NONE +T 57000 8MHz 2/3 NONE QAM64 8k 1/8 NONE diff -r c87abbb20491 -r d38a19ce8521 util/scan/dvb-t/fi-Hameenkyro_Kyroskoski --- a/util/scan/dvb-t/fi-Hameenkyro_Kyroskoski Sun Nov 28 21:24:42 2010 +0100 +++ b/util/scan/dvb-t/fi-Hameenkyro_Kyroskoski Fri Dec 10 18:32:39 2010 +0200 @@ -2,4 +2,5 @@ # T freq bw fec_hi fec_lo mod transmission-mode guard-interval hierarchy T 57800 8MHz 2/3 NONE QAM64 8k 1/8 NONE T 49000 8MHz 2/3 NONE QAM64 8k 1/8 NONE +T 77000 8MHz 2/3 NONE QAM64 8k 1/8 NONE T 77800 8MHz 2/3 NONE QAM64 8k 1/8 NONE diff -r c87abbb20491 -r d38a19ce8521 util/scan/dvb-t/fi-Haukela --- /dev/null Thu Jan 01 00:00:00 1970 + +++ b/util/scan/dvb-t/fi-HaukelaFri Dec 10 18:32:39 2010 +0200 @@ -0,0 +1,5 @@ +# automatically generated from http://www.digitv.fi/sivu.asp?path=1;8224;9519 +# T freq bw fec_hi fec_lo mod transmission-mode guard-interval hierarchy +T 57800 8MHz 2/3 NONE QAM64 8k 1/8 NONE +T 62600 8MHz 2/3 NONE QAM64 8k 1/8 NONE +T 58600 8MHz 2/3 NONE QAM64 8k 1/8 NONE diff -r c87abbb20491 -r d38a19ce8521 util/scan/dvb-t/fi-Hossa --- /dev/null Thu Jan 01 00:00:00 1970 + +++ b/util/scan/dvb-t/fi-Hossa Fri Dec 10 18:32:39 2010 +0200 @@ -0,0 +1,4 @@ +# automatically generated from http://www.digitv.fi/sivu.asp?path=1;8224;9519 +# T freq bw fec_hi fec_lo mod transmission-mode guard-interval hierarchy +T 65800 8MHz 2/3 NONE QAM64 8k 1/8 NONE +T 67400 8MHz 2/3 NONE QAM64 8k 1/8 NONE diff -r c87abbb20491 -r d38a19ce8521 util/scan/dvb-t/fi-Hyrynsalmi_Paljakka --- a/util/scan/dvb-t/fi-Hyrynsalmi_PaljakkaSun Nov 28 21:24:42 2010 +0100 +++ b/util/scan/dvb-t/fi-Hyrynsalmi_PaljakkaFri Dec 10 18:32:39 2010 +0200 @@ -2,3 +2,4 @@ # T freq bw fec_hi fec_lo mod transmission-mode guard-interval hierarchy T 48200 8MHz 2/3 NONE QAM64 8k 1/8 NONE T 52200 8MHz 2/3 NONE QAM64 8k 1/8 NONE +T 67400 8MHz 2/3 NONE QAM64 8k 1/8 NONE diff -r c87abbb20491 -r d38a19ce8521 util/scan/dvb-t/fi-Jamsa_Kaipola --- a/util/scan/dvb-t/fi-Jamsa_Kaipola Sun Nov 28 21:24:42 2010 +0100 +++ b/util/scan/dvb-t/fi-Jamsa_Kaipola Fri Dec 10 18:32:39 2010 +0200 @@ -2,4 +2,5 @@ # T freq bw fec_hi fec_lo mod transmission-mode guard-interval hierarchy T 60200 8MHz 2/3 NONE QAM64 8k 1/8 NONE T 65800 8MHz 2/3 NONE QAM64 8k 1/8 NONE +T 69800 8MHz 2/3 NONE QAM64 8k 1/8 NONE T 53800 8MHz 2/3 NONE QAM64 8k 1/8 NONE diff -r c87abbb20491 -r
Re: PCTV 290e nanostick and remote control support
Hello On 08/13/2011 10:36 PM, Chris Rankin wrote: I've just acquired a PCTV 290e nanostick, and have successfully tuned it into a DVB-T2 MUX. Yay! :-). However, before declaring total victory, I have noticed that no-one has yet wired up the device's IR support in the em28xx driver. The adapter ships with a tiny RC with only 26 buttons, which would allow me to use the 290e with VDR. Does anyone know what kind of IR hardware the 290e uses, please? I tried setting: .has_ir_i2c = 1 in the [EM28174_BOARD_PCTV_290E] section of em28xx_cards.c, but saw nothing new in the dmesg log. (Yes, the ir_kdb_i2c modules did load successfully.) The /sys/bus/i2c/devices directory contains two nodes: em28xx #0 CXD2820R tuner I2C adapter Any (non-destructive) suggestions for other things to try to get IR working would be gratefully received. Remote is already supported, but from the 3.1 or maybe 3.2 (I am not sure if Mauro was hurry to sent it 3.1). Anyhow, if you need it please install latest v4l-dvb drivers. Thank you for the report. 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
Re: TerraTec T6 Dual Tuner Stick initial support available
On 08/14/2011 10:30 AM, Hans-Frieder Vogt wrote: just wanted to inform you that I got the TerraTec Dual DVB-T Stick working using a slightly patched driver from Afatech. Please see the wiki entry http://www.linuxtv.org/wiki/index.php/TerraTec_T6_Dual_DVB-T_Stick Currently both tuners work, but the remote doesn't. This driver is only supposed to be a temporary solution until I have integrated the bits into Antti's af9035 driver, see http://openee.googlecode.com/svn-history/r137/trunk/recipes/v4l-dvb/files/v4l- dvb-af9035.patch http://openee.googlecode.com/svn-history/r137/trunk/recipes/v4l-dvb/files/v4l- dvb-af9033.patch Situation of my AF9035 AF9033 driver is and have been years totally frozen, I given it up since I never got permission from ITE to push it Kernel and firmware distribution. Thus I left it. I have had in mind to write out all vendor code (not much code I think) to get rid of copyrights and do what I want - but never had enough time. Due to that I am not going to work my AF9035 + AF9033 unless something changes dramatically at least now when there is other drivers. 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
Re: PCTV 290e nanostick and remote control support
On 08/14/2011 04:48 AM, Devin Heitmueller wrote:
On Sat, Aug 13, 2011 at 9:43 PM, Chris Rankin ranki...@yahoo.com wrote:
The rc-pinnacle-pctv-hd keymap is missing the definition of the OK key:
--- linux-3.0/drivers/media/rc/keymaps/rc-pinnacle-pctv-hd.c.orig
2011-08-14 02:42:01.0 +0100
+++ linux-3.0/drivers/media/rc/keymaps/rc-pinnacle-pctv-hd.c2011-08-14
02:12:45.0 +0100
@@ -20,6 +20,7 @@
{ 0x0701, KEY_MENU }, /* Pinnacle logo */
{ 0x0739, KEY_POWER },
{ 0x0703, KEY_VOLUMEUP },
+ { 0x0705, KEY_OK },
{ 0x0709, KEY_VOLUMEDOWN },
{ 0x0706, KEY_CHANNELUP },
{ 0x070c, KEY_CHANNELDOWN },
Cheers,
Chris
Wow, how the hell did I miss that? I did numerous remotes for em28xx
based devices that use that RC profile, and never noticed that issue.
Will have to check the merge logs. Maybe the key got lost when they
refactored the IR support.
It seems to be very old bug, year 2007, not coming from merge errors! It
could be even possible there have not been such button originally. Very
weird situation none have found it earlier. For example I just pressed
few buttons to see number are coming to console = OK it works (didn't
looked all buttons sends events).
That's commit which adds those keytables:
commit 54d75ebaa02809f24a16624e32706af3bf97588e
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
Re: Smart card reader support for Anysee DVB devices
Hello, I looked your codes and examined also some more. About your driver, I don't like you put so much functionality to the Kernel driver. Just put this functionality to the userspace driver all and offer only lowest possible interface (read + write) from Kernel. If you look other IFDs it is like that. On the other hand I see it could be possible to add some glue and functionality to the Kernel driver if you find already existing userspace protocol (IFD driver) which can be used. Add some emulation to Kernel and use existing user space. Select some well supported serial smartcard reader and make Anysee driver speak like that. Biggest problem I see whole thing is poor application support. OpenCT is rather legacy but there is no good alternative. All this kind of serial drivers seems to be OpenCT currently. regards Antti On 07/17/2011 05:18 PM, István Váradi wrote: Hi, I have developed smart card reader support for the Anysee devices by extending Antti Palosaari's driver. I attached the patches for it. It registers a character device named /dev/anysee_scN for each Anysee device. The character device supports two ioctl's (see anysee_sc), one for detecting the presence of a card, the other one for resetting the card and querying the ATR. The write() operation writes to the card by packaging the bytes into USB commands. The read() operation issues an appropriate command over USB and returns the reply. I have also written a simple OpenCT driver (attached) which shows the usage. I would like to have the kernel driver included in the official sources. For this reason I corresponded with Antti, and he suggested the perhaps the kernel driver should have a lower-level interface. I had the following proposal: We would continue having the two ioctls, ANYSEE_SC_ACTIVATE and ANYSEE_SC_PRESENT, however, ANYSEE_SC_ACTIVATE would do only the register reading and writing. Besides these two we need access to the anysee_ctrl_msg() function somehow. I think the cleanest way would be via another ioctl() call in which we would pass the return buffer as well, with the length so that we know how many bytes to copy. Another possibility would be that a call to write() calls anysee_ctrl_msg() and stores the return data in a 64 byte buffer that we allocate for each device. The read() following a write() would read this buffer, then discard it. Further read() attempts would fail with EAGAIN, or we could maintain an offset into the 64 byte buffer, and read as long as there is data, and fail only then. A write() would cause losing any unread data. What do you think? Thanks, Istvan -- 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
Re: PCTV 290e - assorted problems
On 08/15/2011 02:56 AM, Chris Rankin wrote: tuning status == 0x0f tuning status == 0x0f WARNING: tuning failed!!! ERROR: initial tuning failed dumping lists (0 services) Done. Although it was working (briefly) on Saturday morning. Have you tried it on Windows? No, because I don't own a Windows machine. Most likely demod does not got full lock since weak/noisy signal. It is possible to increase lock waiting time from changing driver but it is not wise before signal is known to be good enough. 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
dvb-apps: update DVB-T intial tuning files for Finland (fi-*)
Moi Christoph, Updates all Finnish channels as today. Antti -- http://palosaari.fi/ diff -r 36a084aace47 util/scan/dvb-t/fi-Alajarvi --- a/util/scan/dvb-t/fi-Alajarvi Sat Jul 16 17:42:28 2011 +0200 +++ b/util/scan/dvb-t/fi-Alajarvi Mon Aug 15 03:30:49 2011 +0300 @@ -2,4 +2,5 @@ # T freq bw fec_hi fec_lo mod transmission-mode guard-interval hierarchy T 64200 8MHz 2/3 NONE QAM64 8k 1/8 NONE T 73000 8MHz 2/3 NONE QAM64 8k 1/8 NONE +T 77800 8MHz 2/3 NONE QAM64 8k 1/8 NONE T 57800 8MHz 2/3 NONE QAM64 8k 1/8 NONE diff -r 36a084aace47 util/scan/dvb-t/fi-Hanko --- a/util/scan/dvb-t/fi-Hanko Sat Jul 16 17:42:28 2011 +0200 +++ b/util/scan/dvb-t/fi-Hanko Mon Aug 15 03:30:49 2011 +0300 @@ -1,5 +1,6 @@ # automatically generated from http://www.digitv.fi/sivu.asp?path=1;8224;9519 # T freq bw fec_hi fec_lo mod transmission-mode guard-interval hierarchy -T 61800 8MHz 2/3 NONE QAM64 8k 1/8 NONE -T 74600 8MHz 2/3 NONE QAM64 8k 1/8 NONE -T 70600 8MHz 2/3 NONE QAM64 8k 1/8 NONE +T 59400 8MHz 2/3 NONE QAM64 8k 1/8 NONE +T 57000 8MHz 2/3 NONE QAM64 8k 1/8 NONE +T 69000 8MHz 2/3 NONE QAM64 8k 1/8 NONE +T 51400 8MHz 2/3 NONE QAM64 8k 1/8 NONE diff -r 36a084aace47 util/scan/dvb-t/fi-Hartola --- a/util/scan/dvb-t/fi-HartolaSat Jul 16 17:42:28 2011 +0200 +++ b/util/scan/dvb-t/fi-HartolaMon Aug 15 03:30:49 2011 +0300 @@ -2,3 +2,4 @@ # T freq bw fec_hi fec_lo mod transmission-mode guard-interval hierarchy T 51400 8MHz 2/3 NONE QAM64 8k 1/8 NONE T 60200 8MHz 2/3 NONE QAM64 8k 1/8 NONE +T 64200 8MHz 2/3 NONE QAM64 8k 1/8 NONE diff -r 36a084aace47 util/scan/dvb-t/fi-Heinavesi --- a/util/scan/dvb-t/fi-Heinavesi Sat Jul 16 17:42:28 2011 +0200 +++ b/util/scan/dvb-t/fi-Heinavesi Mon Aug 15 03:30:49 2011 +0300 @@ -2,3 +2,4 @@ # T freq bw fec_hi fec_lo mod transmission-mode guard-interval hierarchy T 65800 8MHz 2/3 NONE QAM64 8k 1/8 NONE T 70600 8MHz 2/3 NONE QAM64 8k 1/8 NONE +T 51400 8MHz 2/3 NONE QAM64 8k 1/8 NONE diff -r 36a084aace47 util/scan/dvb-t/fi-Heinola --- a/util/scan/dvb-t/fi-HeinolaSat Jul 16 17:42:28 2011 +0200 +++ b/util/scan/dvb-t/fi-HeinolaMon Aug 15 03:30:49 2011 +0300 @@ -2,5 +2,5 @@ # T freq bw fec_hi fec_lo mod transmission-mode guard-interval hierarchy T 55400 8MHz 2/3 NONE QAM64 8k 1/8 NONE T 78600 8MHz 2/3 NONE QAM64 8k 1/8 NONE -T 82600 8MHz 2/3 NONE QAM64 8k 1/8 NONE +T 53000 8MHz 2/3 NONE QAM64 8k 1/8 NONE T 70600 8MHz 2/3 NONE QAM64 8k 1/8 NONE diff -r 36a084aace47 util/scan/dvb-t/fi-Houtskari --- a/util/scan/dvb-t/fi-Houtskari Sat Jul 16 17:42:28 2011 +0200 +++ b/util/scan/dvb-t/fi-Houtskari Mon Aug 15 03:30:49 2011 +0300 @@ -2,4 +2,5 @@ # T freq bw fec_hi fec_lo mod transmission-mode guard-interval hierarchy T 62600 8MHz 2/3 NONE QAM64 8k 1/8 NONE T 68200 8MHz 2/3 NONE QAM64 8k 1/8 NONE +T 57800 8MHz 2/3 NONE QAM64 8k 1/8 NONE T 52200 8MHz 2/3 NONE QAM64 8k 1/8 NONE diff -r 36a084aace47 util/scan/dvb-t/fi-Hyrynsalmi --- a/util/scan/dvb-t/fi-Hyrynsalmi Sat Jul 16 17:42:28 2011 +0200 +++ b/util/scan/dvb-t/fi-Hyrynsalmi Mon Aug 15 03:30:49 2011 +0300 @@ -2,3 +2,4 @@ # T freq bw fec_hi fec_lo mod transmission-mode guard-interval hierarchy T 62600 8MHz 2/3 NONE QAM64 8k 1/8 NONE T 65800 8MHz 2/3 NONE QAM64 8k 1/8 NONE +T 57800 8MHz 2/3 NONE QAM64 8k 1/8 NONE diff -r 36a084aace47 util/scan/dvb-t/fi-Hyrynsalmi_Kyparavaara --- a/util/scan/dvb-t/fi-Hyrynsalmi_Kyparavaara Sat Jul 16 17:42:28 2011 +0200 +++ b/util/scan/dvb-t/fi-Hyrynsalmi_Kyparavaara Mon Aug 15 03:30:49 2011 +0300 @@ -2,3 +2,4 @@ # T freq bw fec_hi fec_lo mod transmission-mode guard-interval hierarchy T 62600 8MHz 2/3 NONE QAM64 8k 1/8 NONE T 65800 8MHz 2/3 NONE QAM64 8k 1/8 NONE +T 49800 8MHz 2/3 NONE QAM64 8k 1/8 NONE diff -r 36a084aace47 util/scan/dvb-t/fi-Hyvinkaa_Musta-Mannisto --- a/util/scan/dvb-t/fi-Hyvinkaa_Musta-MannistoSat Jul 16 17:42:28 2011 +0200 +++ b/util/scan/dvb-t/fi-Hyvinkaa_Musta-MannistoMon Aug 15 03:30:49 2011 +0300 @@ -2,4 +2,5 @@ # T freq bw fec_hi fec_lo mod transmission-mode guard-interval hierarchy T 53800 8MHz 2/3 NONE QAM64 8k 1/8 NONE T 69800 8MHz 2/3 NONE QAM64 8k 1/8 NONE +T 35000 8MHz 2/3 NONE QAM64 8k 1/8 NONE T 75400 8MHz 2/3 NONE QAM64 8k 1/8 NONE diff -r 36a084aace47 util/scan/dvb-t/fi-Ikaalinen --- a/util/scan/dvb-t/fi-Ikaalinen Sat Jul 16 17:42:28 2011 +0200 +++ b/util/scan/dvb-t/fi-Ikaalinen Mon Aug 15 03:30:49 2011 +0300 @@ -2,4 +2,5 @@ # T freq bw fec_hi fec_lo mod transmission-mode guard-interval hierarchy T 53800 8MHz 2/3 NONE QAM64 8k 1/8 NONE T 65800 8MHz 2/3 NONE QAM64 8k 1/8 NONE +T 76200 8MHz 2/3 NONE QAM64 8k 1/8 NONE T 61800 8MHz 2/3 NONE QAM64 8k 1/8 NONE diff -r 36a084aace47 util/scan/dvb-t/fi-Ikaalinen_Riitiala --- a/util/scan/dvb-t/fi-Ikaalinen_Riitiala Sat Jul 16 17:42:28 2011 +0200 +++
Re: dvb-apps: update DVB-T intial tuning files for Finland (fi-*)
On 08/15/2011 12:56 PM, Hein Rigolo wrote: On Mon, Aug 15, 2011 at 2:38 AM, Antti Palosaari cr...@iki.fi wrote: Updates all Finnish channels as today. Antti Do we still need to have separate initial tuning files per region in finland? For France it was decided that the auto-With167kHzOffsets file would be enough to find all possible DVB-T transponders in France. It was suggested to create a fr-All that would be symlinked to the auto-With167kHzOffsets file, but that was not implemented yet (as far as I can see from the dvb-apps repository) Can this approach also work for Finland? It was spoken ages for creation of EU-All, Taiwan-All, UK-All etc. but I don't remember which have been problem. For example many Windows channels scanner have such files. Finland uses standard EU channels, channels under 20 are VHF 7 MHz and channels over 20 are UHF 8 MHz. Just same used almost everywhere in EU. 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
Re: Smart card reader support for Anysee DVB devices
On 08/15/2011 02:51 AM, Antti Palosaari wrote: Biggest problem I see whole thing is poor application support. OpenCT is rather legacy but there is no good alternative. All this kind of serial drivers seems to be OpenCT currently. I wonder if it is possible to make virtual CCID device since CCID seems to be unfortunately the only interface SmartCard guys currently care. 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
Re: Afatech AF9013
On 08/16/2011 11:27 PM, Jose Alberto Reguero wrote: options dvb-usb force_pid_filter_usage=1 I change the signal timeout and tuning timeout and now it works perfect! I can watch two HD channels, thanks for your help. I really don't understand what force_pid_filter_usage do on the module, is there any documentation? Thanks and best regards. For usb devices with usb 2.0 when tunned to a channel there is enought usb bandwith to deliver the whole transponder. With pid filters they only deliver the pids needed for the channel. The only limit is that the pid filters is limited normaly to 32 pids. May I ask how wide DVB-T streams you have? Here in Finland it is about 22 Mbit/sec and I think two such streams should be too much for one USB bus. I suspect there is some other bug in back of this. 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
Re: Afatech AF9013
On 08/17/2011 10:36 AM, Josu Lazkano wrote: I don't know how wide is the stream, but it could be a USB wide limitation. My board is a little ION based and I have some USB devices: $ lsusb Bus 001 Device 002: ID 1b80:e399 Afatech Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub I don't think so. Total under 50Mbit/sec stream should not be too much for one USB2.0 root hub. Which is chipset used ION (it is southbridge which contains usually USB ports)? The problematic twin device is the Afatech one, there is an DVB-S2 USB tuner, a bluetooth dongle, a IR receiver and a wireless mouse/keybord receiver. Now I am at work, I will try to disconnect all devices and try with just the DVB-T device. I use to try with MythTV if it works or not. Is there any other tool to test and debug more deep about USB or DVB wide? You can look stream sizes using dvbtraffic tool. It is last line of output which shows total stream size. tzap can be used to tune channel. But it you can use some other app like MythTV and then run dvbtraffic same time. I apreciate your help. Thanks and best regards. 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
Re: Smart card reader support for Anysee DVB devices
On 08/15/2011 02:14 PM, Antti Palosaari wrote: On 08/15/2011 02:51 AM, Antti Palosaari wrote: Biggest problem I see whole thing is poor application support. OpenCT is rather legacy but there is no good alternative. All this kind of serial drivers seems to be OpenCT currently. I wonder if it is possible to make virtual CCID device since CCID seems to be unfortunately the only interface SmartCard guys currently care. I studied scenario and looks like it is possible to implement way like, register virtual USB HCI (virtual motherboard USB controller) then register virtual PC/SC device to that which hooks all calls to HW via Anysee driver. Some glue surely needed for emulate PC/SC. I think there is not any such driver yet. Anyhow, there is virtual USB HCI driver currently in staging which can be used as example, or even use it to register virtual device. That kind of functionality surely needs more talking... 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
offer for Conax CAM exchange
I ordered two different Conax CAMs for Anysee development but unfortunately got just same CAMs with different brands. As a CI/CAM driver development there is no idea having two similar CAMs. Anyone willing to exchange Conax CAMs or maybe some other encryption? Those are branded as SMIT and the other is LA Digital (SMIT seems to be original brand). SMITDVB CA Module DVB_CI_V1.00 CAM Application manufacturer: cafe CAM Manufacturer code: babe 1. Software version: CNX-STD-2.5.9 2. Hardware version: 2.2.1 8. CA_SYS_ID: 0x0b00 9. CIM Build Date : Jul 28 2009 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
flag DVB_CA_EN50221_POLL_CAM_READY
Why this flag is defined? I don't see how interface driver can know CAM is ready (after plug or reset) unless it reads that info from CAM itself. Thus, I think correct behaviour should be move that detection functionality to the EN50221 CA core. Looking from existing drivers can confirm that. Those just returns that flag when CAM is present (plugged in slot) with DVB_CA_EN50221_POLL_CAM_PRESENT flag. OR read directly CAM memory to see it answers and set flag according to that (which should be job of EN50221 CA core IMHO). 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
Re: [PATH v2] cxd2820r: fix possible out-of-array lookup
Mauro, don't apply that patch since it is now obsolete after another
patch [1] from Steve Kerrison.
[1] https://patchwork.kernel.org/patch/1048832/
regards
Antti
On 07/29/2011 03:54 PM, Antti Palosaari wrote:
On 07/29/2011 09:57 AM, HoP wrote:
When I2C_WRITE is used the msg[] array contains one element only.
Don't access msg[1] in that case. Also moved rest of msg2[1]
setting to be used only if needed.
Signed-off-by: Honza Petrous jpetr...@smartimp.cz
Acked-by: Antti Palosaari cr...@iki.fi
---
diff -r ae517614bf00 drivers/media/dvb/frontends/cxd2820r_core.c
--- a/drivers/media/dvb/frontends/cxd2820r_core.cThu Jul 28 15:44:49
2011 +0200
+++ b/drivers/media/dvb/frontends/cxd2820r_core.cThu Jul 28 16:20:17
2011 +0200
@@ -747,12 +747,7 @@ static int cxd2820r_tuner_i2c_xfer(struc
.flags = 0,
.len = sizeof(obuf),
.buf = obuf,
-}, {
-.addr = priv-cfg.i2c_address,
-.flags = I2C_M_RD,
-.len = msg[1].len,
-.buf = msg[1].buf,
-}
+},
};
obuf[0] = 0x09;
@@ -760,6 +755,11 @@ static int cxd2820r_tuner_i2c_xfer(struc
if (num == 2) { /* I2C read */
obuf[1] = (msg[0].addr 1) | I2C_M_RD; /* I2C RD flag */
msg2[0].len = sizeof(obuf) - 1; /* maybe HW bug ? */
+
+msg2[1].addr = priv-cfg.i2c_address,
+msg2[1].flags = I2C_M_RD,
+msg2[1].len = msg[1].len,
+msg2[1].buf = msg[1].buf,
}
memcpy(obuf[2], msg[0].buf, msg[0].len);
--
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
usb_set_intfdata usage for two subdrivers
I am trying to implement DVB USB device smartcard reader support using USB-serial. The main problem is now that both DVB-USB and USB-serial uses interface data (usb_set_intfdata / usb_get_intfdata) for state. Is there any common solution to resolve issue easily? 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
Re: Smart card reader support for Anysee DVB devices
On 08/29/2011 05:44 PM, István Váradi wrote: Hi, 2011/8/17 Antti Palosaaricr...@iki.fi: On 08/15/2011 02:14 PM, Antti Palosaari wrote: On 08/15/2011 02:51 AM, Antti Palosaari wrote: Biggest problem I see whole thing is poor application support. OpenCT is rather legacy but there is no good alternative. All this kind of serial drivers seems to be OpenCT currently. I wonder if it is possible to make virtual CCID device since CCID seems to be unfortunately the only interface SmartCard guys currently care. I studied scenario and looks like it is possible to implement way like, register virtual USB HCI (virtual motherboard USB controller) then register virtual PC/SC device to that which hooks all calls to HW via Anysee driver. Some glue surely needed for emulate PC/SC. I think there is not any such driver yet. Anyhow, there is virtual USB HCI driver currently in staging which can be used as example, or even use it to register virtual device. That kind of functionality surely needs more talking... It maybe that smartcard guys care only for CCID, but wouldn't it be an overkill to implement an emulation of that for the driver? It can be done, of course, but I think it would be much more complicated than the current one. Is it really necessary to put such complexity into the kernel? In my opinion, this should be handled in user-space. Only De facto serial smartcard protocol is so called Phoenix/Smartmouse, implementing new protocol is totally dead idea. It will never got any support. There is already such drivers, at least Infinity Unlimited USB Phoenix driver (iuu_phoenix.c). It uses USB-serial driver framework and some small emulation for Phoenix protocol. Look that driver to see which kind of complexity it adds. Anysee have *just* same situation. 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
Re: Smart card reader support for Anysee DVB devices
On 08/29/2011 06:13 PM, István Váradi wrote: 2011/8/29 Antti Palosaaricr...@iki.fi: On 08/29/2011 05:44 PM, István Váradi wrote: 2011/8/17 Antti Palosaaricr...@iki.fi: On 08/15/2011 02:14 PM, Antti Palosaari wrote: On 08/15/2011 02:51 AM, Antti Palosaari wrote: Biggest problem I see whole thing is poor application support. OpenCT is rather legacy but there is no good alternative. All this kind of serial drivers seems to be OpenCT currently. I wonder if it is possible to make virtual CCID device since CCID seems to be unfortunately the only interface SmartCard guys currently care. I studied scenario and looks like it is possible to implement way like, register virtual USB HCI (virtual motherboard USB controller) then register virtual PC/SC device to that which hooks all calls to HW via Anysee driver. Some glue surely needed for emulate PC/SC. I think there is not any such driver yet. Anyhow, there is virtual USB HCI driver currently in staging which can be used as example, or even use it to register virtual device. That kind of functionality surely needs more talking... It maybe that smartcard guys care only for CCID, but wouldn't it be an overkill to implement an emulation of that for the driver? It can be done, of course, but I think it would be much more complicated than the current one. Is it really necessary to put such complexity into the kernel? In my opinion, this should be handled in user-space. Only De facto serial smartcard protocol is so called Phoenix/Smartmouse, implementing new protocol is totally dead idea. It will never got any support. There is already such drivers, at least Infinity Unlimited USB Phoenix driver (iuu_phoenix.c). It uses USB-serial driver framework and some small emulation for Phoenix protocol. Look that driver to see which kind of complexity it adds. Anysee have *just* same situation. Phoenix/Smartmouse and CCID are quite different aren't they? So to support Phoenix I would need provide a USB serial device which talks the protocol, but there would be no need for a virtual USB HCI. Is that correct? Yes, CCID and serial are different interfaces. CCID is new interface specified by USB organization that needs hardware level interface profile like mass storage profile. Serial is block device interface (/dev/tty). Since Anysee device itself does not have CCID interface it is needed to make virtual USB device in order to get CCID support. I have never seen virtual USB devices like that, but there is VHCI in current kernel staging that actually does something like that over IP. 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
Re: Smart card reader support for Anysee DVB devices
On 09/02/2011 02:04 PM, Bjørn Mork wrote: Antti Palosaaricr...@iki.fi writes: Since Anysee device itself does not have CCID interface it is needed to make virtual USB device in order to get CCID support. I have never seen virtual USB devices like that, but there is VHCI in current kernel staging that actually does something like that over IP. Don't know if you have seen this already, but there's a virtual CCID device implementation in QEMU. See http://wiki.qemu.org/Features/Smartcard Should be a good starting point. Combine it withe the VHCI driver from USBIP and you have your CCID device. It is first time I hear about QEMU virtual CCID. Now we have all parts needed for USBIP VHCI and QEMU virtual CCID, just glue those together. I wonder if it is wise to even create virtual CCID core to Kernel. There is few other readers that can use that too, actually I think all USB readers that have unique USB ID (blocking out those which uses USB-serial converters with common IDs). As I see that CCID still more complex as serial device I will still look implementing it as serial as now. 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
Re: [PATCH] [media] dvb-core, tda18271c2dd: define get_if_frequency() callback
On 09/03/2011 06:12 PM, Mauro Carvalho Chehab wrote: The DRX-K frontend needs to know the IF frequency in order to work, just like all other frontends. However, as it is a multi-standard FE, the IF may change if the standard is changed. So, the usual procedure of passing it via a config struct doesn't work. One might code it as two separate IF frequencies, one by each type of FE, but, as, on tda18271, the IF changes if the bandwidth for DVB-C changes, this also won't work. So, the better is to just add a new callback for it and require it for the tuners that can be used with MFE frontends like drx-k. It makes sense to add support for it on all existing tuners, and remove the IF parameter from the demods, cleaning up the code. Is it clear that only used tuner IC defines used IF? I have seen some cases where used IF is different depending on other used hardware, even same tuner IC used. Very good example is to see all configuration structs of old tda18271 driver. Those are mainly used for setting different IF than tuner default... 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
Re: [PATCH] [media] dvb-core, tda18271c2dd: define get_if_frequency() callback
On 09/03/2011 06:24 PM, Antti Palosaari wrote: On 09/03/2011 06:12 PM, Mauro Carvalho Chehab wrote: The DRX-K frontend needs to know the IF frequency in order to work, just like all other frontends. However, as it is a multi-standard FE, the IF may change if the standard is changed. So, the usual procedure of passing it via a config struct doesn't work. One might code it as two separate IF frequencies, one by each type of FE, but, as, on tda18271, the IF changes if the bandwidth for DVB-C changes, this also won't work. So, the better is to just add a new callback for it and require it for the tuners that can be used with MFE frontends like drx-k. It makes sense to add support for it on all existing tuners, and remove the IF parameter from the demods, cleaning up the code. Is it clear that only used tuner IC defines used IF? I have seen some cases where used IF is different depending on other used hardware, even same tuner IC used. Very good example is to see all configuration structs of old tda18271 driver. Those are mainly used for setting different IF than tuner default... Hmm, I think that will actually only reduce defining same IFs to demod which are already set to tuner allowing to remove redundant demod definitions. OK, now it looks fine for me. Acked-by: Antti Palosaari cr...@iki.fi 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
ERROR: em28xx_add_into_devlist [drivers/media/video/em28xx/em28xx.ko] undefined!
Moikka, Current linux-media make gives error. Any idea what's wrong? Kernel: arch/x86/boot/bzImage is ready (#1) Building modules, stage 2. MODPOST 1907 modules ERROR: em28xx_add_into_devlist [drivers/media/video/em28xx/em28xx.ko] undefined! WARNING: modpost: Found 2 section mismatch(es). To see full details build your kernel with: 'make CONFIG_DEBUG_SECTION_MISMATCH=y' make[1]: *** [__modpost] Error 1 make: *** [modules] Error 2 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
Re: ERROR: em28xx_add_into_devlist [drivers/media/video/em28xx/em28xx.ko] undefined!
On 09/05/2011 03:15 AM, Chris Rankin wrote: On 05/09/11 00:46, Antti Palosaari wrote: Moikka, Current linux-media make gives error. Any idea what's wrong? Kernel: arch/x86/boot/bzImage is ready (#1) Building modules, stage 2. MODPOST 1907 modules ERROR: em28xx_add_into_devlist [drivers/media/video/em28xx/em28xx.ko] undefined! WARNING: modpost: Found 2 section mismatch(es). To see full details build your kernel with: 'make CONFIG_DEBUG_SECTION_MISMATCH=y' make[1]: *** [__modpost] Error 1 make: *** [modules] Error 2 The function em28xx_add_into_devlist() should have been deleted as part of this change: http://git.linuxtv.org/media_tree.git?a=commitdiff;h=6c03e38b34dcfcdfa2f10cf984995a48f030f039 Its only reference should have been removed at the same time. git grep m28xx_add_into_devlis drivers/media/ drivers/media/video/em28xx/em28xx-cards.c: em28xx_add_into_devlist(dev); drivers/media/video/em28xx/em28xx.h:void em28xx_add_into_devlist(struct em28xx *dev); If you select em28xx-cards.c blob link you give you can see it is there still for some reason. 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
checkpatch.pl WARNING: Do not use whitespace before Signed-off-by:
I am almost sure this have been working earlier, but now it seems like nothing is acceptable for checkpatch.pl! I did surely about 20 --amend and tried to remove everything, without luck. Could someone point out whats new acceptable logging format for checkpatch.pl ? [crope@localhost linux]$ git show 1b19e42952963ae2a09a655f487de15b7c81c5b7 |./scripts/checkpatch.pl - WARNING: Do not use whitespace before Signed-off-by: #10: Signed-off-by: Joe Perches j...@perches.com WARNING: Do not use whitespace before Signed-off-by: #11: Signed-off-by: Mauro Carvalho Chehab mche...@redhat.com total: 0 errors, 2 warnings, 48 lines checked Your patch has style problems, please review. If any of these errors are false positives, please report them to the maintainer, see CHECKPATCH in MAINTAINERS. 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
Re: checkpatch.pl WARNING: Do not use whitespace before Signed-off-by:
On 09/06/2011 10:50 AM, Bjørn Mork wrote: Antti Palosaaricr...@iki.fi writes: I am almost sure this have been working earlier, but now it seems like nothing is acceptable for checkpatch.pl! I did surely about 20 --amend and tried to remove everything, without luck. Could someone point out whats new acceptable logging format for checkpatch.pl ? [crope@localhost linux]$ git show 1b19e42952963ae2a09a655f487de15b7c81c5b7 |./scripts/checkpatch.pl - WARNING: Do not use whitespace before Signed-off-by: Don't know if checkpatch used to accept that, but you can use --format=email to make it work with git show: bjorn@canardo:/usr/local/src/git/linux$ git show --format=email 1b19e42952963ae2a09a655f487de15b7c81c5b7|./scripts/checkpatch.pl - total: 0 errors, 0 warnings, 48 lines checked Your patch has no obvious style problems and is ready for submission. Yes, I found it. It was rather new patch adding more checks. As a you pointed that can be workaround giving --format=email as a param for git show. But it is yet another useless param to remember... So what is recommended way to ensure patch is correct currently? a) before commit b) after commit commit 2011247550c1b903a9ecd68f6eb3e9e7b7b07f52 Author: Joe Perches j...@perches.com Date: Mon Jul 25 17:13:23 2011 -0700 checkpatch: validate signature styles and To: and Cc: lines Signatures have many forms and can sometimes cause problems if not in the correct format when using git send-email or quilt. Try to verify the signature tags and email addresses to use the generally accepted Signed-off-by: Full Name em...@domain.tld form. Original idea by Anish Kumar anish198519851...@gmail.com 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
Re: checkpatch.pl WARNING: Do not use whitespace before Signed-off-by:
On 09/06/2011 06:15 PM, Joe Perches wrote: On Tue, 2011-09-06 at 17:41 +0300, Antti Palosaari wrote: So what is recommended way to ensure patch is correct currently? a) before commit Use checkpatch. b) after commit Make the output of the commit log look like a patch. --format=email But still that sounds annoying, GIT is our default tool for handling patches and all the other tools like checkpatch.pl should honour that without any tricks. Why you don't add some detection logic to checkpatch.pl or even some new switch like --git. 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
Re: checkpatch.pl WARNING: Do not use whitespace before Signed-off-by:
On 09/06/2011 07:10 PM, Joe Perches wrote: On Tue, 2011-09-06 at 18:30 +0300, Antti Palosaari wrote: On 09/06/2011 06:15 PM, Joe Perches wrote: On Tue, 2011-09-06 at 17:41 +0300, Antti Palosaari wrote: So what is recommended way to ensure patch is correct currently? a) before commit Use checkpatch. b) after commit Make the output of the commit log look like a patch. --format=email But still that sounds annoying, GIT is our default tool for handling patches and all the other tools like checkpatch.pl should honour that without any tricks. Why you don't add some detection logic to checkpatch.pl or even some new switch like --git. checkpatch is, as the name shows, for patches. I think using checkpatch on commit logs is not really useful. But that's what I have done every time I have added patches coming community. And also for my own patches. And when problem is found it is easy to git commit --amend and fix it. I think I am not the only maintainer who checks incoming patches like this way - you will got surely more feedback when that version of checkpatch will get more usage. If you're using checkpatch on commit logs, format the commit log output appropriately or use --ignore=BAD_SIGN_OFF or add that --ignore= to a .checkpatch.conf if you really must. hmm, lets see. Maybe I will add --format=email as keyboard shortcut button. 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
Re: [PATCH 2/3] dvb-usb: multi-frontend support (MFE)
On 08/01/2011 05:24 AM, Mauro Carvalho Chehab wrote: Em 31-07-2011 22:22, Antti Palosaari escreveu: On 08/01/2011 03:46 AM, Mauro Carvalho Chehab wrote: One bad thing I noticed with the API is that it calls adap-props.frontend_attach(adap) several times, instead of just one, without even passing an argument for the driver to know that it was called twice. IMO, there are two ways of doing the attach: 1) call it only once, and, inside the driver, it will loop to add the other FE's; 2) add a parameter, at the call, to say what FE needs to be initialized. I think (1) is preferred, as it is more flexible, allowing the driver to test for several types of frontends. I am planning to change DVB USB MFE call .frontend_attach() only once. Is there any comments about that? Currently there is anysee, ttusb2 and cx88 drivers which uses MFE and change is needed ASAP before more MFE devices are coming. Also .num_frontends can be removed after that, since DVB USB will just loop through 0 to MAX FEs and register all FEs found (fe pointer !NULL). CURRENTLY: == .frontend_attach() if (adap-fe_adap[0].fe == NULL) adap-fe_adap[0].fe = dvb_attach(DVB-T) else if (adap-fe_adap[1].fe == NULL) adap-fe_adap[1].fe = dvb_attach(DVB-C) else if (adap-fe_adap[2].fe == NULL) adap-fe_adap[2].fe = dvb_attach(DVB-S) PLANNED: .frontend_attach() adap-fe_adap[0].fe = dvb_attach(DVB-T) adap-fe_adap[1].fe = dvb_attach(DVB-C) adap-fe_adap[2].fe = dvb_attach(DVB-S) 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
Re: [PATCH 2/3] dvb-usb: multi-frontend support (MFE)
On 09/07/2011 08:45 PM, Michael Krufky wrote: On Wed, Sep 7, 2011 at 1:41 PM, Michael Krufkymkru...@kernellabs.com wrote: On Wed, Sep 7, 2011 at 12:51 PM, Antti Palosaaricr...@iki.fi wrote: On 08/01/2011 05:24 AM, Mauro Carvalho Chehab wrote: Em 31-07-2011 22:22, Antti Palosaari escreveu: On 08/01/2011 03:46 AM, Mauro Carvalho Chehab wrote: One bad thing I noticed with the API is that it calls adap-props.frontend_attach(adap) several times, instead of just one, without even passing an argument for the driver to know that it was called twice. IMO, there are two ways of doing the attach: 1) call it only once, and, inside the driver, it will loop to add the other FE's; 2) add a parameter, at the call, to say what FE needs to be initialized. I think (1) is preferred, as it is more flexible, allowing the driver to test for several types of frontends. I am planning to change DVB USB MFE call .frontend_attach() only once. Is there any comments about that? Currently there is anysee, ttusb2 and cx88 drivers which uses MFE and change is needed ASAP before more MFE devices are coming. Also .num_frontends can be removed after that, since DVB USB will just loop through 0 to MAX FEs and register all FEs found (fe pointer !NULL). CURRENTLY: == .frontend_attach() if (adap-fe_adap[0].fe == NULL) adap-fe_adap[0].fe = dvb_attach(DVB-T) else if (adap-fe_adap[1].fe == NULL) adap-fe_adap[1].fe = dvb_attach(DVB-C) else if (adap-fe_adap[2].fe == NULL) adap-fe_adap[2].fe = dvb_attach(DVB-S) PLANNED: .frontend_attach() adap-fe_adap[0].fe = dvb_attach(DVB-T) adap-fe_adap[1].fe = dvb_attach(DVB-C) adap-fe_adap[2].fe = dvb_attach(DVB-S) Antti, I don't understand exactly what you are proposing -- Is this a change for the anysee driver? ...or is it a change for the dvb-usb framework? ...or is it a change to dvb-core, and every driver in the subsystem? In the anysee driver, I see that you are using this: .frontend_attach() if (adap-fe_adap[0].fe == NULL) adap-fe_adap[0].fe = dvb_attach(DVB-T) else if (adap-fe_adap[1].fe == NULL) adap-fe_adap[1].fe = dvb_attach(DVB-C) else if (adap-fe_adap[2].fe == NULL) adap-fe_adap[2].fe = dvb_attach(DVB-S) I have no problem if you want to change the anysee driver to remove the second dvb_usb_adap_fe_props context, and replace with the following: .frontend_attach() adap-fe_adap[0].fe = dvb_attach(DVB-T) adap-fe_adap[1].fe = dvb_attach(DVB-C) adap-fe_adap[2].fe = dvb_attach(DVB-S) I believe this will work in the anysee driver for you, even with my changes that got merged yesterday... However, I do *not* believe that such change should propogate to the dvb-usb framework or dvb-core itself, because it can have a large negative impact on the drivers using it. For example, my mxl111sf driver was merged yesterday. Since it is the initial driver merge, it currently only supports one frontend (ATSC). The device also supports two other delivery systems, and has two additional dtv demodulators, each attached via a separate input bus to the USB device, each streaming on a separate USB endpoint. Many demod drivers do an ID test or some other kind of initialization during the _attach() function. A device like the mxl111sf would have to manipulate the USB device state and alter the bus operations before and after each frontend attachment in order for the _attach() calls to succeed, not to mention the separate calls needed for bus negotiation to power on the correct demodulator and initialize its streaming data path. I repeat, if this is a change that is specific to your anysee driver, then it seems like a good idea to me. However, if your plan is to change dvb-usb itself, and / or dvb-core, then I'd really like to have a better idea of the implications that this change will bring forth. So, to help reduce the confusion, can you clarify exactly what code you plan to change, and what impact it will have on the drivers that exist today? Best Regards, Michael Krufky ADDENDUM: For the anysee driver, for your single .frontend_attach() adap-fe_adap[0].fe = dvb_attach(DVB-T) adap-fe_adap[1].fe = dvb_attach(DVB-C) adap-fe_adap[2].fe = dvb_attach(DVB-S) ...for this to work in today's dvb-usb code without modification to the dvb-usb framework, i believe that you should do a test for (adap-fe_adap[0].fe adap-fe_adap[1].fe adap-fe_adap[2].fe ) ... if null, then attach, if not null, then exit -- this will prevent the second context's initialization from occurring twice. Yes, I now saw when looked latest anysee driver that you moved .streaming_ctrl(), .frontend_attach() and .tuner_attach() to frontend property. OK, it is not then relevant anymore to change register all as once. What is size_of_priv used? regards Antti -- http
Re: [PATCH 2/3] dvb-usb: multi-frontend support (MFE)
On 09/07/2011 09:36 PM, Michael Krufky wrote: On Wed, Sep 7, 2011 at 2:20 PM, Antti Palosaaricr...@iki.fi wrote: Yes, I now saw when looked latest anysee driver that you moved .streaming_ctrl(), .frontend_attach() and .tuner_attach() to frontend property. OK, it is not then relevant anymore to change register all as once. What is size_of_priv used? size_of_priv is a signal to the dvb-usb framework to allocate memory of size, size_of_priv to track device state at a given context. If you look in dvb-usb.h, there was always a size_of_priv / void *priv at the dvb_usb_device context level, and there was always a size_of_priv / void *priv at the dvb_usb_adapter context level. After my MFE patch, there is now a size_of_priv / void *priv at the dvb_usb_fe_adapter context level. This private state structure is used to track state at the context of each dvb_usb_fe_adap, to manage the environment needed to switch between the various attached frontends. You may take a look in mxl111sf.c to see how this is used (ie, struct mxl111sf_adap_state *adap_state = adap-fe_adap[fe-id].priv;) If size_of_priv is left undefined, it is initialized to 0, and the void *priv pointer remains null. I marvel at there was 3 states, one for device, one for each adapter and now even one for each frontend. Surely enough, generally only device state is used. And your new driver seems to even use that new FE priv added. 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
Re: [git:v4l-dvb/for_v3.2] [media] dvb-usb: refactor MFE code for individual streaming config per frontend
This patch seems to break all DVB USB devices we have. Michael, could you check and fix it asap. On 09/06/2011 08:21 PM, Mauro Carvalho Chehab wrote: This is an automatic generated email to let you know that the following patch were queued at the http://git.linuxtv.org/media_tree.git tree: Subject: [media] dvb-usb: refactor MFE code for individual streaming config per frontend Author: Michael Krufkymkru...@kernellabs.com Date:Tue Sep 6 09:31:57 2011 -0300 refactor MFE code to allow for individual streaming configuration for each frontend Signed-off-by: Michael Krufkymkru...@kernellabs.com Reviewed-by: Antti Palosaaricr...@iki.fi Signed-off-by: Mauro Carvalho Chehabmche...@redhat.com drivers/media/dvb/dvb-usb/dvb-usb-dvb.c | 141 ++- dvb_usb_ctrl_feed() if ((adap-feedcount == onoff) (!onoff)) adap-active_fe = -1; http://git.linuxtv.org/media_tree.git?a=commitdiff;h=77eed219fed5a913f59329cc846420fdeab0150f diff discarded since it is too big 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
Re: [git:v4l-dvb/for_v3.2] [media] dvb-usb: refactor MFE code for individual streaming config per frontend
This error is shown by VLC when channel changed: [0x7f1bbc000cd0] dvb access error: DMXSetFilter: failed with -1 (Invalid argument) [0x7f1bbc000cd0] dvb access error: DMXSetFilter failed [0x7f1bbc32f910] main stream error: cannot pre fill buffer but it seems to be related dvb_usb_ctrl_feed() I pointed earlier mail. Antti On 09/08/2011 12:18 AM, Antti Palosaari wrote: This patch seems to break all DVB USB devices we have. Michael, could you check and fix it asap. On 09/06/2011 08:21 PM, Mauro Carvalho Chehab wrote: This is an automatic generated email to let you know that the following patch were queued at the http://git.linuxtv.org/media_tree.git tree: Subject: [media] dvb-usb: refactor MFE code for individual streaming config per frontend Author: Michael Krufkymkru...@kernellabs.com Date: Tue Sep 6 09:31:57 2011 -0300 refactor MFE code to allow for individual streaming configuration for each frontend Signed-off-by: Michael Krufkymkru...@kernellabs.com Reviewed-by: Antti Palosaaricr...@iki.fi Signed-off-by: Mauro Carvalho Chehabmche...@redhat.com drivers/media/dvb/dvb-usb/dvb-usb-dvb.c | 141 ++- dvb_usb_ctrl_feed() if ((adap-feedcount == onoff) (!onoff)) adap-active_fe = -1; http://git.linuxtv.org/media_tree.git?a=commitdiff;h=77eed219fed5a913f59329cc846420fdeab0150f diff discarded since it is too big 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
recursive locking problem
I am working with AF9015 I2C-adapter lock. I need lock I2C-bus since there is two tuners having same I2C address on same bus, demod I2C gate is used to select correct tuner. I am trapping demod .i2c_gate_ctrl() calls and locking bus according to that. Is there any lock can do recursive locking but unlock frees all locks? Like that: gate_open +gate_open +gate_close == lock is free AFAIK mutex can do only simple lock() + unlock(). Semaphore can do recursive locking, like lock() + lock() + unlock() + unlock(). But how I can do lock() + lock() + unlock() == free. 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
[GIT PULL FOR 3.2] PCTV DVB-S2 Stick 460e
Morjens Mauro This patch series adds support for PCTV DVB-S2 Stick 460e, that is DVB-S2 USB stick. Is is based of; * Empia EM28174 * NXP TDA10071 Conexant CX24118A combo * Allegro A8293 It introduces two new chipset drivers namely tda10071 and a8293 - former is DVB-S/S2 demod + tuner combo and later is LNB controller. Also Chris Rankin em28xx bug fix is included since it wasn't committed to 3.2 tree as today. regards Antti The following changes since commit 2d04c13a507f5a01daa7422cd52250809573cfdb: [media] dvb-usb: improve sanity check of adap-active_fe in dvb_usb_ctrl_feed (2011-09-09 15:28:04 -0300) are available in the git repository at: git://linuxtv.org/anttip/media_tree.git pctv_460e Antti Palosaari (8): a8293: Allegro A8293 SEC driver tda10071: NXP TDA10071 DVB-S/S2 driver em28xx: add support for PCTV DVB-S2 Stick 460e [2013:024f] get_dvb_firmware: add dvb-fe-tda10071.fw get_dvb_firmware: update tda10071 file url tda10071: do not download last byte of fw tda10071: change sleeps to more suitable ones get_dvb_firmware: whitespace fix Chris Rankin (1): em28xx: ERROR: em28xx_add_into_devlist [drivers/media/video/em28xx/em28xx.ko] undefined! Documentation/dvb/get_dvb_firmware | 19 +- drivers/media/dvb/frontends/Kconfig | 12 + drivers/media/dvb/frontends/Makefile|2 + drivers/media/dvb/frontends/a8293.c | 184 drivers/media/dvb/frontends/a8293.h | 41 + drivers/media/dvb/frontends/tda10071.c | 1269 +++ drivers/media/dvb/frontends/tda10071.h | 81 ++ drivers/media/dvb/frontends/tda10071_priv.h | 122 +++ drivers/media/video/em28xx/Kconfig |2 + drivers/media/video/em28xx/em28xx-cards.c | 33 +- drivers/media/video/em28xx/em28xx-dvb.c | 25 + drivers/media/video/em28xx/em28xx.h |1 + 12 files changed, 1788 insertions(+), 3 deletions(-) create mode 100644 drivers/media/dvb/frontends/a8293.c create mode 100644 drivers/media/dvb/frontends/a8293.h create mode 100644 drivers/media/dvb/frontends/tda10071.c create mode 100644 drivers/media/dvb/frontends/tda10071.h create mode 100644 drivers/media/dvb/frontends/tda10071_priv.h -- http://palosaari.fi/ -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 1/1] EM28xx - fix deadlock when unplugging and replugging a DVB adapter
On 08/21/2011 03:32 PM, Chris Rankin wrote: It occurred to me this morning that since we're no longer supposed to be holding the device lock when taking the device list lock, then the em28xx_usb_disconnect() function needs changing too. Signed-off-by: Chris Rankin ranki...@yahoo.com I ran that also when re-plugging both PCTV 290e and 460e as today LinuxTV 3.2 tree. Seems like this patch is still missing and maybe some more. git log drivers/media/video/em28xx/ |grep -A3 Author: Chris Rankin Author: Chris Rankin ranki...@yahoo.com Date: Tue Sep 13 12:23:39 2011 +0300 em28xx: ERROR: em28xx_add_into_devlist [drivers/media/video/em28xx/em28xx.ko] undefined! -- Author: Chris Rankin ranki...@yahoo.com Date: Sat Aug 20 16:01:26 2011 -0300 [media] em28xx: don't sleep on disconnect -- Author: Chris Rankin ranki...@yahoo.com Date: Sat Aug 20 08:31:05 2011 -0300 [media] em28xx: move printk lines outside mutex lock -- Author: Chris Rankin ranki...@yahoo.com Date: Sat Aug 20 08:28:17 2011 -0300 [media] em28xx: clean up resources should init fail -- Author: Chris Rankin ranki...@yahoo.com Date: Sat Aug 20 08:21:03 2011 -0300 [media] em28xx: use atomic bit operations for devices-in-use mask -- Author: Chris Rankin ranki...@yahoo.com Date: Sat Aug 20 08:08:34 2011 -0300 [media] em28xx: pass correct buffer size to snprintf 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
Re: recursive locking problem
On 09/09/2011 01:45 PM, David Waring wrote:
On 08/09/11 17:34, Antti Palosaari wrote:
[snip]
Is there any lock can do recursive locking but unlock frees all locks?
Like that:
gate_open
+gate_open
+gate_close
== lock is free
AFAIK mutex can do only simple lock() + unlock(). Semaphore can do
recursive locking, like lock() + lock() + unlock() + unlock(). But how I
can do lock() + lock() + unlock() == free.
Antti,
It's a very bad idea to try and use a mutex like that. The number of
locks and unlocks must be balanced otherwise you risk accessing
variables without a lock.
Consider:
static struct mutex foo_mutex;
static int foo=3;
void a() {
mutex_lock(foo_mutex);
if (foo5) foo++;
b();
foo--; /* still need lock here */
mutex_unlock(foo_mutex);
}
void b() {
mutex_lock(foo_mutex);
if (foo6) foo=(foo1);
mutex_unlock(foo_mutex);
}
Note: this assumes mutex_lock will allow the same thread get multiple
locks as you would like (which it doesn't).
As pointed out in the code, when a() is called, you still need the lock
for accesses to foo after the call to b() that also requires the lock.
If we used the locks in the way you propose then foo would be accessed
without a lock.
To code properly for cases like these I usually use a wrapper functions
to acquire the lock and call a thread unsafe version (i.e. doesn't use
locks) of the function that only uses other thread unsafe functions. e.g.
void a() {
mutex_lock(foo_mutex);
__a_thr_unsafe();
mutex_unlock(foo_mutex);
}
void b() {
mutex_lock(foo_mutex);
__b_thr_unsafe();
mutex_unlock(foo_mutex);
}
static void __a_thr_unsafe() {
if (foo5) foo++;
__b_thr_unsafe();
foo--;
}
static void __b_thr_unsafe() {
if (foo6) foo=(foo1);
}
This way a call to a() or b() will acquire the lock once for that
thread, perform all actions and then release the lock. The mutex is
handled properly.
Can you restructure the code so that you don't need multiple locks?
Thank you for very long and detailed reply with examples :)
I need lock for hardware access. Single I2C-adapter have two I2C-clients
that have same I2C-address in same bus. There is gate (demod I2C-gate)
logic that is used to select desired tuner. See that:
http://palosaari.fi/linux/v4l-dvb/controlling_tuner_af9015_dual_demod.txt
You can never know surely how tuner drivers calls to open or close gate,
very commonly there is situations where multiple close or open happens.
That's why lock/unlock is problematic.
.i2c_gate_ctrl() is demod driver callback (struct dvb_frontend_ops)
which controls gate that gate. That callback is always called from tuner
driver when gate is needed to open or close.
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
Re: Compro U680F USB stick receiver for FM/DAB/DAB+/DVB-T.
On 09/14/2011 01:31 AM, Erik Dam wrote: I recently came across this interesting little USB device which seems the so far best bet on covering all the relevant standards for these parts of the woods (although it still misses out on DVB-T2 support). However, I have so far been unable to determine whether any level of linux support exists (and therefore whether it's useful or not). Anybody know if drivers exist? According to properties it must be Realtek RTL2832U based. It is only chip can do FM/DAB+/DVB-T. There is no community supported drivers but vendor drivers exits. Try those. 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
Re: recursive locking problem
On 09/09/2011 02:46 PM, Daniel Glöckner wrote: On Thu, Sep 08, 2011 at 07:34:32PM +0300, Antti Palosaari wrote: I am working with AF9015 I2C-adapter lock. I need lock I2C-bus since there is two tuners having same I2C address on same bus, demod I2C gate is used to select correct tuner. Would it be possible to use the i2c-mux framework to handle this? Each tuner will then have its own i2c bus. Interesting idea, but it didn't worked. It deadlocks. I think it locks since I2C-mux is controlled by I2C switch in same I2C bus, not GPIO or some other HW. * tuner does I2C xfer on I2C-mux adapter * I2C-mux adapter calls demod .i2c_gate_ctrl() * demod does register access using I2C * DEADLOCK Maybe since tuner I2C xfer have already locked I2C-adater. Then demod access same adapter and it is locked. But nice I2C mux anyhow. @David Daney, see that pic in order to get understanding what kind of problem I am working; http://palosaari.fi/linux/v4l-dv/controlling_tuner_af9015_dual_demod.txt 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
Re: recursive locking problem
On 09/14/2011 09:19 AM, Daniel Glöckner wrote: On Wed, Sep 14, 2011 at 04:03:58AM +0300, Antti Palosaari wrote: On 09/09/2011 02:46 PM, Daniel Glöckner wrote: On Thu, Sep 08, 2011 at 07:34:32PM +0300, Antti Palosaari wrote: I am working with AF9015 I2C-adapter lock. I need lock I2C-bus since there is two tuners having same I2C address on same bus, demod I2C gate is used to select correct tuner. Would it be possible to use the i2c-mux framework to handle this? Each tuner will then have its own i2c bus. Interesting idea, but it didn't worked. It deadlocks. I think it locks since I2C-mux is controlled by I2C switch in same I2C bus, not GPIO or some other HW. Take a look at drivers/i2c/muxes/pca954x.c. You need to use parent-algo-master_xfer/smbus_xfer directly as the lock that protects you from having both gates open is the lock of the root i2c bus. Ah yes, rather similar case. I see it as commented in pca954x.c: /* Write to mux register. Don't use i2c_transfer()/i2c_smbus_xfer() for this as they will try to lock adapter a second time */ This looks even more hackish solution than calling existing demod .i2c_gate_ctrl() callback from USB-interface driver. But yes, it must work - not beautiful but workable workaround. 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
Re: af9015/tda18218: Multiples (separates) usb devices errors/conflicts
On 09/24/2011 12:06 AM, Jin Kazama wrote: Hello, I've been testing af9015/tda18218 based usb DVB-T tuners on a 2.6.39.4 kernel with the latest v4l drivers avaiable (from git). When I'm using a single USB module, (listed as /dev/dvb/adapter0), everything works fine. When I'm plugging another module, at first it looks like everything's ok (/dev/dvb/adapter1) and if I try to use this module while the adapter0 is not been used, it works - but if try to use both modules at the same time, I get garbage output on both cards (error: warning: discontinuity for PID... with dvblast on both cards. Does anyone have any idea on how to fix this problem? Feel free to fix it. I am too busy currently. 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
Re: Smart card reader support for Anysee DVB devices
On 09/02/2011 04:32 PM, Antti Palosaari wrote:
On 09/02/2011 02:04 PM, Bjørn Mork wrote:
Antti Palosaaricr...@iki.fi writes:
Since Anysee device itself does not have CCID interface it is needed
to make virtual USB device in order to get CCID support. I have never
seen virtual USB devices like that, but there is VHCI in current
kernel staging that actually does something like that over IP.
Don't know if you have seen this already, but there's a virtual CCID
device implementation in QEMU. See
http://wiki.qemu.org/Features/Smartcard
Should be a good starting point. Combine it withe the VHCI driver from
USBIP and you have your CCID device.
It is first time I hear about QEMU virtual CCID. Now we have all parts
needed for USBIP VHCI and QEMU virtual CCID, just glue those together.
I wonder if it is wise to even create virtual CCID core to Kernel.
There is few other readers that can use that too, actually I think all
USB readers that have unique USB ID (blocking out those which uses
USB-serial converters with common IDs).
As I see that CCID still more complex as serial device I will still look
implementing it as serial as now.
Here it is, patch attached. Implemented as serial device. Anysee uses
two different smart card interfaces, CST56I01 and TDA8024. That one is
old CST56I01, I will try to add TDA8024 later, maybe even tonight.
Anyhow, it is something like proof-of-concept currently, missing locks
and abusing ttyUSB. Have you any idea if I should reserve own major
device numbers for Anysee or should I reserve one like DVB common?
Any other ideas?
Antti
--
http://palosaari.fi/
diff --git a/drivers/media/dvb/dvb-usb/anysee.c
b/drivers/media/dvb/dvb-usb/anysee.c
index 0bc1372..79497f3 100644
--- a/drivers/media/dvb/dvb-usb/anysee.c
+++ b/drivers/media/dvb/dvb-usb/anysee.c
@@ -44,7 +44,7 @@
#include cxd2820r.h
/* debug */
-static int dvb_usb_anysee_debug;
+static int dvb_usb_anysee_debug = -1;
module_param_named(debug, dvb_usb_anysee_debug, int, 0644);
MODULE_PARM_DESC(debug, set debugging level DVB_USB_DEBUG_STATUS);
static int dvb_usb_anysee_delsys;
@@ -67,6 +67,11 @@ static int anysee_ctrl_msg(struct dvb_usb_device *d, u8
*sbuf, u8 slen,
if (mutex_lock_interruptible(anysee_usb_mutex) 0)
return -EAGAIN;
+ if (sbuf[0] == CMD_SMARTCARD) {
+ deb_xfer( );
+ debug_dump(buf, slen, deb_xfer);
+ }
+
/* We need receive one message more after dvb_usb_generic_rw due
to weird transaction flow, which is 1 x send + 2 x receive. */
ret = dvb_usb_generic_rw(d, buf, sizeof(buf), buf, sizeof(buf), 0);
@@ -79,8 +84,15 @@ static int anysee_ctrl_msg(struct dvb_usb_device *d, u8
*sbuf, u8 slen,
if (ret)
err(%s: recv bulk message failed: %d, __func__, ret);
else {
- deb_xfer( );
- debug_dump(buf, act_len, deb_xfer);
+// deb_xfer( );
+// debug_dump(buf, act_len, deb_xfer);
+ if (sbuf[0] == CMD_SMARTCARD) {
+ if (buf[63] != 0x4f)
+ deb_info(%s: packet NOK: %02x\n,
__func__, buf[63]);
+
+ deb_xfer( );
+ debug_dump(buf, 40, deb_xfer);
+ }
}
}
@@ -701,6 +713,8 @@ static int anysee_frontend_attach(struct dvb_usb_adapter
*adap)
adap-fe_adap[0].fe = dvb_attach(tda10023_attach,
anysee_tda10023_config, adap-dev-i2c_adap, 0x48);
+ state-has_sc = true;
+
break;
case ANYSEE_HW_507SI: /* 11 */
/* E30 S2 Plus */
@@ -1014,6 +1028,7 @@ static int anysee_tuner_attach(struct dvb_usb_adapter
*adap)
return ret;
}
+#if 0
static int anysee_rc_query(struct dvb_usb_device *d)
{
u8 buf[] = {CMD_GET_IR_CODE};
@@ -1039,6 +1054,7 @@ static int anysee_rc_query(struct dvb_usb_device *d)
return 0;
}
+#endif
static int anysee_ci_read_attribute_mem(struct dvb_ca_en50221 *ci, int slot,
int addr)
@@ -1208,6 +1224,292 @@ static void anysee_ci_release(struct dvb_usb_device *d)
return;
}
+// stty -aF /dev/ttyUSB0
+// setserial /dev/ttyUSB0
+// statserial /dev/ttyUSB0
+// more /proc/tty/drivers
+// watch head /proc/tty/driver/serial
+//
http://www.ibiblio.org/pub/Linux/docs/HOWTO/other-formats/html_single/Serial-HOWTO.html
+
+
+static int anysee_rc_query(struct dvb_usb_device *d)
+{
+ u8 sbuf[] = {CMD_SMARTCARD, 0x06, 0x20};
+ u8 rbuf[60];
+ int ret;
+ u8 *ptr;
+ struct anysee_state *state = d-priv;
+ struct tty_struct *tty = state-sc_tty_driver-ttys[0];
+
+ if (state-sc_poll_count-- = 0)
+ return 0;
+
+ deb_info(%s:\n, __func__);
+
+ ret = anysee_ctrl_msg(d, sbuf, sizeof(sbuf), rbuf, sizeof(rbuf
Re: Smart card reader support for Anysee DVB devices
On 09/28/2011 05:32 PM, Antti Palosaari wrote: On 09/02/2011 04:32 PM, Antti Palosaari wrote: As I see that CCID still more complex as serial device I will still look implementing it as serial as now. Here it is, patch attached. Implemented as serial device. Anysee uses two different smart card interfaces, CST56I01 and TDA8024. That one is old CST56I01, I will try to add TDA8024 later, maybe even tonight. Anyhow, it is something like proof-of-concept currently, missing locks and abusing ttyUSB. Have you any idea if I should reserve own major device numbers for Anysee or should I reserve one like DVB common? Any other ideas? http://git.linuxtv.org/anttip/media_tree.git/shortlog/refs/heads/anysee Now it works for TDA8024 based readers too (addition to CST56I01). Main difference was that TDA8024 designs reads card presence from GPIO whilst for CST56I01 it was got from anysee firmware (I think CST56I01 outputs that using I2C whilst TDA8024 have external IO line). I tested it; * E30 Combo Plus (TDA8024) * E7 T2C (TDA8024) * E30 C (CST56I01) If you would like to help me then you can find out correct device name and whats needed for that. I mainly see following possibilities; * /dev/ttyAnyseeN * /dev/ttyDVBN * /dev/adapterN/serial 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
serial device name for smart card reader that is integrated to Anysee DVB USB device
I have been looking for correct device name for serial smart card reader that is integrated to Anysee DVB USB devices. Consider it like old so called Phoenix reader. Phoenix is de facto protocol used for such readers and there is whole bunch of different RS232 (/dev/ttyS#) or USB-serial (/dev/ttyUSB#) readers using that protocol. Anyhow, that one is integrated to DVB USB device that is driven by dvb_usb_anysee driver. As I understand, I need reserve new device name and major number for my device. See Documentation/devices.txt Current proof-of-concept driver can be found from: http://git.linuxtv.org/anttip/media_tree.git/shortlog/refs/heads/anysee-sc Don't review code since it is not ready for release yet, it even lacks locking. There have been some proposes about names, mainly whether to register it under the DVB adapter it is physically (/dev/dvb/adapterN/sc#) or to the root of /dev (/dev/sc#). I used sc as name, SC=SmartCard. Could someone who have enough knowledge point out which one is correct or better? 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
Re: serial device name for smart card reader that is integrated to Anysee DVB USB device
On 10/05/2011 07:59 AM, Greg KH wrote: On Wed, Oct 05, 2011 at 12:22:09AM +0300, Antti Palosaari wrote: I have been looking for correct device name for serial smart card reader that is integrated to Anysee DVB USB devices. Consider it like old so called Phoenix reader. Phoenix is de facto protocol used for such readers and there is whole bunch of different RS232 (/dev/ttyS#) or USB-serial (/dev/ttyUSB#) readers using that protocol. Anyhow, that one is integrated to DVB USB device that is driven by dvb_usb_anysee driver. As I understand, I need reserve new device name and major number for my device. See Documentation/devices.txt Why not just use the usb-serial core and then you get a ttyUSB* device node for free? It also should provide a lot of the basic tty infrastructure and ring buffer logic all ready to use. Since I don't see how I can access same platform data from DVB USB and USB-serial driver (usb_set_intfdata). I asked that earlier, see: http://www.mail-archive.com/linux-media@vger.kernel.org/msg36027.html 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
Re: serial device name for smart card reader that is integrated to Anysee DVB USB device
On 10/05/2011 09:15 AM, Oliver Neukum wrote: Am Mittwoch, 5. Oktober 2011, 07:58:51 schrieb Antti Palosaari: On 10/05/2011 07:59 AM, Greg KH wrote: Why not just use the usb-serial core and then you get a ttyUSB* device node for free? It also should provide a lot of the basic tty infrastructure and ring buffer logic all ready to use. Since I don't see how I can access same platform data from DVB USB and USB-serial driver (usb_set_intfdata). I asked that earlier, see: http://www.mail-archive.com/linux-media@vger.kernel.org/msg36027.html Yes, and I'll have to give you the same answer as then. But, Greg, Antti makes a very valid point here. The generic code assumes that it owns intfdata, that is you cannot use it as is for access to anything that lacks its own interface. But this is not a fatal flaw. We can alter the generic code to use an accessor function the driver can provide and make it default to get/set_intfdata What do you think? Oliver, I looked your old thread reply but I didn't catch how you meant it to happen. Could you give some small example? 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
Re: Cypress EZ-USB FX2 firmware development
On 10/06/2011 03:47 PM, Johannes Stezenbach wrote: On Tue, Oct 04, 2011 at 11:29:01PM +0200, Johannes Stezenbach wrote: On Tue, Oct 04, 2011 at 10:43:59PM +0300, Antti Palosaari wrote: I would like to made own firmware for Cypress FX2 based DVB device. Is there any sample to look example? http://linuxtv.org/cgi-bin/viewvc.cgi/dvb-hw/dvbusb-fx2/termini/ PS: If you haven't found it already, there is also fx2lib: https://github.com/mulicheng/fx2lib http://sourceforge.net/projects/fx2lib/ Johannes Thank you! I already looked those termini project files and it was kinda jackpot. Much more than I ever imagined. I will try to compile it next weekend and upload to my FX2 device to see if I can get at least control for I2C-bus. 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
Re: [PATCH] af9013 Extended monitoring in set_frontend.
I have been following that discussion and hoping you would finally find out the reason. But I want to point out few things; * .set_frontend() is called only when channel changed * .set_params() is called only when channel changed * there is no I2C traffic for tuner after channel changed * there is I2C traffic to tuner only when channel is changed Since generally changes to .set_frontend() will not have effect in normal use, when both devices are already streaming. Only in case of lock is missed and re-tune initialized or channel changed. 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
Re: Cypress EZ-USB FX2 firmware development
On 10/06/2011 04:10 PM, Antti Palosaari wrote: On 10/06/2011 03:47 PM, Johannes Stezenbach wrote: On Tue, Oct 04, 2011 at 11:29:01PM +0200, Johannes Stezenbach wrote: On Tue, Oct 04, 2011 at 10:43:59PM +0300, Antti Palosaari wrote: I would like to made own firmware for Cypress FX2 based DVB device. Is there any sample to look example? http://linuxtv.org/cgi-bin/viewvc.cgi/dvb-hw/dvbusb-fx2/termini/ PS: If you haven't found it already, there is also fx2lib: https://github.com/mulicheng/fx2lib http://sourceforge.net/projects/fx2lib/ Johannes Thank you! I already looked those termini project files and it was kinda jackpot. Much more than I ever imagined. I will try to compile it next weekend and upload to my FX2 device to see if I can get at least control for I2C-bus. After very long hack sessions during weekend I got it working. I2C was easy stuff, streaming video was more challenging. 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
Re: [PATCH] af9013 Extended monitoring in set_frontend.
On 10/08/2011 11:05 PM, Jason Hecker wrote: Which kernels are you all running? 2.6.38-11-generic #50-Ubuntu SMP (Mythbuntu 11.04) Have you tried other USB-cable or connect it directly to the mobo USB port. I just used one af9015 + 2x mxl5007t and got some streaming corruptions. I was WTF. Switched to af9015 + 2x mxl5005s since it is device I usually have used. Still errors. Then I commented out remote controller polling and all status polling from drivers. Still some stream corruptions. Finally I realized I have other USB-cable than normally. Plugged device directly to the mobo USB and now both tuners are streaming same time without errors. 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
Re: support for tv tuner tda18211 in Iconbit U100 analog stick
CX23102 + TDA18211 (== DVB-T only version of TDA18271) Maybe someone have better knowledge about that as I am not any familiar with CX23102 nor analog TV side. Antti On 10/09/2011 03:56 AM, Ling Sequera wrote: I try to post this at linux-media@vger.kernel.org mailto:linux-media@vger.kernel.org, but the system rejects the sending, Excuse me for send this to you, I have understood that you are one of the developers of the tda18271 module. I have a Mygica u719c usb analog tv stick, lsusb output identify this device as: ID 1f4d:0237 G-Tek Electronics Group. Googling, I found that this device is the same Iconbit Analog Stick U100 FM http://translate.google.es/translate?sl=rutl=enjs=nprev=_thl=esie=UTF-8layout=2eotf=1u=http%3A%2F%2Fwww.f1cd.ru%2Ftuners%2Freviews%2Ficonbit_u100_fm_iconbit_u500_fm_page_1%2F, which has support in the kernel since version 3.0 as shown here http://cateee.net/lkddb/web-lkddb/VIDEO_CX231XX.html. I opened the device to corfirm this information, and effectively, it has to chips, the demod Conexan CX23102 and the DVB-T tuner NPX TDA-18211. I installed the precompiled version of kernel 3.0.4, and the device was reconized, but only works in the modes: composite and s-video. I check the source code and I found that it don't support tv tuner mode (.tuner_type=TUNER_ABSENT in 513 line of the cx231xx-cards.c http://lxr.linux.no/#linux+v3.0.4/drivers/media/video/cx231xx/cx231xx-cards.c source file), I want to add support for this. The TDA-18211 tuner has support in the kernel in the module tda18271 according to the thread of this mailing list http://www.mail-archive.com/linux-dvb@linuxtv.org/msg30055.html. I have never written a module, but I have basic knowledge in C, so I need a book, reference, api, or something, to write the missing code to add support for this device as tv tuner. Also I need help understanding how to read usb-snoop log files and identify the necessary parameters for configure the code. Thanks in advance. Best regards. -- 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
Re: PCTV 520e on Linux
On 10/13/2011 06:57 PM, Devin Heitmueller wrote: and wonder if anyone know the status of support, if any, of the PCTV QuatroStick nano 520e for DVB-C on Linux? http://www.pctvsystems.com/Products/ProductsEuropeAsia/Hybridproducts/PCTVQuatroSticknano/tabid/254/language/en-GB/Default.aspx No support currently. I have the stick, but haven't had any time to work on it. Is that EM28xx + DRX-K + TDA18217 ? And analog parts... 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
Re: PCTV 520e on Linux
On 10/13/2011 07:15 PM, Devin Heitmueller wrote: On Thu, Oct 13, 2011 at 12:07 PM, Antti Palosaaricr...@iki.fi wrote: No support currently. I have the stick, but haven't had any time to work on it. Is that EM28xx + DRX-K + TDA18217 ? And analog parts... You were close: em2884, drx-k, xc5000, and for analog it uses the afv4910b. Then it should be peace of cake at least for digital side. 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
[GIT PULL FOR 3.2] Anysee
Mauro, The following changes since commit 446b792c6bd87de4565ba200b75a708b4c575a06: [media] media: DocBook: Fix trivial typo in Sub-device Interface (2011-09-27 09:14:58 -0300) are available in the git repository at: git://linuxtv.org/anttip/media_tree.git anysee Antti Palosaari (7): tda18212: add DVB-T2 support anysee: add support for Anysee E7 T2C anysee: I2C gate control DNOD44CDH086A tuner module anysee: CI/CAM support anysee: fix fronted pointers due to merge conflict anysee: add control message debugs anysee: fix style issues drivers/media/common/tuners/tda18212.c | 49 +++- drivers/media/common/tuners/tda18212.h |4 + drivers/media/dvb/dvb-usb/Kconfig |1 + drivers/media/dvb/dvb-usb/anysee.c | 418 +++- drivers/media/dvb/dvb-usb/anysee.h |6 + 5 files changed, 404 insertions(+), 74 deletions(-) -- 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
Re: femon patch for dB
On 10/29/2011 02:01 AM, James wrote: I added a switch to femon so it displays signal and snr in dB. The cx23885 driver for my Hauppauge WinTV-HVR1250 reports signal and snr in dB. http://lockie.ca/test/femon.patch.bz2 from patch: human readable output: (signal: 0-65335, snr: 1/256 increments)\n human readable output: (signal and snr in .1 dB increments)\n You should take look to demod drivers and check what those are returning. I have strong feeling that most drivers returns SNR as 10xdB. And SS as 0-0x. I think there is good consensus of SNR unit, but for SS it is not so clear. For my drivers I have used SNR 10xdB and SS 0-0x. That's why, giving only those two alternatives is not suitable. Maybe it is better to set own param for SNR and SS? Devin did some research about SNR long time back: http://www.devinheitmueller.com/snr.txt 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
[GIT PULL FOR 2.6.38] af9013 IF config fix
Moi Mauro, PULL that bug fix to the 2.6.38 t. Antti The following changes since commit 0a97a683049d83deaf636d18316358065417d87b: [media] cpia2: convert .ioctl to .unlocked_ioctl (2011-01-06 11:34:41 -0200) are available in the git repository at: git://linuxtv.org/anttip/media_tree.git af9015 Antti Palosaari (1): af9013: fix AF9013 TDA18271 IF config drivers/media/dvb/frontends/af9013.c |4 ++-- 1 files changed, 2 insertions(+), 2 deletions(-) -- 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
Re: ec168-9295d36ab66e compiling error
Dont use my, or anyone else, old HG trees. You should follow that http://www.linuxtv.org/wiki/index.php/How_to_install_DVB_device_drivers Antti On 02/24/2011 04:24 PM, Vinicio Nocciolini wrote: Hi all I have problem compiling the project regards Vinicio --- CC [M] /home/vinicio/Desktop/ec168-9295d36ab66e/v4l/vc032x.o CC [M] /home/vinicio/Desktop/ec168-9295d36ab66e/v4l/zc3xx.o CC [M] /home/vinicio/Desktop/ec168-9295d36ab66e/v4l/hdpvr-control.o CC [M] /home/vinicio/Desktop/ec168-9295d36ab66e/v4l/hdpvr-core.o CC [M] /home/vinicio/Desktop/ec168-9295d36ab66e/v4l/hdpvr-video.o CC [M] /home/vinicio/Desktop/ec168-9295d36ab66e/v4l/hopper_cards.o CC [M] /home/vinicio/Desktop/ec168-9295d36ab66e/v4l/hopper_vp3028.o CC [M] /home/vinicio/Desktop/ec168-9295d36ab66e/v4l/ir-functions.o CC [M] /home/vinicio/Desktop/ec168-9295d36ab66e/v4l/ir-keytable.o /home/vinicio/Desktop/ec168-9295d36ab66e/v4l/ir-keytable.c: In function '__ir_input_register': /home/vinicio/Desktop/ec168-9295d36ab66e/v4l/ir-keytable.c:452:24: warning: assignment from incompatible pointer type /home/vinicio/Desktop/ec168-9295d36ab66e/v4l/ir-keytable.c:453:24: warning: assignment from incompatible pointer type CC [M] /home/vinicio/Desktop/ec168-9295d36ab66e/v4l/ir-sysfs.o /home/vinicio/Desktop/ec168-9295d36ab66e/v4l/ir-sysfs.c: In function 'ir_register_class': /home/vinicio/Desktop/ec168-9295d36ab66e/v4l/ir-sysfs.c:268:23: error: 'ir_raw_dev_type' undeclared (first use in this function) /home/vinicio/Desktop/ec168-9295d36ab66e/v4l/ir-sysfs.c:268:23: note: each undeclared identifier is reported only once for each function it appears in make[3]: *** [/home/vinicio/Desktop/ec168-9295d36ab66e/v4l/ir-sysfs.o] Error 1 make[2]: *** [_module_/home/vinicio/Desktop/ec168-9295d36ab66e/v4l] Error 2 make[2]: Leaving directory `/usr/src/kernels/2.6.35.11-83.fc14.i686' make[1]: *** [default] Error 2 make[1]: Leaving directory `/home/vinicio/Desktop/ec168-9295d36ab66e/v4l' make: *** [all] Error 2 [vinicio@localhost ec168-9295d36ab66e]$ cat /etc/issue Fedora release 14 (Laughlin) Kernel \r on an \m (\l) -- 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 -- 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
Re: Well supported USB DVB-C device?
On 02/28/2011 02:02 AM, Malte Gell wrote: is there a DVB-C device with USB that is well supported by a recent kernel (2.6.38)? Anysee E30 C Plus is supported as far as I know. Note that new revision of Anysee E30 Combo Plus is no longer supported since they changed to new NXP silicon tuner. E30 Combo Plus and E30 C Plus are different devices. I am not sure which is status of TT CT-3650, it could be other one which is working. 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
Re: ec168-9295d36ab66e compiling error
On 02/28/2011 12:37 PM, Vinicio Nocciolini wrote: [ 304.74] dvb-usb: found a 'E3C EC168 DVB-T USB2.0 reference design' in cold state, will try to load a firmware [ 304.742587] dvb-usb: did not find the firmware file. (dvb-usb-ec168.fw) Please see linux/Documentation/dvb/ for more details on firmware-problems. (-2) That error message should be rather clear. Use Google to find correct firmware. 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
Re: Well supported USB DVB-C device?
On 02/28/2011 11:49 AM, Magnus Alm wrote: 2011/2/28 Antti Palosaaricr...@iki.fi On 02/28/2011 02:02 AM, Malte Gell wrote: is there a DVB-C device with USB that is well supported by a recent kernel (2.6.38)? Anysee E30 C Plus is supported as far as I know. It works fine, besides the card reader. Yes it is working as E30 Combo Plus was too. The aim was try to say that you never know when chipset changes and it stops working. Anyhow, I am not currently aware that, I am that driver author. Card reader is not supported in any of the Anysee models. 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
Re: [patch] Fix AF9015 Dual tuner i2c write failures
Wow, thanks! On 03/04/2011 11:37 PM, Andrew de Quincey wrote: Hi, this has been annoying me for some time, so this evening I fixed it. If you use one of the above dual tuner devices (e.g. KWorld 399U), you get random tuning failures and i2c errors reported in dmesg such as: [...] Adding a bus lock to af9015_i2c_xfer() will not work as demod/tuner accesses will take multiple i2c transactions. Therefore, the following patch overrides the dvb_frontend_ops functions to add a per-device lock around them: only one frontend can now use the i2c bus at a time. Testing with the scripts above shows this has eliminated the errors. This have annoyed me too, but since it does not broken functionality much I haven't put much effort for fixing it. I like that fix since it is in AF9015 driver where it logically belongs to. But it looks still rather complex. I see you have also considered bus lock to af9015_i2c_xfer() which could be much smaller in code size (that's I have tried to implement long time back). I would like to ask if it possible to check I2C gate open / close inside af9015_i2c_xfer() and lock according that? Something like: typical command sequence: FE0 open gate FE0 write reg FE0 close gate FE1 open gate FE1 read reg FE1 close gate if (locked == YES) if (locked_by != caller FE) return error locked by other FE else (locked_by == caller FE) allow reg access if (gate close req) locked = NO locked_by = NONE else (locked == NO) locked = YES locked_by = caller FE allow reg access Do you see it possible? thanks 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
Re: [patch] Fix AF9015 Dual tuner i2c write failures
On 03/05/2011 12:44 AM, Andrew de Quincey wrote: Adding a bus lock to af9015_i2c_xfer() will not work as demod/tuner accesses will take multiple i2c transactions. Therefore, the following patch overrides the dvb_frontend_ops functions to add a per-device lock around them: only one frontend can now use the i2c bus at a time. Testing with the scripts above shows this has eliminated the errors. This have annoyed me too, but since it does not broken functionality much I haven't put much effort for fixing it. I like that fix since it is in AF9015 driver where it logically belongs to. But it looks still rather complex. I see you have also considered bus lock to af9015_i2c_xfer() which could be much smaller in code size (that's I have tried to implement long time back). I would like to ask if it possible to check I2C gate open / close inside af9015_i2c_xfer() and lock according that? Something like: Hmm, I did think about that, but I felt overriding the functions was just cleaner: I felt it was more obvious what it was doing. Doing exactly this sort of tweaking was one of the main reasons we added that function overriding feature. I don't like the idea of returning error locked by FE since that'll mean the tuning will randomly fail sometimes in a way visible to userspace (unless we change the core dvb_frontend code), which was one of the things I was trying to avoid. Unless, of course, I've misunderstood your proposal. Not returning error, but waiting in lock like that: if (mutex_lock_interruptible(d-i2c_mutex) 0) return -EAGAIN; However, looking at the code again, I realise it is possible to simplify it. Since its only the demod gates that cause a problem, we only /actually/ need to lock the get_frontend() and set_frontend() calls. I don't understand why .get_frontend() causes problem, since it does not access tuner at all. It only reads demod registers. The main problem is (like schema in af9015.c shows) that there is two tuners on same I2C bus using same address. And demod gate is only way to open access for desired tuner only. You should block traffic based of tuner not demod. And I think those callbacks which are needed for override are tuner driver callbacks. Consider situation device goes it v4l-core calls same time both tuner .sleep() == problem. 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
Re: [patch] Fix AF9015 Dual tuner i2c write failures
Switching channels for long time seems to hang device (no errors seen but it does not lock anymore), I don't know why. It is not very easy to reproduce. For me it will take generally few days just tune from channel to channel in loop. Antti On 03/05/2011 10:56 AM, Juan Jesús García de Soria Lucena wrote: Hi, Andrew. This is what happens to me with both the KWorld dual tuner (when using only one tuner) and the Avermedia Volar Black (single tuner), both based on AF9015. I also got corrupted streams with the KWorld when capturing via both tuners (the video our the audio would show artifacts in mythtv each several seconds). As far as the loss of tuning ability goes, I think it's a problem related to tuning itself, since it wouldn't happen when you just left a channel tuned and streaming in a simple client, but would trigger after a random time when you left mythtv scanning the channels for EIT data. I don't think it's a problem with a specific HW implementation, since I got it with both AF9015-based cards. It could be either a chipset quirk our a bug in the driver. My informal and quick tests with Windows Media Center and these cards did not reproduce the problem, when trying to change channels as quickly as possible, admittedly for not so long a time. Best regards, Juan Jesus. El 05/03/2011 02:53, adqa...@lidskialf.net escribió: On 5 March 2011 01:43, adqa...@lidskialf.net wrote: On 4 March 2011 23:11, Andrew de Quinceyadq_...@lidskialf.net wrote: On 4 March 2011 22:59, Antti Palosaaricr...@iki.fi wrote: On 03/05/2011 12:44 AM, Andrew de Quincey wrote: Adding a bus lock to af9015_i2c_xfer() will not work as demod/tuner accesses will take multiple i2c transactions. Therefore, the following patch overrides the dvb_frontend_ops functions to add a per-device lock around them: only one frontend can now use the i2c bus at a time. Testing with the scripts above shows this has eliminated the errors. This have annoyed me too, but since it does not broken functionality much I haven't put much effort for fixing it. I like that fix since it is in AF9015 driver where it logically belongs to. But it looks still rather complex. I see you have also considered bus lock to af9015_i2c_xfer() which could be much smaller in code size (that's I have tried to implement long time back). I would like to ask if it possible to check I2C gate open / close inside af9015_i2c_xfer() and lock according that? Something like: Hmm, I did think about that, but I felt overriding the functions was just cleaner: I felt it was more obvious what it was doing. Doing exactly this sort of tweaking was one of the main reasons we added that function overriding feature. I don't like the idea of returning error locked by FE since that'll mean the tuning will randomly fail sometimes in a way visible to userspace (unless we change the core dvb_frontend code), which was one of the things I was trying to avoid. Unless, of course, I've misunderstood your proposal. Not returning error, but waiting in lock like that: if (mutex_lock_interruptible(d-i2c_mutex) 0) return -EAGAIN; Ah k, sorry However, looking at the code again, I realise it is possible to simplify it. Since its only the demod gates that cause a problem, we only /actually/ need to lock the get_frontend() and set_frontend() calls. I don't understand why .get_frontend() causes problem, since it does not access tuner at all. It only reads demod registers. The main problem is (like schema in af9015.c shows) that there is two tuners on same I2C bus using same address. And demod gate is only way to open access for desired tuner only. AFAIR /some/ tuner code accesses the tuner hardware to read the exact tuned frequency back on a get_frontend(); was just being extra paranoid :) You should block traffic based of tuner not demod. And I think those callbacks which are needed for override are tuner driver callbacks. Consider situation device goes it v4l-core calls same time both tuner .sleep() == problem. Hmm, yeah, you're right, let me have another look tomorrow. Hi, must admit I misunderstood your diagram originally, I thought it was the demods AND the tuners that had the same i2c addresses. As you say though. its just the tuners, so adding the locking into the gate ctrl as you suggested makes perfect sense. Attached is v3 implementing this; it seems to be working fine here. Unfortunately even with this fix, I'm still seeing the problem I was trying to fix to begin with. Although I no longer get any i2c errors (or *any* reported errors), after a bit, one of the frontends just.. stops working. All attempts to tune it fail. I can even unload and reload the driver module, and its stuck in the same state, indicating its a problem with the hardware. :( -- 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
Re: [patch] Fix AF9015 Dual tuner i2c write failures
On 03/05/2011 03:51 AM, adq wrote: As you say though. its just the tuners, so adding the locking into the gate ctrl as you suggested makes perfect sense. Attached is v3 implementing this; it seems to be working fine here. Unfortunately even with this fix, I'm still seeing the problem I was trying to fix to begin with. Although I no longer get any i2c errors (or *any* reported errors), after a bit, one of the frontends just.. stops working. All attempts to tune it fail. I can even unload and reload the driver module, and its stuck in the same state, indicating its a problem with the hardware. :( How easily you can re-produce this? Does it work using your first patch? Could try some changes for GPIOs, LEDs are not important but tuner GPIOs? Here is instructions how GPIOs should be done: FE0 START FE0 READ EEPROM FE0 GPIO RESET and ENABLE FE1? // set_gpio(0, 3); // msleep(40) // set_gpio(0, 7); FE0 DOWNLOAD FW FE0 enable POWER LED ??? // wr_reg(0xd734, upper nibble 3) FE1 set power management (0xd731) FE0 tuner OFF // set_gpio(3, 7); FE0 LOCK LED OFF FE1 tuner OFF // set_gpio(0, 7); FE1 LOCK LED OFF *** DEVICE is NOW IN SLEEP *** *** TUNE REQ for FE1 ** FE1 tuner ON // set_gpio(0, b); FE1 LOCK LED ON *** now streaming ** FE1 tuner OFF // set_gpio(0, 7); FE1 LOCK LED OFF *** DEVICE is NOW IN SLEEP *** *** TUNE REQ for FE0 ** FE0 tuner ON // set_gpio(3, b); FE0 LOCK LED ON *** now streaming ** FE0 tuner OFF // set_gpio(3, 7); FE0 LOCK LED OFF *** DEVICE is NOW IN SLEEP *** Also configure some power management for FE1, write register 0xd731 value 0x47. Do that in af9013_init() before OFSM init (since it changes some bits in same register). And this is list of used GPIOs, it is my latest understanding. I have ensured many of those by just testing. AF9015 GPIO0 AF9013 reset AF9015 GPIO1 NC (note: on MC44S803 device tuner reset) AF9015 GPIO2 NC AF9015 GPIO3 TUNER AF9015 GPIO_LOCK1 LOCK LED AF9015 GPIO_LOCK2 POWER LED (not sure, I don't have any device having power LED, but it looks like it could be) AF9013 GPIO0 TUNER AF9013 GPIO1 NC AF9013 GPIO2 LOCK LED AF9013 GPIO3 HW power down? AF9013 GPIO_LOCK1 LOCK LED AF9013 GPIO_LOCK2 NC -- 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
Re: [patch] Fix AF9015 Dual tuner i2c write failures
On 03/05/2011 03:43 AM, adq wrote:
+static int af9015_lock_i2c_gate_ctrl(struct dvb_frontend *fe, int enable)
+{
+ int result;
+ struct dvb_usb_adapter *adap = fe-dvb-priv;
+ struct af9015_state *state = adap-dev-priv;
+
+ if (enable)
+ if (mutex_lock_interruptible(adap-dev-usb_mutex))
+ return -EAGAIN;
+
+ result = state-i2c_gate_ctrl[adap-id](fe, enable);
+
+ if (!enable)
+ mutex_unlock(adap-dev-usb_mutex);
+
+ return result;
+}
I think this will cause problems in case of tuner driver calls more than
one time gate close or gate enable one after the other.
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
Re: [patch] Fix AF9015 Dual tuner i2c write failures
On 03/06/2011 02:24 PM, adq wrote: Another issue I've noticed just now: The UCBLOCKS measure isn't reset: it seems to be an accumulative counter, which isn't correct from the DVB API (if I remember correctly). This explains why tvheadend's quallity measure gradually tends to 0, since it is assuming UCBLOCKS is non-accumulative. 2.2.7 FE READ UNCORRECTED BLOCKS DESCRIPTION This ioctl call returns the number of uncorrected blocks detected by the device driver during its lifetime. For meaningful measurements, the incrementin block count during a specific time interval should be calculated. For this command, read-only access to the device is sufficient. Note that the counter will wrap to zero after its maximum count has been reached. 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
Re: [patch] Fix AF9015 Dual tuner i2c write failures
On 03/08/2011 12:12 AM, adq wrote: Ah well, so its definitely /not/ conflicting i2c writes that cause the tuner problem as it has finally just died. The festats for a crashed tuner are: Sig: 50933 SNR: 50 BER: 0 UBLK: 5370554 Stat: 0x01 [SIG ] (no other error messages) For the other tuner, it is: Sig: 55703 SNR: 120 BER: 0 UBLK: 919 Stat: 0x1f [SIG CARR VIT SYNC LOCK ] Note the /massive/ difference in ubclocks; the tuner that died always had a massively larger UCBLOCKS count even when it was working fine. Antii, I'll try out your GPIO suggestions today or tomorrow, and I'll try and snag an i2c register dump to see if that sheds any light... Any new findings? 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
AMD Cali TV card
Can anyone identify which are used chips for USB DVB-T + analog card AMD Cali TV card sold vary many brands? http://crunchbanglinux.org/forums/topic/5642/usb-tv-tuner-help/ I have one of those, but I don't want break case... 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
Re: [PATCH 09/16] [media] au6610: get rid of on-stack dma buffer
On 03/18/2011 11:27 PM, Florian Mickler wrote: On Fri, 18 Mar 2011 18:34:58 +0200 Antti Palosaaricr...@iki.fi wrote: On 03/15/2011 10:43 AM, Florian Mickler wrote: usb_control_msg initiates (and waits for completion of) a dma transfer using the supplied buffer. That buffer thus has to be seperately allocated on the heap. In lib/dma_debug.c the function check_for_stack even warns about it: WARNING: at lib/dma-debug.c:866 check_for_stack Note: This change is tested to compile only, as I don't have the hardware. Signed-off-by: Florian Micklerflor...@mickler.org This patch did not found from patchwork! Probably skipped due to broken Cc at my contact. Please resend. Anyhow, I tested and reviewed it. Acked-by: Antti Palosaaricr...@iki.fi Reviewed-by: Antti Palosaaricr...@iki.fi Tested-by: Antti Palosaaricr...@iki.fi [1] https://patchwork.kernel.org/project/linux-media/list/ Antti Yes, there was some broken adressing on my side. Sorry. Thanks for review test! I will resend (hopefully this weekend) the series when I reviewed some of the other patches if it is feasible/better to use prealocated memory as suggested by Mauro. How often does au6610_usb_msg get called in normal operation? Should it use preallocated memory? It is called by demodulator and tuner drivers via I2C. One call per one register access. Tuner driver is qt1010 and demod driver is zl10353. When you perform tune to channel and device is in sleep there is maybe 100 or more calls. After channel is tuned as OK, application starts calling only some signalling statistics from demod, it is usually only few calls per sec. On my experience I cannot say if it is wise to preallocate or not. Anyhow, this same apply for all DVB USB drivers. 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
