Re: de-Primacom initial tuning data doesn't work anymore
I completly missed that mail somehow, appologies, a CC to me is always helpfull ;) Next time it would be preferred if you send a patch instead of a link. It would have been even better if Sven submittted said patch so we could have committed it to git much earlier! Anyhow, pushed to git(hub) as edc0bc3f04b715f2c882343e4d4fdf94e7cc1e29 Oliver On 27-07-13 12:37, Franz Schrober wrote: bump - Ursprüngliche Message - Von: Franz Schrober franzschro...@yahoo.de An: linux-media@vger.kernel.org linux-media@vger.kernel.org; kaffeine-u...@lists.sourceforge.net kaffeine-u...@lists.sourceforge.net; pkg-kde-ext...@lists.alioth.debian.org pkg-kde-ext...@lists.alioth.debian.org CC: Gesendet: 16:07 Samstag, 22.Juni 2013 Betreff: de-Primacom initial tuning data doesn't work anymore Hi, I wanted to watch TV today with kaffeine 1.2.2-2 from debian and noticed that it didn't work anymore. Also scans even after the update of the initial tuning data didn't show all tv stations. Just replacing the entry for dvb-c/de-Primacom in ~/.kde/share/apps/kaffeine/scanfile.dvb with the one from http://narfation.org/misc/dvbc/de-Primacom fixed the problem for me after the next scan for tv stations. -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Very verbose message about em28174 chip.
Hi, I plugged my PCTV 290e device into my newly compiled 3.10.3 kernel today, and found this message in the dmesg log. [ 511.041412] usb 10-4: new high-speed USB device number 3 using ehci-pci [ 511.216218] em28xx: New device PCTV Systems PCTV 290e @ 480 Mbps (2013:024f, interface 0, class 0) [ 511.223916] em28xx: DVB interface 0 found: isoc [ 511.227398] em28xx: chip ID is em28174 [ 511.548310] em28174 #0: i2c eeprom : 26 00 01 00 02 09 d8 85 80 80 e5 80 f4 f5 94 90 [ 511.54] em28174 #0: i2c eeprom 0010: 78 0d e4 f0 f5 46 12 00 5a c2 eb c2 e8 30 e9 03 [ 511.562682] em28174 #0: i2c eeprom 0020: 12 09 de 30 eb 03 12 09 10 30 ec f1 12 07 72 80 [ 511.569827] em28174 #0: i2c eeprom 0030: ec 00 60 00 e5 f5 64 01 60 09 e5 f5 64 09 60 03 [ 511.576937] em28174 #0: i2c eeprom 0040: c2 c6 22 e5 f7 b4 03 13 e5 f6 b4 87 03 02 09 92 [ 511.584138] em28174 #0: i2c eeprom 0050: e5 f6 b4 93 03 02 07 e6 c2 c6 22 c2 c6 22 12 09 [ 511.591273] em28174 #0: i2c eeprom 0060: cf 02 06 19 1a eb 67 95 13 20 4f 02 c0 13 6b 10 [ 511.598453] em28174 #0: i2c eeprom 0070: a0 1a ba 14 ce 1a 39 57 00 5c 18 00 00 00 00 00 [ 511.605572] em28174 #0: i2c eeprom 0080: 00 00 00 00 44 36 00 00 f0 10 02 00 00 00 00 00 [ 511.612694] em28174 #0: i2c eeprom 0090: 5b 23 c0 00 00 00 20 40 20 80 02 20 01 01 00 00 [ 511.619821] em28174 #0: i2c eeprom 00a0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 [ 511.627001] em28174 #0: i2c eeprom 00b0: c6 40 00 00 00 00 a7 00 00 00 00 00 00 00 00 00 [ 511.634120] em28174 #0: i2c eeprom 00c0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 38 32 [ 511.641199] em28174 #0: i2c eeprom 00d0: 34 31 30 31 31 36 36 30 31 37 31 31 32 36 58 59 [ 511.648319] em28174 #0: i2c eeprom 00e0: 56 49 00 4f 53 49 30 30 33 30 38 44 30 31 30 36 [ 511.655473] em28174 #0: i2c eeprom 00f0: 58 59 56 49 00 00 00 00 00 00 00 00 00 00 30 36 [ 511.662628] em28174 #0: i2c eeprom 0100: ... (skipped) [ 511.666500] em28174 #0: EEPROM ID = 26 00 01 00, EEPROM hash = 0x1eb936d2 [ 511.672023] em28174 #0: EEPROM info: [ 511.674338] em28174 #0: microcode start address = 0x0004, boot configuration = 0x01 [ 511.705368] em28174 #0: No audio on board. [ 511.708286] em28174 #0: 500mA max power [ 511.710988] em28174 #0: Table at offset 0x00, strings=0x, 0x, 0x [ 511.717120] em28174 #0: Identified as PCTV nanoStick T2 290e (card=78) [ 511.722436] em28174 #0: v4l2 driver version 0.2.0 [ 511.731410] em28174 #0: V4L2 video device registered as video1 [ 511.736043] em28174 #0: dvb set to isoc mode. [ 511.739638] usbcore: registered new interface driver em28xx [ 511.821414] tda18271 7-0060: creating new instance [ 511.829520] TDA18271HD/C2 detected @ 7-0060 [ 512.000542] DVB: registering new adapter (em28174 #0) [ 512.004325] usb 10-4: DVB: registering adapter 0 frontend 0 (Sony CXD2820R)... [ 512.011191] em28174 #0: Successfully loaded em28xx-dvb [ 512.015077] Em28xx: Initialized (Em28xx dvb Extension) extension [ 512.056753] Registered IR keymap rc-pinnacle-pctv-hd [ 512.060784] input: em28xx IR (em28174 #0) as /devices/pci:00/:00:1d.7/usb10/10-4/rc/rc0/input16 [ 512.069167] rc0: em28xx IR (em28174 #0) as /devices/pci:00/:00:1d.7/usb10/10-4/rc/rc0 [ 512.076882] Em28xx: Initialized (Em28xx Input Extension) extension [ 552.064828] tda18271: performing RF tracking filter calibration [ 554.417676] tda18271: RF tracking filter calibration complete Presumably something this verbose is intended to be shared, so here it is. (I can't think of any other reason why this amount of information would be logged by default). Cheers, Chris -- 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: Very verbose message about em28174 chip.
On Sun, Jul 28, 2013 at 9:19 AM, Chris Rankin ranki...@yahoo.com wrote: Hi, I plugged my PCTV 290e device into my newly compiled 3.10.3 kernel today, and found this message in the dmesg log. [ 511.041412] usb 10-4: new high-speed USB device number 3 using ehci-pci [ 511.216218] em28xx: New device PCTV Systems PCTV 290e @ 480 Mbps (2013:024f, interface 0, class 0) [ 511.223916] em28xx: DVB interface 0 found: isoc [ 511.227398] em28xx: chip ID is em28174 [ 511.548310] em28174 #0: i2c eeprom : 26 00 01 00 02 09 d8 85 80 80 e5 80 f4 f5 94 90 [ 511.54] em28174 #0: i2c eeprom 0010: 78 0d e4 f0 f5 46 12 00 5a c2 eb c2 e8 30 e9 03 [ 511.562682] em28174 #0: i2c eeprom 0020: 12 09 de 30 eb 03 12 09 10 30 ec f1 12 07 72 80 [ 511.569827] em28174 #0: i2c eeprom 0030: ec 00 60 00 e5 f5 64 01 60 09 e5 f5 64 09 60 03 [ 511.576937] em28174 #0: i2c eeprom 0040: c2 c6 22 e5 f7 b4 03 13 e5 f6 b4 87 03 02 09 92 [ 511.584138] em28174 #0: i2c eeprom 0050: e5 f6 b4 93 03 02 07 e6 c2 c6 22 c2 c6 22 12 09 [ 511.591273] em28174 #0: i2c eeprom 0060: cf 02 06 19 1a eb 67 95 13 20 4f 02 c0 13 6b 10 [ 511.598453] em28174 #0: i2c eeprom 0070: a0 1a ba 14 ce 1a 39 57 00 5c 18 00 00 00 00 00 [ 511.605572] em28174 #0: i2c eeprom 0080: 00 00 00 00 44 36 00 00 f0 10 02 00 00 00 00 00 [ 511.612694] em28174 #0: i2c eeprom 0090: 5b 23 c0 00 00 00 20 40 20 80 02 20 01 01 00 00 [ 511.619821] em28174 #0: i2c eeprom 00a0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 [ 511.627001] em28174 #0: i2c eeprom 00b0: c6 40 00 00 00 00 a7 00 00 00 00 00 00 00 00 00 [ 511.634120] em28174 #0: i2c eeprom 00c0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 38 32 [ 511.641199] em28174 #0: i2c eeprom 00d0: 34 31 30 31 31 36 36 30 31 37 31 31 32 36 58 59 [ 511.648319] em28174 #0: i2c eeprom 00e0: 56 49 00 4f 53 49 30 30 33 30 38 44 30 31 30 36 [ 511.655473] em28174 #0: i2c eeprom 00f0: 58 59 56 49 00 00 00 00 00 00 00 00 00 00 30 36 [ 511.662628] em28174 #0: i2c eeprom 0100: ... (skipped) [ 511.666500] em28174 #0: EEPROM ID = 26 00 01 00, EEPROM hash = 0x1eb936d2 [ 511.672023] em28174 #0: EEPROM info: [ 511.674338] em28174 #0: microcode start address = 0x0004, boot configuration = 0x01 [ 511.705368] em28174 #0: No audio on board. [ 511.708286] em28174 #0: 500mA max power [ 511.710988] em28174 #0: Table at offset 0x00, strings=0x, 0x, 0x [ 511.717120] em28174 #0: Identified as PCTV nanoStick T2 290e (card=78) [ 511.722436] em28174 #0: v4l2 driver version 0.2.0 [ 511.731410] em28174 #0: V4L2 video device registered as video1 [ 511.736043] em28174 #0: dvb set to isoc mode. [ 511.739638] usbcore: registered new interface driver em28xx [ 511.821414] tda18271 7-0060: creating new instance [ 511.829520] TDA18271HD/C2 detected @ 7-0060 [ 512.000542] DVB: registering new adapter (em28174 #0) [ 512.004325] usb 10-4: DVB: registering adapter 0 frontend 0 (Sony CXD2820R)... [ 512.011191] em28174 #0: Successfully loaded em28xx-dvb [ 512.015077] Em28xx: Initialized (Em28xx dvb Extension) extension [ 512.056753] Registered IR keymap rc-pinnacle-pctv-hd [ 512.060784] input: em28xx IR (em28174 #0) as /devices/pci:00/:00:1d.7/usb10/10-4/rc/rc0/input16 [ 512.069167] rc0: em28xx IR (em28174 #0) as /devices/pci:00/:00:1d.7/usb10/10-4/rc/rc0 [ 512.076882] Em28xx: Initialized (Em28xx Input Extension) extension [ 552.064828] tda18271: performing RF tracking filter calibration [ 554.417676] tda18271: RF tracking filter calibration complete Nothing out of the ordinary in this output. Presumably something this verbose is intended to be shared, so here it is. (I can't think of any other reason why this amount of information would be logged by default). The complexity of these devices (variations on demodulators, tuner chips used, etc) have resulted in putting out more debug by default on initialization compared to other drivers (typically to aid in debugging when users report issues). The amount of output is not inconsistent with most other linuxtv drivers though. Regards, Devin -- Devin J. Heitmueller - Kernel Labs http://www.kernellabs.com -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Very verbose message about em28174 chip.
Hi, It's normal for em28xx to give you that sort of information on device-plug - it does seem like a lot, but it's effectively one-off and you probably won't see much else during use of the device, under default module parameters. It's very useful log output if you have a new device or a slight variant of an existing one, as it takes very little effort to copy paste the details here to help figure out how easy it is to support the device. But as you know, that device works already, so you can just ignore it :) Regards, Steve. On 28/07/13 14:19, Chris Rankin wrote: Hi, I plugged my PCTV 290e device into my newly compiled 3.10.3 kernel today, and found this message in the dmesg log. [ 511.041412] usb 10-4: new high-speed USB device number 3 using ehci-pci [ 511.216218] em28xx: New device PCTV Systems PCTV 290e @ 480 Mbps (2013:024f, interface 0, class 0) [ 511.223916] em28xx: DVB interface 0 found: isoc [ 511.227398] em28xx: chip ID is em28174 [ 511.548310] em28174 #0: i2c eeprom : 26 00 01 00 02 09 d8 85 80 80 e5 80 f4 f5 94 90 [ 511.54] em28174 #0: i2c eeprom 0010: 78 0d e4 f0 f5 46 12 00 5a c2 eb c2 e8 30 e9 03 [ 511.562682] em28174 #0: i2c eeprom 0020: 12 09 de 30 eb 03 12 09 10 30 ec f1 12 07 72 80 [ 511.569827] em28174 #0: i2c eeprom 0030: ec 00 60 00 e5 f5 64 01 60 09 e5 f5 64 09 60 03 [ 511.576937] em28174 #0: i2c eeprom 0040: c2 c6 22 e5 f7 b4 03 13 e5 f6 b4 87 03 02 09 92 [ 511.584138] em28174 #0: i2c eeprom 0050: e5 f6 b4 93 03 02 07 e6 c2 c6 22 c2 c6 22 12 09 [ 511.591273] em28174 #0: i2c eeprom 0060: cf 02 06 19 1a eb 67 95 13 20 4f 02 c0 13 6b 10 [ 511.598453] em28174 #0: i2c eeprom 0070: a0 1a ba 14 ce 1a 39 57 00 5c 18 00 00 00 00 00 [ 511.605572] em28174 #0: i2c eeprom 0080: 00 00 00 00 44 36 00 00 f0 10 02 00 00 00 00 00 [ 511.612694] em28174 #0: i2c eeprom 0090: 5b 23 c0 00 00 00 20 40 20 80 02 20 01 01 00 00 [ 511.619821] em28174 #0: i2c eeprom 00a0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 [ 511.627001] em28174 #0: i2c eeprom 00b0: c6 40 00 00 00 00 a7 00 00 00 00 00 00 00 00 00 [ 511.634120] em28174 #0: i2c eeprom 00c0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 38 32 [ 511.641199] em28174 #0: i2c eeprom 00d0: 34 31 30 31 31 36 36 30 31 37 31 31 32 36 58 59 [ 511.648319] em28174 #0: i2c eeprom 00e0: 56 49 00 4f 53 49 30 30 33 30 38 44 30 31 30 36 [ 511.655473] em28174 #0: i2c eeprom 00f0: 58 59 56 49 00 00 00 00 00 00 00 00 00 00 30 36 [ 511.662628] em28174 #0: i2c eeprom 0100: ... (skipped) [ 511.666500] em28174 #0: EEPROM ID = 26 00 01 00, EEPROM hash = 0x1eb936d2 [ 511.672023] em28174 #0: EEPROM info: [ 511.674338] em28174 #0: microcode start address = 0x0004, boot configuration = 0x01 [ 511.705368] em28174 #0: No audio on board. [ 511.708286] em28174 #0: 500mA max power [ 511.710988] em28174 #0: Table at offset 0x00, strings=0x, 0x, 0x [ 511.717120] em28174 #0: Identified as PCTV nanoStick T2 290e (card=78) [ 511.722436] em28174 #0: v4l2 driver version 0.2.0 [ 511.731410] em28174 #0: V4L2 video device registered as video1 [ 511.736043] em28174 #0: dvb set to isoc mode. [ 511.739638] usbcore: registered new interface driver em28xx [ 511.821414] tda18271 7-0060: creating new instance [ 511.829520] TDA18271HD/C2 detected @ 7-0060 [ 512.000542] DVB: registering new adapter (em28174 #0) [ 512.004325] usb 10-4: DVB: registering adapter 0 frontend 0 (Sony CXD2820R)... [ 512.011191] em28174 #0: Successfully loaded em28xx-dvb [ 512.015077] Em28xx: Initialized (Em28xx dvb Extension) extension [ 512.056753] Registered IR keymap rc-pinnacle-pctv-hd [ 512.060784] input: em28xx IR (em28174 #0) as /devices/pci:00/:00:1d.7/usb10/10-4/rc/rc0/input16 [ 512.069167] rc0: em28xx IR (em28174 #0) as /devices/pci:00/:00:1d.7/usb10/10-4/rc/rc0 [ 512.076882] Em28xx: Initialized (Em28xx Input Extension) extension [ 552.064828] tda18271: performing RF tracking filter calibration [ 554.417676] tda18271: RF tracking filter calibration complete Presumably something this verbose is intended to be shared, so here it is. (I can't think of any other reason why this amount of information would be logged by default). Cheers, Chris -- 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 -- Steve Kerrison MEng Hons. http://www.stevekerrison.com/ -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Very verbose message about em28174 chip.
- Original Message - From: Devin Heitmueller dheitmuel...@kernellabs.com The amount of output is not inconsistent with most other linuxtv drivers though. It's the EEPROM dump that really caught my eye: 16+ lines of pure WTF?. Cheers, Chris -- 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: Very verbose message about em28174 chip.
On Sun, Jul 28, 2013 at 9:58 AM, Chris Rankin ranki...@yahoo.com wrote: - Original Message - From: Devin Heitmueller dheitmuel...@kernellabs.com The amount of output is not inconsistent with most other linuxtv drivers though. It's the EEPROM dump that really caught my eye: 16+ lines of pure WTF?. Yeah, nowadays the eeprom output is one of the less useful pieces of output (in fact, I intentionally didn't do support for dumping it out on the em2874, but somebody did it anyway). That said, I certainly wouldn't nack any patch submitted which changed the debug level for the eeprom output so it's not visible by default. Devin -- Devin J. Heitmueller - Kernel Labs http://www.kernellabs.com -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Very verbose message about em28174 chip.
Am 28.07.2013 16:05, schrieb Devin Heitmueller: On Sun, Jul 28, 2013 at 9:58 AM, Chris Rankin ranki...@yahoo.com wrote: - Original Message - From: Devin Heitmueller dheitmuel...@kernellabs.com The amount of output is not inconsistent with most other linuxtv drivers though. It's the EEPROM dump that really caught my eye: 16+ lines of pure WTF?. Yeah, nowadays the eeprom output is one of the less useful pieces of output (in fact, I intentionally didn't do support for dumping it out on the em2874, but somebody did it anyway). We've always been dumping the eeprom content (which doesn't mean that we have to do it forever ;) ). IIRC, the reason why we didn't dump the eeprom of the newer em2874+ devices up to now, that they are using 16bit eeproms and Devin thought it was too dangerous to read them. ;) It should also be mentioned, that we haven't decoded the meaning of this eeprom type yet completely. I don't care too much. Regards, Frank -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
cron job: media_tree daily build: ERRORS
This message is generated daily by a cron job that builds media_tree for the kernels and architectures in the list below. Results of the daily build of media_tree: date: Sun Jul 28 19:00:16 CEST 2013 git branch: test git hash: 51dd4d70fc59564454a4dcb90d6d46d39a4a97ef gcc version:i686-linux-gcc (GCC) 4.8.1 sparse version: v0.4.5-rc1 host hardware: x86_64 host os:3.9-7.slh.1-amd64 linux-git-arm-at91: OK linux-git-arm-davinci: OK linux-git-arm-exynos: OK linux-git-arm-mx: OK linux-git-arm-omap: OK linux-git-arm-omap1: OK linux-git-arm-pxa: OK linux-git-blackfin: OK linux-git-i686: OK linux-git-m32r: OK linux-git-mips: OK linux-git-powerpc64: OK linux-git-sh: OK linux-git-x86_64: OK linux-2.6.31.14-i686: ERRORS linux-2.6.32.27-i686: ERRORS linux-2.6.33.7-i686: ERRORS linux-2.6.34.7-i686: ERRORS linux-2.6.35.9-i686: ERRORS linux-2.6.36.4-i686: ERRORS linux-2.6.37.6-i686: ERRORS linux-2.6.38.8-i686: ERRORS linux-2.6.39.4-i686: ERRORS linux-3.0.60-i686: ERRORS linux-3.10-i686: OK linux-3.1.10-i686: ERRORS linux-3.2.37-i686: ERRORS linux-3.3.8-i686: ERRORS linux-3.4.27-i686: WARNINGS linux-3.5.7-i686: WARNINGS linux-3.6.11-i686: WARNINGS linux-3.7.4-i686: WARNINGS linux-3.8-i686: WARNINGS linux-3.9.2-i686: WARNINGS linux-2.6.31.14-x86_64: ERRORS linux-2.6.32.27-x86_64: ERRORS linux-2.6.33.7-x86_64: ERRORS linux-2.6.34.7-x86_64: ERRORS linux-2.6.35.9-x86_64: ERRORS linux-2.6.36.4-x86_64: ERRORS linux-2.6.37.6-x86_64: ERRORS linux-2.6.38.8-x86_64: ERRORS linux-2.6.39.4-x86_64: ERRORS linux-3.0.60-x86_64: ERRORS linux-3.10-x86_64: OK linux-3.1.10-x86_64: ERRORS linux-3.2.37-x86_64: ERRORS linux-3.3.8-x86_64: ERRORS linux-3.4.27-x86_64: WARNINGS linux-3.5.7-x86_64: WARNINGS linux-3.6.11-x86_64: WARNINGS linux-3.7.4-x86_64: WARNINGS linux-3.8-x86_64: WARNINGS linux-3.9.2-x86_64: WARNINGS apps: WARNINGS spec-git: OK sparse version: v0.4.5-rc1 sparse: ERRORS Detailed results are available here: http://www.xs4all.nl/~hverkuil/logs/Sunday.log Full logs are available here: http://www.xs4all.nl/~hverkuil/logs/Sunday.tar.bz2 The Media Infrastructure API from this daily build is here: http://www.xs4all.nl/~hverkuil/spec/media.html -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: PROBLEM: dvb-usb-rtl28xxu and Terratec Cinergy TStickRC (rev3) - no signal on some frequencies
Hello Antti, Unfortunately the patch doesn't work for me either. Would it help you if I send you an usb sniff with wireshark of an program search run with kaffeine (27 MB)? regards Torsten Am 24.07.2013 16:06, schrieb Antti Palosaari: Could you test attached patch? It enhances reception a little bit, you should be able to receive more weak signals. I was able to made test setup against modulator. Modulator + attenuator + attenuator + TV-stick, where I got picture using Windows driver at signal level -29dBm whilst on Linux -26.5dBm was needed. With that patch Linux driver started performing same as Windows. regards Antti On 07/23/2013 12:09 AM, Antti Palosaari wrote: On 07/19/2013 08:18 PM, Jan Taegert wrote: Hello, when the culprit is the e4000 driver but the old driver from https://github.com/valtri/DVB-Realtek-RTL2832U-2.2.2-10tuner-mod_kernel-3.0.0 worked for me, then must be somewhere there in the driver sources a solution for the signal issues. Does it make sense to look for a particular string in the sources? I don't have any clue of coding but perhaps I can be helpful in this way. Feel free to look. Those are different drivers and you cannot compare easily. For my experience you will need huge amount of time and much luck with that approach. As I said, the easiest solution is just to took sniffs and copypaste generated code until it starts working. regards Antti There are - tuner_e4000.c - nim_rtl2832_e4000.c Thanks, Jan. Am 19.07.2013 14:00, schrieb Antti Palosaari: Hello It is e4000 driver problem. Someone should take the look what there is wrong. Someone sent non-working stick for me, but I wasn't able to reproduce issue. I used modulator to generate signal with just same parameters he said non-working, but it worked for me. It looks like e4000 driver does not perform as well as it should. Maybe I should take Windows XP and Linux, use modulator to find out signal condition where Windows works but Linux not, took sniffs and compare registers... But I am busy and help is more than welcome. regards Antti -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 1/2] tea575x: Move header from sound to media
Move include/sound/tea575x-tuner.h to include/media/tea575x.h and update files
that include it.
Signed-off-by: Ondrej Zary li...@rainbow-software.org
---
drivers/media/radio/radio-maxiradio.c |2 +-
drivers/media/radio/radio-sf16fmr2.c |2 +-
drivers/media/radio/radio-shark.c |2 +-
include/media/tea575x.h | 79 +
include/sound/tea575x-tuner.h | 79 -
sound/i2c/other/tea575x-tuner.c |2 +-
sound/pci/es1968.c|2 +-
sound/pci/fm801.c |2 +-
8 files changed, 85 insertions(+), 85 deletions(-)
create mode 100644 include/media/tea575x.h
delete mode 100644 include/sound/tea575x-tuner.h
diff --git a/drivers/media/radio/radio-maxiradio.c
b/drivers/media/radio/radio-maxiradio.c
index 1d1c9e1..5236035 100644
--- a/drivers/media/radio/radio-maxiradio.c
+++ b/drivers/media/radio/radio-maxiradio.c
@@ -42,7 +42,7 @@
#include linux/videodev2.h
#include linux/io.h
#include linux/slab.h
-#include sound/tea575x-tuner.h
+#include media/tea575x.h
#include media/v4l2-device.h
#include media/v4l2-ioctl.h
#include media/v4l2-fh.h
diff --git a/drivers/media/radio/radio-sf16fmr2.c
b/drivers/media/radio/radio-sf16fmr2.c
index 9c09904..f1e3714 100644
--- a/drivers/media/radio/radio-sf16fmr2.c
+++ b/drivers/media/radio/radio-sf16fmr2.c
@@ -14,7 +14,7 @@
#include linux/io.h /* outb, outb_p */
#include linux/isa.h
#include linux/pnp.h
-#include sound/tea575x-tuner.h
+#include media/tea575x.h
MODULE_AUTHOR(Ondrej Zary);
MODULE_DESCRIPTION(MediaForte SF16-FMR2 and SF16-FMD2 FM radio card driver);
diff --git a/drivers/media/radio/radio-shark.c
b/drivers/media/radio/radio-shark.c
index 8fa18ab..b914772 100644
--- a/drivers/media/radio/radio-shark.c
+++ b/drivers/media/radio/radio-shark.c
@@ -33,7 +33,7 @@
#include linux/usb.h
#include linux/workqueue.h
#include media/v4l2-device.h
-#include sound/tea575x-tuner.h
+#include media/tea575x.h
#if defined(CONFIG_LEDS_CLASS) || \
(defined(CONFIG_LEDS_CLASS_MODULE) defined(CONFIG_RADIO_SHARK_MODULE))
diff --git a/include/media/tea575x.h b/include/media/tea575x.h
new file mode 100644
index 000..2d4fa59
--- /dev/null
+++ b/include/media/tea575x.h
@@ -0,0 +1,79 @@
+#ifndef __SOUND_TEA575X_TUNER_H
+#define __SOUND_TEA575X_TUNER_H
+
+/*
+ * ALSA driver for TEA5757/5759 Philips AM/FM tuner chips
+ *
+ * Copyright (c) 2004 Jaroslav Kysela pe...@perex.cz
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License as published by
+ * the Free Software Foundation; either version 2 of the License, or
+ * (at your option) any later version.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+ * GNU General Public License for more details.
+ *
+ * You should have received a copy of the GNU General Public License
+ * along with this program; if not, write to the Free Software
+ * Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA 02111-1307 USA
+ *
+ */
+
+#include linux/videodev2.h
+#include media/v4l2-ctrls.h
+#include media/v4l2-dev.h
+#include media/v4l2-device.h
+
+#define TEA575X_FMIF 10700
+#define TEA575X_AMIF 450
+
+#define TEA575X_DATA (1 0)
+#define TEA575X_CLK(1 1)
+#define TEA575X_WREN (1 2)
+#define TEA575X_MOST (1 3)
+
+struct snd_tea575x;
+
+struct snd_tea575x_ops {
+ /* Drivers using snd_tea575x must either define read_ and write_val */
+ void (*write_val)(struct snd_tea575x *tea, u32 val);
+ u32 (*read_val)(struct snd_tea575x *tea);
+ /* Or define the 3 pin functions */
+ void (*set_pins)(struct snd_tea575x *tea, u8 pins);
+ u8 (*get_pins)(struct snd_tea575x *tea);
+ void (*set_direction)(struct snd_tea575x *tea, bool output);
+};
+
+struct snd_tea575x {
+ struct v4l2_device *v4l2_dev;
+ struct v4l2_file_operations fops;
+ struct video_device vd; /* video device */
+ int radio_nr; /* radio_nr */
+ bool tea5759; /* 5759 chip is present */
+ bool has_am;/* Device can tune to AM freqs */
+ bool cannot_read_data; /* Device cannot read the data pin */
+ bool cannot_mute; /* Device cannot mute */
+ bool mute; /* Device is muted? */
+ bool stereo;/* receiving stereo */
+ bool tuned; /* tuned to a station */
+ unsigned int val; /* hw value */
+ u32 band; /* 0: FM, 1: FM-Japan, 2: AM */
+ u32 freq; /* frequency */
+ struct mutex mutex;
+ struct snd_tea575x_ops
[PATCH 0/2] tea575x: Move from sound to media
Hello, TEA575x is neither a sound device nor an i2c device. Let's finally move it from sound/i2c/other to drivers/media/radio. Tested with snd-es1968, snd-fm801 and radio-sf16fmr2. -- Ondrej Zary -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 2/2] tea575x: Move from sound to media
Move tea575x from sound/i2c/other to drivers/media/radio Includes Kconfig changes by Hans Verkuil. Signed-off-by: Hans Verkuil hans.verk...@cisco.com Signed-off-by: Ondrej Zary li...@rainbow-software.org --- drivers/media/radio/Kconfig | 12 +- drivers/media/radio/Makefile|1 + drivers/media/radio/tea575x.c | 584 +++ sound/i2c/other/Makefile|2 - sound/i2c/other/tea575x-tuner.c | 584 --- sound/pci/Kconfig |9 +- 6 files changed, 598 insertions(+), 594 deletions(-) create mode 100644 drivers/media/radio/tea575x.c delete mode 100644 sound/i2c/other/tea575x-tuner.c diff --git a/drivers/media/radio/Kconfig b/drivers/media/radio/Kconfig index d529ba7..39882dd 100644 --- a/drivers/media/radio/Kconfig +++ b/drivers/media/radio/Kconfig @@ -12,6 +12,9 @@ menuconfig RADIO_ADAPTERS if RADIO_ADAPTERS VIDEO_V4L2 +config RADIO_TEA575X + tristate + config RADIO_SI470X bool Silicon Labs Si470x FM Radio Receiver support depends on VIDEO_V4L2 @@ -61,7 +64,8 @@ config USB_DSBR config RADIO_MAXIRADIO tristate Guillemot MAXI Radio FM 2000 radio - depends on VIDEO_V4L2 PCI SND + depends on VIDEO_V4L2 PCI + select RADIO_TEA575X ---help--- Choose Y here if you have this radio card. This card may also be found as Gemtek PCI FM. @@ -76,7 +80,8 @@ config RADIO_MAXIRADIO config RADIO_SHARK tristate Griffin radioSHARK USB radio receiver - depends on USB SND + depends on USB + select RADIO_TEA575X ---help--- Choose Y here if you have this radio receiver. @@ -393,7 +398,8 @@ config RADIO_SF16FMI config RADIO_SF16FMR2 tristate SF16-FMR2/SF16-FMD2 Radio - depends on ISA VIDEO_V4L2 SND + depends on ISA VIDEO_V4L2 + select RADIO_TEA575X ---help--- Choose Y here if you have one of these FM radio cards. diff --git a/drivers/media/radio/Makefile b/drivers/media/radio/Makefile index 0dcdb32..3b64560 100644 --- a/drivers/media/radio/Makefile +++ b/drivers/media/radio/Makefile @@ -32,6 +32,7 @@ obj-$(CONFIG_RADIO_TEF6862) += tef6862.o obj-$(CONFIG_RADIO_TIMBERDALE) += radio-timb.o obj-$(CONFIG_RADIO_WL1273) += radio-wl1273.o obj-$(CONFIG_RADIO_WL128X) += wl128x/ +obj-$(CONFIG_RADIO_TEA575X) += tea575x.o shark2-objs := radio-shark2.o radio-tea5777.o diff --git a/drivers/media/radio/tea575x.c b/drivers/media/radio/tea575x.c new file mode 100644 index 000..cef0698 --- /dev/null +++ b/drivers/media/radio/tea575x.c @@ -0,0 +1,584 @@ +/* + * ALSA driver for TEA5757/5759 Philips AM/FM radio tuner chips + * + * Copyright (c) 2004 Jaroslav Kysela pe...@perex.cz + * + * + * This program is free software; you can redistribute it and/or modify + * it under the terms of the GNU General Public License as published by + * the Free Software Foundation; either version 2 of the License, or + * (at your option) any later version. + * + * This program is distributed in the hope that it will be useful, + * but WITHOUT ANY WARRANTY; without even the implied warranty of + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the + * GNU General Public License for more details. + * + * You should have received a copy of the GNU General Public License + * along with this program; if not, write to the Free Software + * Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA 02111-1307 USA + * + */ + +#include asm/io.h +#include linux/delay.h +#include linux/module.h +#include linux/init.h +#include linux/slab.h +#include linux/sched.h +#include media/v4l2-device.h +#include media/v4l2-dev.h +#include media/v4l2-fh.h +#include media/v4l2-ioctl.h +#include media/v4l2-event.h +#include media/tea575x.h + +MODULE_AUTHOR(Jaroslav Kysela pe...@perex.cz); +MODULE_DESCRIPTION(Routines for control of TEA5757/5759 Philips AM/FM radio tuner chips); +MODULE_LICENSE(GPL); + +/* + * definitions + */ + +#define TEA575X_BIT_SEARCH (124) /* 1 = search action, 0 = tuned */ +#define TEA575X_BIT_UPDOWN (123) /* 0 = search down, 1 = search up */ +#define TEA575X_BIT_MONO (122) /* 0 = stereo, 1 = mono */ +#define TEA575X_BIT_BAND_MASK (320) +#define TEA575X_BIT_BAND_FM(020) +#define TEA575X_BIT_BAND_MW(120) +#define TEA575X_BIT_BAND_LW(220) +#define TEA575X_BIT_BAND_SW(320) +#define TEA575X_BIT_PORT_0 (119) /* user bit */ +#define TEA575X_BIT_PORT_1 (118) /* user bit */ +#define TEA575X_BIT_SEARCH_MASK(316) /* search level */ +#define TEA575X_BIT_SEARCH_5_28 (016)/* FM 5uV, AM 28uV */ +#define TEA575X_BIT_SEARCH_10_40 (116) /* FM 10uV, AM 40uV */ +#define TEA575X_BIT_SEARCH_30_63 (216) /* FM 30uV, AM 63uV */ +#define TEA575X_BIT_SEARCH_150_1000 (316) /* FM 150uV, AM 1000uV */ +#define TEA575X_BIT_DUMMY
Green/purple video from 950Q + security cam
Hi, I have a WinTV-HVR-950Q which I am using to capture composite video. I have two cameras: a rear-view cam for a car, and a security camera. When I plug either of these cameras into the video plug on a plain old TV, they work great. When I plug either camera into the 950Q on Windows using the supplied WinTV software, they work great. When I plug the rear-view camera into the 950Q on Linux, it works great. But when I plug the security camera into 950Q on Linux, it mostly works and then the picture starts randomly jumping sideways (like it is having trouble keeping a horizontal sync on the signal) and then will suddenly flip to a green-grayscale image with all bright areas as purple-grayscale. Once turned green/purple, it remains like this until I reset the camera, but the video is full framerate, low latency, and looks flawless aside from the bizarre colors. For the tests under Linux, I am using the v4l2 API directly in a simple demo C program I wrote. It is attached. I tried both the read API, and the mmap API. Both produce identical results. My other attempts on Linux had been to use v4l2-ctl to select the composite channel, and then play the device with VLC or Cheese. Neither were successful (no video at all) but I need to do this from C in the long run, anyway. Anyone seen anything like this before? Thanks in advance. -Mike Some details: Linux Mint 12, 3.0.0-12-generic #20-Ubuntu SMP Fri Oct 7 14:56:25 UTC 2011 x86_64 x86_64 x86_64 GNU/Linux Bus 001 Device 007: ID 2040:7200 Hauppauge Device Descriptor: bLength18 bDescriptorType 1 bcdUSB 2.00 bDeviceClass0 (Defined at Interface level) bDeviceSubClass 0 bDeviceProtocol 0 bMaxPacketSize064 idVendor 0x2040 Hauppauge idProduct 0x7200 bcdDevice0.05 iManufacturer 1 iProduct2 iSerial10 bNumConfigurations 1 Relevant loaded modules: tuner 27428 1 au8522 27916 2 au0828 48363 0 dvb_core 110616 1 au0828 videobuf_vmalloc 13589 1 au0828 videobuf_core 26390 2 au0828,videobuf_vmalloc tveeprom 21249 1 au0828 v4l2_common16454 3 tuner,au8522,au0828 videodev 93004 4 tuner,au8522,au0828,v4l2_common v4l2_compat_ioctl3217083 1 videodev Relevant kernel messages (only from bootup, nothing new shows while playing) [ 10.467852] Linux video capture interface: v2.00 [ 10.677764] au0828 driver loaded [ 11.036080] au0828: i2c bus registered [ 11.294654] tveeprom 0-0050: Hauppauge model 72001, rev B4F0, serial# 8455749 [ 11.294658] tveeprom 0-0050: MAC address is 00:0d:fe:81:06:45 [ 11.294661] tveeprom 0-0050: tuner model is Xceive XC5000 (idx 150, type 76) [ 11.294664] tveeprom 0-0050: TV standards NTSC(M) ATSC/DVB Digital (eeprom 0x88) [ 11.294666] tveeprom 0-0050: audio processor is AU8522 (idx 44) [ 11.294669] tveeprom 0-0050: decoder processor is AU8522 (idx 42) [ 11.294672] tveeprom 0-0050: has no radio, has IR receiver, has no IR transmitter [ 11.294674] hauppauge_eeprom: hauppauge eeprom: model=72001 [ 11.321442] nvidia: module license 'NVIDIA' taints kernel. [ 11.321446] Disabling lock debugging due to kernel taint [ 12.006495] nvidia :01:00.0: PCI INT A - GSI 16 (level, low) - IRQ 16 [ 12.006503] nvidia :01:00.0: setting latency timer to 64 [ 12.006508] vgaarb: device changed decodes: PCI::01:00.0,olddecodes=io+mem,decodes=none:owns=io+mem [ 12.006583] NVRM: loading NVIDIA UNIX x86_64 Kernel Module 280.13 Wed Jul 27 16:53:56 PDT 2011 [ 12.020865] au8522 0-0047: creating new instance [ 12.020867] au8522_decoder creating new instance... [ 12.061240] i2c-core: driver [tuner] using legacy suspend method [ 12.061242] i2c-core: driver [tuner] using legacy resume method [ 12.061662] tuner 0-0061: Tuner -1 found with type(s) Radio TV. [ 12.089530] xc5000 0-0061: creating new instance [ 12.094274] xc5000: Successfully identified at address 0x61 [ 12.094277] xc5000: Firmware has not been loaded previously [ 12.094536] au8522 0-0047: attaching existing instance [ 12.101901] xc5000 0-0061: attaching existing instance [ 12.112396] xc5000: Successfully identified at address 0x61 [ 12.112398] xc5000: Firmware has not been loaded previously [ 12.112400] DVB: registering new adapter (au0828) [ 12.112402] DVB: registering adapter 0 frontend 0 (Auvitek AU8522 QAM/8VSB Frontend)... [ 12.112699] Registered device AU0828 [Hauppauge HVR950Q] [ 12.631925] usbcore: registered new interface driver snd-usb-audio [ 12.632064] usbcore: registered new interface driver au0828 Output from my program: Driver : au0828 Card : Hauppauge HVR950Q Bus: au0828 1-5.1.2:1.0 Version: 0.0.1 Caps : V4L2_CAP_VIDEO_CAPTURE V4L2_CAP_VBI_CAPTURE
[PATCH 2/3] include: Convert ethernet mac address declarations to use ETH_ALEN
It's convenient to have ethernet mac addresses use
ETH_ALEN to be able to grep for them a bit easier and
also to ensure that the addresses are __aligned(2).
Add #include linux/if_ether.h as necessary.
Signed-off-by: Joe Perches j...@perches.com
---
include/acpi/actbl2.h | 4 ++-
include/linux/dm9000.h | 4 ++-
include/linux/fs_enet_pd.h | 3 ++-
include/linux/ieee80211.h | 59 +
include/linux/mlx4/device.h | 11
include/linux/mlx4/qp.h | 5 ++--
include/linux/mv643xx_eth.h | 3 ++-
include/linux/sh_eth.h | 3 ++-
include/linux/smsc911x.h| 3 ++-
include/linux/uwb/spec.h| 5 ++--
include/media/tveeprom.h| 4 ++-
include/net/irda/irlan_common.h | 3 ++-
12 files changed, 61 insertions(+), 46 deletions(-)
diff --git a/include/acpi/actbl2.h b/include/acpi/actbl2.h
index ffaac0e..3f0f11c 100644
--- a/include/acpi/actbl2.h
+++ b/include/acpi/actbl2.h
@@ -44,6 +44,8 @@
#ifndef __ACTBL2_H__
#define __ACTBL2_H__
+#include linux/if_ether.h
+
/***
*
* Additional ACPI Tables (2)
@@ -605,7 +607,7 @@ struct acpi_ibft_nic {
u8 secondary_dns[16];
u8 dhcp[16];
u16 vlan;
- u8 mac_address[6];
+ u8 mac_address[ETH_ALEN];
u16 pci_address;
u16 name_length;
u16 name_offset;
diff --git a/include/linux/dm9000.h b/include/linux/dm9000.h
index 96e8769..841925f 100644
--- a/include/linux/dm9000.h
+++ b/include/linux/dm9000.h
@@ -14,6 +14,8 @@
#ifndef __DM9000_PLATFORM_DATA
#define __DM9000_PLATFORM_DATA __FILE__
+#include linux/if_ether.h
+
/* IO control flags */
#define DM9000_PLATF_8BITONLY (0x0001)
@@ -27,7 +29,7 @@
struct dm9000_plat_data {
unsigned intflags;
- unsigned char dev_addr[6];
+ unsigned char dev_addr[ETH_ALEN];
/* allow replacement IO routines */
diff --git a/include/linux/fs_enet_pd.h b/include/linux/fs_enet_pd.h
index 51b7934..343d82a 100644
--- a/include/linux/fs_enet_pd.h
+++ b/include/linux/fs_enet_pd.h
@@ -18,6 +18,7 @@
#include linux/string.h
#include linux/of_mdio.h
+#include linux/if_ether.h
#include asm/types.h
#define FS_ENET_NAME fs_enet
@@ -135,7 +136,7 @@ struct fs_platform_info {
const struct fs_mii_bus_info *bus_info;
int rx_ring, tx_ring; /* number of buffers on rx */
- __u8 macaddr[6];/* mac address */
+ __u8 macaddr[ETH_ALEN]; /* mac address */
int rx_copybreak; /* limit we copy small frames */
int use_napi; /* use NAPI*/
int napi_weight;/* NAPI weight */
diff --git a/include/linux/ieee80211.h b/include/linux/ieee80211.h
index b0dc87a..4e101af 100644
--- a/include/linux/ieee80211.h
+++ b/include/linux/ieee80211.h
@@ -16,6 +16,7 @@
#define LINUX_IEEE80211_H
#include linux/types.h
+#include linux/if_ether.h
#include asm/byteorder.h
/*
@@ -209,28 +210,28 @@ static inline u16 ieee80211_sn_sub(u16 sn1, u16 sn2)
struct ieee80211_hdr {
__le16 frame_control;
__le16 duration_id;
- u8 addr1[6];
- u8 addr2[6];
- u8 addr3[6];
+ u8 addr1[ETH_ALEN];
+ u8 addr2[ETH_ALEN];
+ u8 addr3[ETH_ALEN];
__le16 seq_ctrl;
- u8 addr4[6];
+ u8 addr4[ETH_ALEN];
} __packed __aligned(2);
struct ieee80211_hdr_3addr {
__le16 frame_control;
__le16 duration_id;
- u8 addr1[6];
- u8 addr2[6];
- u8 addr3[6];
+ u8 addr1[ETH_ALEN];
+ u8 addr2[ETH_ALEN];
+ u8 addr3[ETH_ALEN];
__le16 seq_ctrl;
} __packed __aligned(2);
struct ieee80211_qos_hdr {
__le16 frame_control;
__le16 duration_id;
- u8 addr1[6];
- u8 addr2[6];
- u8 addr3[6];
+ u8 addr1[ETH_ALEN];
+ u8 addr2[ETH_ALEN];
+ u8 addr3[ETH_ALEN];
__le16 seq_ctrl;
__le16 qos_ctrl;
} __packed __aligned(2);
@@ -608,8 +609,8 @@ struct ieee80211s_hdr {
u8 flags;
u8 ttl;
__le32 seqnum;
- u8 eaddr1[6];
- u8 eaddr2[6];
+ u8 eaddr1[ETH_ALEN];
+ u8 eaddr2[ETH_ALEN];
} __packed __aligned(2);
/* Mesh flags */
@@ -758,7 +759,7 @@ struct ieee80211_rann_ie {
u8 rann_flags;
u8 rann_hopcount;
u8 rann_ttl;
- u8 rann_addr[6];
+ u8 rann_addr[ETH_ALEN];
__le32 rann_seq;
__le32 rann_interval;
__le32 rann_metric;
@@ -802,9 +803,9 @@ enum ieee80211_vht_opmode_bits {
struct ieee80211_mgmt {
__le16 frame_control;
__le16 duration;
- u8 da[6];
- u8 sa[6];
- u8 bssid[6];
+ u8 da[ETH_ALEN];
+ u8 sa[ETH_ALEN];
+ u8 bssid[ETH_ALEN];
__le16 seq_ctrl;
union {
struct {
@@ -833,7 +834,7 @@ struct ieee80211_mgmt {
[PATCH 0/3] networking: Use ETH_ALEN where appropriate
Convert the uses mac addresses to ETH_ALEN so it's easier to find and verify where mac addresses need to be __aligned(2) Joe Perches (3): uapi: Convert some uses of 6 to ETH_ALEN include: Convert ethernet mac address declarations to use ETH_ALEN ethernet: Convert mac address uses of 6 to ETH_ALEN drivers/net/ethernet/8390/ax88796.c| 4 +- drivers/net/ethernet/amd/pcnet32.c | 6 +-- drivers/net/ethernet/broadcom/cnic_if.h| 6 +-- drivers/net/ethernet/dec/tulip/tulip_core.c| 8 +-- drivers/net/ethernet/i825xx/sun3_82586.h | 4 +- drivers/net/ethernet/myricom/myri10ge/myri10ge.c | 2 +- drivers/net/ethernet/nuvoton/w90p910_ether.c | 4 +- drivers/net/ethernet/pasemi/pasemi_mac.c | 13 ++--- drivers/net/ethernet/pasemi/pasemi_mac.h | 4 +- drivers/net/ethernet/qlogic/netxen/netxen_nic_hw.c | 4 +- drivers/net/ethernet/qlogic/qlge/qlge.h| 2 +- include/acpi/actbl2.h | 4 +- include/linux/dm9000.h | 4 +- include/linux/fs_enet_pd.h | 3 +- include/linux/ieee80211.h | 59 +++--- include/linux/mlx4/device.h| 11 ++-- include/linux/mlx4/qp.h| 5 +- include/linux/mv643xx_eth.h| 3 +- include/linux/sh_eth.h | 3 +- include/linux/smsc911x.h | 3 +- include/linux/uwb/spec.h | 5 +- include/media/tveeprom.h | 4 +- include/net/irda/irlan_common.h| 3 +- include/uapi/linux/dn.h| 3 +- include/uapi/linux/if_bridge.h | 3 +- include/uapi/linux/netfilter_bridge/ebt_802_3.h| 5 +- include/uapi/linux/netfilter_ipv4/ipt_CLUSTERIP.h | 3 +- include/uapi/linux/virtio_net.h| 2 +- include/uapi/linux/wimax/i2400m.h | 4 +- 29 files changed, 103 insertions(+), 81 deletions(-) -- 1.8.1.2.459.gbcd45b4.dirty -- 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: [REVIEW PATCH 0/6] exynos4-is: Asynchronous subdev registration support
Hi Sylwester, On Wed, Jul 24, 2013 at 12:09 AM, Sylwester Nawrocki s.nawro...@samsung.com wrote: This patch series is a refactoring of the exynos4-is driver to get rid of the common fimc-is-sensor driver and to adapt it to use standard sensor subdev drivers, one per each image sensor type. Then a clock provider is added to the exynos4-is driver and the s5k6a3 subdev is modified to use one of the clocks registered by exynos4-is. Arun, I think you could reuse the s5k6a3 sensor for your work on the Exynos5 FIMC-IS driver. One advantage of separate sensor drivers is that the power on/off sequences can be written specifically for each sensor. We are probably going to need such sequences per board in future. Also having the clock control inside the sensor subdev allows to better match the hardware power on/off sequence requirements, however the S5K6A3 sensor can have active clock signal on its clock input pin even when all its power supplies are turned off. I'm posting this series before having a proper implementation for clk_unregister() in the clock framework, so you are not blocked with your Exynos5 FIMC-IS works. Thank you for the patches. I am modifying exynos5-is based on the same design. Thanks Regards Arun -- 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: [REVIEW PATCH 4/6] exynos4-is: Add clock provider for the external clocks
Hi Sylwester,
On Wed, Jul 24, 2013 at 12:09 AM, Sylwester Nawrocki
s.nawro...@samsung.com wrote:
This patch adds clock provider to expose the sclk_cam0/1 clocks
for image sensor subdevs.
Signed-off-by: Sylwester Nawrocki s.nawro...@samsung.com
Signed-off-by: Kyungmin Park kyungmin.p...@samsung.com
---
.../devicetree/bindings/media/samsung-fimc.txt | 17 +++-
drivers/media/platform/exynos4-is/media-dev.c | 92
drivers/media/platform/exynos4-is/media-dev.h | 19 +++-
3 files changed, 125 insertions(+), 3 deletions(-)
diff --git a/Documentation/devicetree/bindings/media/samsung-fimc.txt
b/Documentation/devicetree/bindings/media/samsung-fimc.txt
index 96312f6..04a2b87 100644
--- a/Documentation/devicetree/bindings/media/samsung-fimc.txt
+++ b/Documentation/devicetree/bindings/media/samsung-fimc.txt
@@ -91,6 +91,15 @@ Optional properties
- samsung,camclk-out : specifies clock output for remote sensor,
0 - CAM_A_CLKOUT, 1 - CAM_B_CLKOUT;
+'clock-controller' node (optional)
+--
+
+The purpose of this node is to define a clock provider for external image
+sensors and link any of the CAM_?_CLKOUT clock outputs with related external
+clock consumer device. Properties specific to this node are described in
+../clock/clock-bindings.txt.
+
+
Image sensor nodes
--
@@ -114,7 +123,7 @@ Example:
vddio-supply = ...;
clock-frequency = 2400;
- clocks = ...;
+ clocks = camclk 1;
clock-names = mclk;
port {
@@ -135,7 +144,7 @@ Example:
vddio-supply = ...;
clock-frequency = 2400;
- clocks = ...;
+ clocks = camclk 0;
clock-names = mclk;
port {
@@ -156,6 +165,10 @@ Example:
pinctrl-names = default;
pinctrl-0 = cam_port_a_clk_active;
+ camclk: clock-controller {
+ #clock-cells = 1;
Isn't it
#clock-cells = 1;
?
+ };
+
Regards
Arun
--
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
