Re: IR device at I2C address 0x7a
Hi Jean, Thank you for your answer. It is not the error message itself that bothers me but the fact that IR remote control device is not detected and I cannot use it (I checked it on Windows and it's working). After finding this thread I thought it could have had something to do with this error mesage. Is there something that can be done to get my IR remote control working? Thanks for your help in advance. Best regards Darek W dniu 06.01.2010 15:39, Jean Delvare pisze: Hi Darek, Adding LMML to Cc. On Wed, 23 Dec 2009 18:10:08 +0100, Daro wrote: I have the problem you described at the mailing list with Asus MyCinema-P7131/P/FM/AV/RC Analog TV Card: IR remote control is not detected and i2c-adapter i2c-3: Invalid 7-bit address 0x7a error occurs. lspci gives the following output: 04:00.0 Multimedia controller: Philips Semiconductors SAA7131/SAA7133/SAA7135 Video Broadcast Decoder (rev d1) dmesg output I enclose in the attachment. I use: Linux DOMOWY 2.6.31-16-generic #53-Ubuntu SMP Tue Dec 8 04:02:15 UTC 2009 x86_64 GNU/Linux I would be gratefull for the help on that. (...) subsystem: 1043:4845, board: ASUS TV-FM 7135 [card=53,autodetected] (...) i2c-adapter i2c-3: Invalid 7-bit address 0x7a saa7133[0]: P7131 analog only, using entry of ASUSTeK P7131 Analog This error message will show on virtually every SAA713x-based board with no known IR setup. It doesn't imply your board has any I2C device at address 0x7a. So chances are that the message is harmless and you can simply ignore it. -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: IR device at I2C address 0x7a
W dniu 06.01.2010 19:40, Jean Delvare pisze: On Wed, 06 Jan 2010 18:58:58 +0100, Daro wrote: It is not the error message itself that bothers me but the fact that IR remote control device is not detected and I cannot use it (I checked it on Windows and it's working). After finding this thread I thought it could have had something to do with this error mesage. Is there something that can be done to get my IR remote control working? Did it ever work on Linux? I have no experience on that. I bought this card just few weeks ago and tried it only on Karmic Koala. -- 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: IR device at I2C address 0x7a
W dniu 06.01.2010 21:21, Jean Delvare pisze: On Wed, 06 Jan 2010 20:10:30 +0100, Daro wrote: W dniu 06.01.2010 19:40, Jean Delvare pisze: On Wed, 06 Jan 2010 18:58:58 +0100, Daro wrote: It is not the error message itself that bothers me but the fact that IR remote control device is not detected and I cannot use it (I checked it on Windows and it's working). After finding this thread I thought it could have had something to do with this error mesage. Is there something that can be done to get my IR remote control working? Did it ever work on Linux? I have no experience on that. I bought this card just few weeks ago and tried it only on Karmic Koala. OK. You could try loading the saa7134 driver with option card=146 and see if it helps. It works! [ 15.477875] input: saa7134 IR (ASUSTeK P7131 Analo as /devices/pci:00/:00:1e.0/:05:00.0/input/input8 Thank you very much fo your help. I have another question regarding this driver: [ 21.340316] saa7133[0]: dsp access error [ 21.340320] saa7133[0]: dsp access error Do those messages imply something wrong? Can they have something do do with the fact I cannot get the sound out of tvtime application directly and have to use arecord | aplay workaround which causes undesirable delay? -- 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] saa7134: Fix IR support of some ASUS TV-FM 7135 variants
W dniu 03.02.2010 00:32, hermann pitton pisze: Hi Jean, Mauro and all, Am Dienstag, den 02.02.2010, 08:54 +0100 schrieb Jean Delvare: Hi Hermann, On Tue, 02 Feb 2010 02:47:53 +0100, hermann pitton wrote: Hi Jean, Am Montag, den 01.02.2010, 10:56 +0100 schrieb Jean Delvare: Hi Hermann, On Mon, 01 Feb 2010 02:16:35 +0100, hermann pitton wrote: For now, I only faked a P7131 Dual with a broken IR receiver on a 2.6.29 with recent, you can see that gpio 0x4 doesn't go high, but your patch should enable the remote on that P7131 analog only. I'm not sure why you had to fake anything? What I'd like to know is simply if my first patch had any negative effect on other cards. because I simply don't have that Asus My Cinema analog only in question. To recap, you previously announced a patch, tested by Daro, claiming to get the remote up under auto detection for that device and I told you having some doubts on it. My first patch was not actually tested by Daro. What he tested was loading the driver with card=146. At first I thought it was equivalent, but since then I have realized it wasn't. That's the reason why the Tested-by: was turned into a mere Cc: on my second and third patches. Mauro prefers to have a fix for that single card in need for now. Since nobody else cares, For now, see above, I can confirm that your last patch for that single device should work to get IR up with auto detection in delay after we change the card such late with eeprom detection. The meaning of that byte in use here is unknown to me, we should avoid such as much we can! It can turn out to be only some pseudo service. If your call for testers on your previous attempt, really reaches some for some reason, I'm with you, but for now I have to keep the car operable within all such snow. That I understand. What I don't understand is: if you have a SAA7134-based card, why don't you test my second patch (the one moving the call to saa7134_input_init1 to saa7134_hwinit2) on it, without faking anything? This would be a first, useful data point. sorry, the snow fall did not stop and we will need trucks next day to get it out of town. No place left. I did not reread any single line of code until now, but told you that Roman has tested a equivalent patch on his P7131_ANALOG already and I can confirm that it also had no side effects on a FlyVideo3000 card=2. For now, I would at least need some time to see, if input_init can be decoupled from all other hardware init, what you seem to suggest, and looking closer to Mauro's concerns. Thought you are asking for some test with a i2c remote next to confirm your analysis there. No such card in any machine currently, but can be done. Cheers, Hermann Hi All, If some tests on my machine could be helpfull just let me know. Best regards Darek -- 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] saa7134: Fix IR support of some ASUS TV-FM 7135 variants
Hi Jean, I am back and ready to go :) As I am not much experienced Linux user I would apprieciate some more details: I have few linux kernels installed; which one should I test or it does not matter? 2.6.31-14-generic 2.6.31-16-generic 2.6.31-17-generic 2.6.31-19-generic 2.6.31-20-generic and one I compiled myself 2.6.32.2 I assume that to proceed with a test I should patch the certain version of kernel and compile it or could it be done other way? Best regards Daro W dniu 12.03.2010 10:38, Jean Delvare pisze: Hi Daro, On Fri, 26 Feb 2010 17:19:38 +0100, Daro wrote: I did not forget I had offered to test the patch however I am now on vacation skiing so I will get back to you as soon I am back home. Are you back home by now? We are still waiting for your test results. We can't push the patch upstream without it, and if it takes too long, I'll probably just discard the patch and move to other tasks. -- 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] saa7134: Fix IR support of some ASUS TV-FM 7135 variants
W dniu 14.03.2010 09:26, Jean Delvare pisze: Hi Daro, On Sun, 14 Mar 2010 03:38:11 +0100, Daro wrote: Hi Jean, I am back and ready to go :) As I am not much experienced Linux user I would apprieciate some more details: I have few linux kernels installed; which one should I test or it does not matter? 2.6.31-14-generic 2.6.31-16-generic 2.6.31-17-generic 2.6.31-19-generic 2.6.31-20-generic and one I compiled myself 2.6.32.2 I assume that to proceed with a test I should patch the certain version of kernel and compile it or could it be done other way? It will be easier with the kernel you compiled yourself. First of all, download the patch from: http://patchwork.kernel.org/patch/75883/raw/ Then, move to the source directory of your 2.6.32.2 kernel and apply the patch: $ cd ~/src/linux-2.6.32 $ patch -p2 ~/download/saa7134-Fix-IR-support-of-some-ASUS-TV-FM-7135-variants.patch Adjust the path in each command to match your own setup. Then just build and install the kernel: $ make $ sudo make modules_install $ sudo make install Or whatever method you use to install your self-compiled kernels. Then reboot to kernel 2.6.32.2 and test that the remote control works even when _not_ passing any card parameter to the driver. If you ever need to remove the patch, use: $ cd ~/src/linux-2.6.32 $ patch -p2 -R ~/download/saa7134-Fix-IR-support-of-some-ASUS-TV-FM-7135-variants.patch I hope my instructions are clear enough, if you have any problem, just ask. Thanks, Hi Jean! It works! dmesg output is attached. However I will have to go back to generic kernel as under my self-built kernels fglrx driver stops working and I did not manage to solve it :( Or maybe you could give me a hint what to do with it? Best regards Daro [0.00] Initializing cgroup subsys cpuset [0.00] Initializing cgroup subsys cpu [0.00] Linux version 2.6.32.2 (r...@domowy) (gcc version 4.4.1 (Ubuntu 4.4.1-4ubuntu9) ) #2 SMP Sun Mar 14 14:11:25 CET 2010 [0.00] Command line: root=/dev/mapper/isw_bgccbabfgf_SYSTEM2 ro [0.00] KERNEL supported cpus: [0.00] Intel GenuineIntel [0.00] AMD AuthenticAMD [0.00] Centaur CentaurHauls [0.00] BIOS-provided physical RAM map: [0.00] BIOS-e820: - 00096c00 (usable) [0.00] BIOS-e820: 00096c00 - 000a (reserved) [0.00] BIOS-e820: 000e4000 - 0010 (reserved) [0.00] BIOS-e820: 0010 - 7ff8 (usable) [0.00] BIOS-e820: 7ff8 - 7ff8e000 (ACPI data) [0.00] BIOS-e820: 7ff8e000 - 7ffd (ACPI NVS) [0.00] BIOS-e820: 7ffd - 8000 (reserved) [0.00] BIOS-e820: fee0 - fee01000 (reserved) [0.00] BIOS-e820: fff0 - 0001 (reserved) [0.00] DMI present. [0.00] AMI BIOS detected: BIOS may corrupt low RAM, working around it. [0.00] e820 update range: - 0001 (usable) == (reserved) [0.00] last_pfn = 0x7ff80 max_arch_pfn = 0x4 [0.00] MTRR default type: uncachable [0.00] MTRR fixed ranges enabled: [0.00] 0-9 write-back [0.00] A-B uncachable [0.00] C-D write-protect [0.00] E-E write-through [0.00] F-F write-protect [0.00] MTRR variable ranges enabled: [0.00] 0 base 0 mask F8000 write-back [0.00] 1 disabled [0.00] 2 disabled [0.00] 3 disabled [0.00] 4 disabled [0.00] 5 disabled [0.00] 6 disabled [0.00] 7 disabled [0.00] x86 PAT enabled: cpu 0, old 0x7040600070406, new 0x7010600070106 [0.00] Scanning 0 areas for low memory corruption [0.00] modified physical RAM map: [0.00] modified: - 0001 (reserved) [0.00] modified: 0001 - 00096c00 (usable) [0.00] modified: 00096c00 - 000a (reserved) [0.00] modified: 000e4000 - 0010 (reserved) [0.00] modified: 0010 - 7ff8 (usable) [0.00] modified: 7ff8 - 7ff8e000 (ACPI data) [0.00] modified: 7ff8e000 - 7ffd (ACPI NVS) [0.00] modified: 7ffd - 8000 (reserved) [0.00] modified: fee0 - fee01000 (reserved) [0.00] modified: fff0 - 0001 (reserved) [0.00] initial memory mapped : 0 - 2000 [0.00] init_memory_mapping: -7ff8 [0.00] 00 - 007fe0 page 2M [0.00] 007fe0 - 007ff8 page 4k [0.00] kernel direct mapping tables up to 7ff8 @ 1-14000
