__tda18271_write_regs ERROR
Hi, On a freshly booted rpi2, I got this in the logs (3rd line from bottom): [ 12.999134] em28xx 1-1.2.4.1:1.0: New device PCTV Systems PCTV 290e @ 480 Mbps (2013:024f, interface 0, class 0) [ 13.072265] em28xx 1-1.2.4.1:1.0: DVB interface 0 found: isoc [ 13.082114] em28xx 1-1.2.4.1:1.0: chip ID is em28174 [ 13.477093] em28xx 1-1.2.4.1:1.0: EEPROM ID = 26 00 01 00, EEPROM hash = 0x11372abd [ 13.491322] em28xx 1-1.2.4.1:1.0: EEPROM info: [ 13.499089] em28xx 1-1.2.4.1:1.0:microcode start address = 0x0004, boot configuration = 0x01 [ 13.538392] em28xx 1-1.2.4.1:1.0:No audio on board. [ 13.546833] em28xx 1-1.2.4.1:1.0:500mA max power [ 13.554815] em28xx 1-1.2.4.1:1.0:Table at offset 0x39, strings=0x1aa0, 0x14ba, 0x1ace [ 13.569346] em28xx 1-1.2.4.1:1.0: Identified as PCTV nanoStick T2 290e (card=78) [ 13.583142] em28xx 1-1.2.4.1:1.0: dvb set to isoc mode. [ 13.592690] em28xx 1-1.2.4.3:1.0: New device PCTV PCTV 292e @ 480 Mbps (2013:025f, interface 0, class 0) [ 13.609209] em28xx 1-1.2.4.3:1.0: DVB interface 0 found: isoc [ 13.618736] em28xx 1-1.2.4.3:1.0: chip ID is em28178 [ 15.742114] em28xx 1-1.2.4.3:1.0: EEPROM ID = 26 00 01 00, EEPROM hash = 0x1f10fa04 [ 15.742126] em28xx 1-1.2.4.3:1.0: EEPROM info: [ 15.742136] em28xx 1-1.2.4.3:1.0:microcode start address = 0x0004, boot configuration = 0x01 [ 15.74] em28xx 1-1.2.4.3:1.0:AC97 audio (5 sample rates) [ 15.750012] em28xx 1-1.2.4.3:1.0:500mA max power [ 15.750028] em28xx 1-1.2.4.3:1.0:Table at offset 0x27, strings=0x146a, 0x1888, 0x0a7e [ 15.750417] em28xx 1-1.2.4.3:1.0: Identified as PCTV tripleStick (292e) (card=94) [ 15.750432] em28xx 1-1.2.4.3:1.0: dvb set to isoc mode. [ 15.753015] usbcore: registered new interface driver em28xx [ 15.808636] em28xx 1-1.2.4.1:1.0: Binding DVB extension [ 15.876054] cxd2820r 4-006c: Sony CXD2820R successfully identified [ 15.905239] tda18271 4-0060: creating new instance [ 15.923907] tda18271: TDA18271HD/C2 detected @ 4-0060 [ 16.425196] dvbdev: DVB: registering new adapter (1-1.2.4.1:1.0) [ 16.435689] em28xx 1-1.2.4.1:1.0: DVB: registering adapter 0 frontend 0 (Sony CXD2820R)... [ 16.453437] em28xx 1-1.2.4.1:1.0: DVB extension successfully initialized [ 16.463783] em28xx 1-1.2.4.3:1.0: Binding DVB extension [ 16.499683] i2c i2c-6: Added multiplexed i2c bus 7 [ 16.508155] si2168 6-0064: Silicon Labs Si2168-B40 successfully identified [ 16.518485] si2168 6-0064: firmware version: B 4.0.2 [ 16.545725] si2157 7-0060: Silicon Labs Si2147/2148/2157/2158 successfully attached [ 16.560772] dvbdev: DVB: registering new adapter (1-1.2.4.3:1.0) [ 16.570481] em28xx 1-1.2.4.3:1.0: DVB: registering adapter 1 frontend 0 (Silicon Labs Si2168)... [ 16.592323] em28xx 1-1.2.4.3:1.0: DVB extension successfully initialized [ 16.602913] em28xx: Registered (Em28xx dvb Extension) extension [ 16.640109] em28xx 1-1.2.4.1:1.0: Registering input extension [ 16.651247] rc rc0: 1-1.2.4.1:1.0 IR as /devices/platform/soc/3f98.usb/usb1/1-1/1-1.2/1-1.2.4/1-1.2.4.1/1-1.2.4.1:1.0/rc/rc0 [ 16.722038] Registered IR keymap rc-pinnacle-pctv-hd [ 16.733053] input: 1-1.2.4.1:1.0 IR as /devices/platform/soc/3f98.usb/usb1/1-1/1-1.2/1-1.2.4/1-1.2.4.1/1-1.2.4.1:1.0/rc/rc0/input2 [ 16.753630] em28xx 1-1.2.4.1:1.0: Input extension successfully initalized [ 16.764109] em28xx 1-1.2.4.3:1.0: Registering input extension [ 16.774447] rc rc1: 1-1.2.4.3:1.0 IR as /devices/platform/soc/3f98.usb/usb1/1-1/1-1.2/1-1.2.4/1-1.2.4.3/1-1.2.4.3:1.0/rc/rc1 [ 16.792973] Registered IR keymap rc-pinnacle-pctv-hd [ 16.802484] input: 1-1.2.4.3:1.0 IR as /devices/platform/soc/3f98.usb/usb1/1-1/1-1.2/1-1.2.4/1-1.2.4.3/1-1.2.4.3:1.0/rc/rc1/input3 [ 16.822322] em28xx 1-1.2.4.3:1.0: Input extension successfully initalized [ 16.832818] em28xx: Registered (Em28xx Input Extension) extension [ 22.142086] si2168 6-0064: downloading firmware from file 'dvb-demod-si2168-b40-01.fw' [ 22.641659] si2168 6-0064: firmware version: B 4.0.11 [ 22.659062] si2157 7-0060: found a 'Silicon Labs Si2157-A30' [ 22.719300] si2157 7-0060: firmware version: 3.0.5 [ 22.728337] em28xx 1-1.2.4.3:1.0: DVB: adapter 1 frontend 0 frequency 0 out of range (4200..87000) [ 23.257682] tda18271: performing RF tracking filter calibration [ 26.994564] em28xx 1-1.2.4.1:1.0: write to i2c device at 0xd8 failed with unknown error (status=1) [ 27.021126] __tda18271_write_regs: [4-0060|M] ERROR: idx = 0x21, len = 1, i2c_transfer returned: -6 [ 28.125996] tda18271: RF tracking filter calibration complete [ 28.137028] em28xx 1-1.2.4.1:1.0: DVB: adapter 0 frontend 0 frequency 0 out of range (4500..86400) Is this expected? It's running 4.12.3-v7+ from the rpi tree. -Anders
Re: em28xx i2c writing error
On Mon, Apr 17, 2017 at 3:55 AM, Mauro Carvalho Chehab <mche...@s-opensource.com> wrote: > Em Sat, 15 Apr 2017 20:28:20 +0200 > Anders Eriksson <aerikss...@gmail.com> escreveu: > >> Hi Mauro, >> >> I've two devices using this driver, and whenever I have them both in >> use I eventually (between 10K and 100K secs uptime) i2c write errors >> such as in the log below. If only have one of the devices in use, the >> machine is stable. >> >> The machine never recovers from the error. >> >> All help apreciated. >> -Anders >> >> >> >> [0.00] Booting Linux on physical CPU 0xf00 >> [0.00] Initializing cgroup subsys cpuset >> [0.00] Initializing cgroup subsys cpu >> [0.00] Initializing cgroup subsys cpuacct >> [0.00] Linux version 4.4.15-v7+ (dc4@dc4-XPS13-9333) (gcc >> version 4.9.3 (crosstool-NG crosstool-ng-1.22.0-88-g8460611) ) #897 >> SMP Tue Jul 12 18:42:55 BST 2016 >> [0.00] CPU: ARMv7 Processor [410fc075] revision 5 (ARMv7), >> cr=10c5387d >> [0.00] CPU: PIPT / VIPT nonaliasing data cache, VIPT aliasing >> instruction cache >> [0.00] Machine model: Raspberry Pi 2 Model B Rev 1.1 > > Hmm.. RPi2... that explains a lot ;) > > I've seen similar behaviors on some arm devices with just one device. > > That's likely due to some problem with isochronous transfers at the > USB host driver. > > The thing is that ISOC transfers are heavily used by USB cameras: > they require that the USB chip would provide a steady throughput > that can eat up to 60% of the USB maximum bitrate, with just one > video stream. > > My experience says that several USB drivers can't sustain such > bit rates for a long time. > > The RPi tree uses an out-of-tree driver for the USB host driver > (otgdwc - I guess). Upstream uses a different driver (dwc2). > My recent experiences with upstream(dwc2) and USB cameras > is even worse: it doesn't work, if the camera supports only > ISOC frames. > > I'll eventually try to fix the upstream driver if I find > spare time for it, but I won't touch at the proprietary > driver that is shipped with the downstream Kernel. > Hi, I'd appreciate any attempt to fix this. My experience is that it (the rpi2 with otgdwc) bugs out after 10k-100k of uptime, and can sustain parallel recordings (using both tv-receivers), so the rest of the systems seems to be working ok. I'd be happy to try out any patches you create for the upstream driver. Br, Anders
Re: em28xx i2c writing error
Hi Frank, On Sun, Apr 16, 2017 at 7:59 PM, Frank Schäfer <fschaefer@googlemail.com> wrote: > > Am 15.04.2017 um 20:28 schrieb Anders Eriksson: >> Hi Mauro, >> >> I've two devices using this driver, and whenever I have them both in >> use I eventually (between 10K and 100K secs uptime) i2c write errors >> such as in the log below. If only have one of the devices in use, the >> machine is stable. >> >> The machine never recovers from the error. >> >> All help apreciated. >> -Anders >> >> >> >> [ 45.616358] br0: port 6(vb-work) entered forwarding state >> [ 45.634769] br0: port 6(vb-work) entered forwarding state >> [ 54.045274] br0: port 5(vb-revproxy) entered forwarding state >> [ 60.645283] br0: port 6(vb-work) entered forwarding state > Did you skip any lines here ? Any usb related messages ? > Nope. It ran without any messages up to 93093 >> [93038.637557] em28178 #1: writing to i2c device at 0xc8 failed (error=-5) >> [93038.737581] em28174 #0: writing to i2c device at 0xd8 failed (error=-5) > -5 is -EIO, which means the errors occure at usb level (line 176 in > em28xx-core.c) > However, the actual error returned by usb_control_msg() might be > different, because it is passed through usb_translate_errors(). > > Hth, > Frank > I add linux-usb@ and see who might knwo something. Do you know whom I should contact wrt usb? Br, Anders >> [93038.746399] i2c i2c-4: cxd2820r: i2c rd failed=-5 reg=10 len=1 >> [93039.247560] em28178 #1: writing to i2c device at 0xc8 failed (error=-5) >> [93039.447579] em28178 #1: writing to i2c device at 0xc8 failed (error=-5) >> [93039.647559] em28178 #1: writing to i2c device at 0xc8 failed (error=-5) >> [93039.847564] em28178 #1: writing to i2c device at 0xc8 failed (error=-5) >> [93040.047567] em28178 #1: writing to i2c device at 0xc8 failed (error=-5) >> [93040.157570] em28174 #0: writing to i2c device at 0xd8 failed (error=-5) >> [93040.165915] i2c i2c-4: cxd2820r: i2c rd failed=-5 reg=10 len=1 >> [93041.047583] em28178 #1: writing to i2c device at 0xc8 failed (error=-5) >> [93041.167571] em28174 #0: writing to i2c device at 0xd8 failed (error=-5) >> [93041.175973] i2c i2c-4: cxd2820r: i2c rd failed=-5 reg=10 len=1 >> [93042.047587] em28178 #1: writing to i2c device at 0xc8 failed (error=-5) >> [93042.177582] em28174 #0: writing to i2c device at 0xd8 failed (error=-5) >> [93042.185886] i2c i2c-4: cxd2820r: i2c rd failed=-5 reg=10 len=1 >> [93043.047590] em28178 #1: writing to i2c device at 0xc8 failed (error=-5) >> [93043.187592] em28174 #0: writing to i2c device at 0xd8 failed (error=-5) >> [93043.195868] i2c i2c-4: cxd2820r: i2c rd failed=-5 reg=10 len=1 >> [93044.047593] em28178 #1: writing to i2c device at 0xc8 failed (error=-5) >> [93044.197589] em28174 #0: writing to i2c device at 0xd8 failed (error=-5) >> [93044.205925] i2c i2c-4: cxd2820r: i2c rd failed=-5 reg=10 len=1 >> [93045.047597] em28178 #1: writing to i2c device at 0xc8 failed (error=-5) >> [93045.207593] em28174 #0: writing to i2c device at 0xd8 failed (error=-5) >> [93045.215996] i2c i2c-4: cxd2820r: i2c rd failed=-5 reg=10 len=1 >> [93046.117605] em28178 #1: writing to i2c device at 0xc8 failed (error=-5) >> [93046.217617] em28174 #0: writing to i2c device at 0xd8 failed (error=-5) >> [93046.226038] i2c i2c-4: cxd2820r: i2c rd failed=-5 reg=10 len=1 >> [93047.127686] em28178 #1: writing to i2c device at 0xc8 failed (error=-5) >> [93048.127607] em28178 #1: writing to i2c device at 0xc8 failed (error=-5) >> [93049.127649] em28178 #1: writing to i2c device at 0xc8 failed (error=-5) >> [93050.127623] em28178 #1: writing to i2c device at 0xc8 failed (error=-5) >> [93051.127653] em28178 #1: writing to i2c device at 0xc8 failed (error=-5) >> [93052.127661] em28178 #1: writing to i2c device at 0xc8 failed (error=-5) >> [93053.127629] em28178 #1: writing to i2c device at 0xc8 failed (error=-5) >> [93054.127676] em28178 #1: writing to i2c device at 0xc8 failed (error=-5) >> [93055.127642] em28178 #1: writing to i2c device at 0xc8 failed (error=-5) >> [93055.567657] em28178 #1: writing to i2c device at 0xc8 failed (error=-5) >> [93055.627642] em28174 #0: writing to i2c device at 0xd8 failed (error=-5) >> [93055.635697] i2c i2c-4: cxd2820r: i2c wr failed=-5 reg=85 len=1 >> [93055.737670] em28174 #0: writing to i2c device at 0xd8 failed (error=-5) >> [93055.745838] i2c i2c-4: cxd2820r: i2c rd failed=-5 reg=10 len=1 >> [93055.767696] em28178 #1: writing to i2c device at 0xc8 failed (error=-5) >> [93055.937644] em28174 #0: writing to i2c device at 0xd8 failed (error=-5) >> [93055.945765] i
em28xx i2c writing error
Hi Mauro, I've two devices using this driver, and whenever I have them both in use I eventually (between 10K and 100K secs uptime) i2c write errors such as in the log below. If only have one of the devices in use, the machine is stable. The machine never recovers from the error. All help apreciated. -Anders [0.00] Booting Linux on physical CPU 0xf00 [0.00] Initializing cgroup subsys cpuset [0.00] Initializing cgroup subsys cpu [0.00] Initializing cgroup subsys cpuacct [0.00] Linux version 4.4.15-v7+ (dc4@dc4-XPS13-9333) (gcc version 4.9.3 (crosstool-NG crosstool-ng-1.22.0-88-g8460611) ) #897 SMP Tue Jul 12 18:42:55 BST 2016 [0.00] CPU: ARMv7 Processor [410fc075] revision 5 (ARMv7), cr=10c5387d [0.00] CPU: PIPT / VIPT nonaliasing data cache, VIPT aliasing instruction cache [0.00] Machine model: Raspberry Pi 2 Model B Rev 1.1 [0.00] cma: Reserved 8 MiB at 0x3a80 [0.00] Memory policy: Data cache writealloc [0.00] On node 0 totalpages: 241664 [0.00] free_area_init_node: node 0, pgdat 808c0e00, node_mem_map b9fa6000 [0.00] Normal zone: 2124 pages used for memmap [0.00] Normal zone: 0 pages reserved [0.00] Normal zone: 241664 pages, LIFO batch:31 [0.00] [bcm2709_smp_init_cpus] enter (9520->f3003010) [0.00] [bcm2709_smp_init_cpus] ncores=4 [0.00] PERCPU: Embedded 13 pages/cpu @b9f62000 s22592 r8192 d22464 u53248 [0.00] pcpu-alloc: s22592 r8192 d22464 u53248 alloc=13*4096 [0.00] pcpu-alloc: [0] 0 [0] 1 [0] 2 [0] 3 [0.00] Built 1 zonelists in Zone order, mobility grouping on. Total pages: 239540 [0.00] Kernel command line: dma.dmachans=0x7f35 bcm2708_fb.fbwidth=656 bcm2708_fb.fbheight=416 bcm2709.boardrev=0xa01041 bcm2709.serial=0x9aa48012 smsc95xx.macaddr=B8:27:EB:A4:80:12 bcm2708_fb.fbswap=1 bcm2709.uart_clock=4800 bcm2709.disk_led_gpio=47 bcm2709.disk_led_active_low=0 vc_mem.mem_base=0x3dc0 vc_mem.mem_size=0x3f00 root=/dev/mmcblk0p4 smsc95xx.turbo_mode=N rootdelay=2 console=ttyAMA0,115200 console=tty0 kgdboc=ttyAMA0,115200 init=/usr/lib/systemd/systemd ro [0.00] PID hash table entries: 4096 (order: 2, 16384 bytes) [0.00] Dentry cache hash table entries: 131072 (order: 7, 524288 bytes) [0.00] Inode-cache hash table entries: 65536 (order: 6, 262144 bytes) [0.00] Memory: 939080K/966656K available (6344K kernel code, 432K rwdata, 1712K rodata, 476K init, 764K bss, 19384K reserved, 8192K cma-reserved) [0.00] Virtual kernel memory layout: vector : 0x - 0x1000 ( 4 kB) fixmap : 0xffc0 - 0xfff0 (3072 kB) vmalloc : 0xbb80 - 0xff80 (1088 MB) lowmem : 0x8000 - 0xbb00 ( 944 MB) modules : 0x7f00 - 0x8000 ( 16 MB) .text : 0x80008000 - 0x807e6470 (8058 kB) .init : 0x807e7000 - 0x8085e000 ( 476 kB) .data : 0x8085e000 - 0x808ca108 ( 433 kB) .bss : 0x808cd000 - 0x8098c1ac ( 765 kB) [0.00] SLUB: HWalign=64, Order=0-3, MinObjects=0, CPUs=4, Nodes=1 [0.00] Hierarchical RCU implementation. [0.00] Build-time adjustment of leaf fanout to 32. [0.00] NR_IRQS:16 nr_irqs:16 16 [0.00] Architected cp15 timer(s) running at 19.20MHz (phys). [0.00] clocksource: arch_sys_counter: mask: 0xff max_cycles: 0x46d987e47, max_idle_ns: 440795202767 ns [0.11] sched_clock: 56 bits at 19MHz, resolution 52ns, wraps every 4398046511078ns [0.32] Switching to timer-based delay loop, resolution 52ns [0.000353] Console: colour dummy device 80x30 [0.001539] console [tty0] enabled [0.001591] Calibrating delay loop (skipped), value calculated using timer frequency.. 38.40 BogoMIPS (lpj=192000) [0.001667] pid_max: default: 32768 minimum: 301 [0.002077] Mount-cache hash table entries: 2048 (order: 1, 8192 bytes) [0.002128] Mountpoint-cache hash table entries: 2048 (order: 1, 8192 bytes) [0.003338] Disabling cpuset control group subsystem [0.003423] Initializing cgroup subsys io [0.003483] Initializing cgroup subsys memory [0.003563] Initializing cgroup subsys devices [0.003615] Initializing cgroup subsys freezer [0.003665] Initializing cgroup subsys net_cls [0.003764] CPU: Testing write buffer coherency: ok [0.003878] ftrace: allocating 21209 entries in 63 pages [0.056189] CPU0: update cpu_capacity 1024 [0.056269] CPU0: thread -1, cpu 0, socket 15, mpidr 8f00 [0.056306] [bcm2709_smp_prepare_cpus] enter [0.056463] Setting up static identity map for 0x8240 - 0x8274 [0.058860] [bcm2709_boot_secondary] cpu:1 started (0) 18 [0.059298] [bcm2709_secondary_init] enter cpu:1 [0.059356] CPU1: update cpu_capacity 1024 [0.059364]
Re: [PATCH 4/4] IR/imon: set up mce-only devices w/mce keytable
ja...@redhat.com said: + /* iMON LCD, MCE IR */ + case 0x9e: + dev_info(ictx-dev, 0xffdc iMON VFD, MCE IR); + detected_display_type = IMON_DISPLAY_TYPE_VFD; + allowed_protos = IR_TYPE_RC6; + break; + /* iMON LCD, MCE IR */ +case 0x9f: That LCD in the comment should be VFD. /Anders -- 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: Fixed (Was:Re: saa7134/2.6.26 regression, noisy output)
tomloh...@gmail.com said: Hello list, you are talking about tuner_config = 1 for the hvr 1110, right ? No. We're talking about the switch_addr variable. This variable is not changeable with module parameters. Changing this option doesn't affect the qualitie of the signal on tv see http://forum.ubuntu-fr.org/viewtopic.php?pid=1472261 it 's an old discussion in french. This option, as far as i remenber, was not provided by me ... anyway with tuner debug=1 and .tuner_config=1 , i have no line with AGC or LNA on dmesg You only get this output if you enable debugging. Here's what i have (gentoo): and...@tv /etc/modprobe.d $ grep '' saa7134 saa7134_alsa tda827x tda8290 tuner saa7134:options saa7134 disable_ir=1 alsa=1 core_debug=1 i2c_debug=1 saa7134:#options saa7134 alsa=1 saa7134_alsa:options saa7134_alsa debug=1 tda827x:options tda827x debug=1 tda8290:options tda8290 debug=1 tuner:options tuner debug=1 If you adjust your module options similarly, you'll get more info in dmesg. If you're ok with patching kernel source, could you try the patch I sent? I have somme glitchs with hvr1110 on dvb (not analogic tv) and many for one particular station call M6 (and i'm not the only one user, see previous post on ubuntu-fr.org, with short or long distance from tv relay) . Bug on 310i means potentially bug on hvr1110 as configuration on hvr 1110 was made from 310i I've never tried my 310i on digital (dvb-t), so I'm afraid I cannot help you there. I use it on analogue cable tv. -Anders -- 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: Fixed (Was:Re: saa7134/2.6.26 regression, noisy output)
hermann-pit...@arcor.de said: thanks a lot for all your time and energy you did spend on this My pleasure. Especially since I start to see some progress! I suggest we start collecting photographs of different LNA circuits on the wiki. Do you want me to open up the case and take some photos of the board? Any particular circuit I should look for? For now, Tom offered his support already off list, I think we should start about the question, if that early Hauppauge HVR 1110 has such an LNA type one at all, since this caused to not look at it further, as it seemed to be without problems. Well, this is a Pinnacle 310i, not a Hauppauge. At least acording to the box it came in! Are we talking about two different cards here? /Anders -- 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
Fixed (Was:Re: saa7134/2.6.26 regression, noisy output)
Success! I've tracked down the offending change. switch_addr takes on the wrong value and setting the LNA fails. Here's a i2c dump: saa7133[0]: i2c eeprom e0: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff saa7133[0]: i2c eeprom f0: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff saa7133[0]: i2c xfer: 20 ERROR: NO_DEVICE saa7133[0]: i2c xfer: 84 ERROR: NO_DEVICE saa7133[0]: i2c xfer: 86 ERROR: NO_DEVICE saa7133[0]: i2c xfer: 94 ERROR: NO_DEVICE saa7133[0]: i2c xfer: 96 saa7133[0]: i2c xfer: 96 00 saa7133[0]: i2c xfer: 97 =01 =01 =00 =11 =01 =04 =01 =85 saa7133[0]: i2c xfer: 96 1f saa7133[0]: i2c xfer: 97 =89 tda8290_probe: tda8290 detected @ 1-004b tuner' 1-004b: tda829x detected tuner' 1-004b: Setting mode_mask to 0x0e tuner' 1-004b: chip found @ 0x96 (saa7133[0]) tuner' 1-004b: tuner 0x4b: Tuner type absent tuner' i2c attach [addr=0x4b,client=(tuner unset)] tuner' 1-004b: Calling set_type_addr for type=54, addr=0xff, mode=0x04, config=0x01 tuner' 1-004b: set addr for type -1 tuner' 1-004b: defining GPIO callback saa7133[0]: i2c xfer: 96 1f saa7133[0]: i2c xfer: 97 =89 tda8290_probe: tda8290 detected @ 1-004b saa7133[0]: i2c xfer: 96 2f saa7133[0]: i2c xfer: 97 =00 saa7133[0]: i2c xfer: 96 21 c0 saa7133[0]: i2c xfer: c1 ERROR: NO_DEVICE saa7133[0]: i2c xfer: c3 =88 saa7133[0]: i2c xfer: c5 ERROR: NO_DEVICE saa7133[0]: i2c xfer: c7 ERROR: NO_DEVICE saa7133[0]: i2c xfer: 96 21 00 tda829x 1-004b: setting tuner address to 61 saa7133[0]: i2c xfer: 96 21 c0 saa7133[0]: i2c xfer: c3 =08 tda827x: tda827x_attach: tda827x: type set to Philips TDA827X saa7133[0]: i2c xfer: c3 =08 tda827x: tda827xa tuner found tda827x: tda827x_init: tda827x: tda827xa_sleep: saa7133[0]: i2c xfer: c2 30 90 saa7133[0]: i2c xfer: 96 21 00 tda829x 1-004b: type set to tda8290+75a saa7133[0]: i2c xfer: 96 21 c0 saa7133[0]: i2c xfer: c2 00 00 00 00 dc 05 8b 0c 04 20 ff 00 00 4b saa7133[0]: i2c xfer: 96 21 00 saa7133[0]: i2c xfer: 96 20 01 saa7133[0]: i2c xfer: 96 30 6f tuner' 1-004b: type set to tda8290+75a tuner' 1-004b: tv freq set to 400.00 tda829x 1-004b: setting tda829x to system xx tda829x 1-004b: tda827xa config is 0x01 saa7133[0]: i2c xfer: 96 01 00 saa7133[0]: i2c xfer: 96 02 00 saa7133[0]: i2c xfer: 96 00 00 saa7133[0]: i2c xfer: 96 01 90 saa7133[0]: i2c xfer: 96 28 14 saa7133[0]: i2c xfer: 96 0f 88 saa7133[0]: i2c xfer: 96 05 04 saa7133[0]: i2c xfer: 96 0d 47 saa7133[0]: i2c xfer: 96 21 c0 tda827x: setting tda827x to system xx tda827x: setting LNA to high gain saa7133[0]: i2c xfer: 96 22 00 ^ This address is c2 in all kernels = 5823b3a63c7661272ea7fef7635955e2a50d17eb saa7133[0]: i2c xfer: c2 00 32 f8 00 16 3b bb 1c 04 20 00 saa7133[0]: i2c xfer: c2 90 ff e0 00 99 saa7133[0]: i2c xfer: c2 a0 c0 saa7133[0]: i2c xfer: c2 30 10 saa7133[0]: i2c xfer: c3 =49 =a4 tda827x: AGC2 gain is: 10 ^ The gain reported on good kernels is 3 Looking at the source, the switch_addr to use in the later kernels is somehow autodetected. How that's done, I've yet to fully understand, but somehow it comes up with the wrong address. This patch (which obviously needs improvement) hardwires the address back to its original value, and works for 2.6.30-rc5. diff --git a/drivers/media/common/tuners/tda8290.c b/drivers/media/common/tuners/tda8290.c index 064d14c..498cc7b 100644 --- a/drivers/media/common/tuners/tda8290.c +++ b/drivers/media/common/tuners/tda8290.c @@ -635,7 +635,11 @@ static int tda829x_find_tuner(struct dvb_frontend *fe) dvb_attach(tda827x_attach, fe, priv-tda827x_addr, priv-i2c_props.adap, priv-cfg); + tuner_info(ANDERS: setting switch_addr. was 0x%02x, new 0x%02x\n,priv-cfg.switch_addr,priv-i2c_props.addr); priv-cfg.switch_addr = priv-i2c_props.addr; + priv-cfg.switch_addr = 0xc2 / 2; + tuner_info(ANDERS: new 0x%02x\n,priv-cfg.switch_addr); + } if (fe-ops.tuner_ops.init) fe-ops.tuner_ops.init(fe); Could you please help me out and shed some light on what the proper fix is for setting switch_addr? Thanks, /Anders -- 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: saa7134/2.6.26 regression, noisy output
An update:
hermann-pit...@arcor.de said:
hmm, the idea eventually was, to download these two snapshots, or make the
last few changes manually on the first and try on 2.6.25.
Then we might know, if the problem is already visible within Hartmut's latest
fix attempts or even more and other stuff is involved.
I wrote:
I see. I'll dig myself into hand applying those patches. It seems quite some
stuff changed between 2.6.25 and what those patches assumes. Let's see what I
dig up.
Dragging the following patch along,
diff --git a/drivers/media/video/saa7134/saa7134-cards.c
b/drivers/media/video/saa7134/saa7134-cards.c
index 6fde042..938bdf5 100644
--- a/drivers/media/video/saa7134/saa7134-cards.c
+++ b/drivers/media/video/saa7134/saa7134-cards.c
@@ -5249,7 +5249,7 @@ static int saa7134_tda8290_callback(struct saa7134_dev
*dev,
int saa7134_tuner_callback(void *priv, int command, int arg)
{
struct i2c_algo_bit_data *i2c_algo = priv;
- struct saa7134_dev *dev = i2c_algo-data;
+ struct saa7134_dev *dev = priv;
switch (dev-tuner_type) {
case TUNER_PHILIPS_TDA8290:
.. I could actually bisect my way to the offending commit. And of course, it's
the one you suspected: git 7bff4b4d3ad2b9ff42b4087f409076035af1d165.
I'm right now applying that commit piece by piece, to isolate the offending
change (Some changes are just rearrangements, others may change the way hw is
touched). I'll keep you posted.
-Anders
--
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
saa7134/2.6.26 regression, noisy output
Hi all, I've got a saa7133[0]: subsystem: 11bd:002f, board: Pinnacle PCTV 310i [card=101,autodetected] In all kernels later than 2.6.25 there is a significant layer of noise added to the video output. I've tried to bisect the problem, and it was introduced somewhere between 1fe8736955515f5075bef05c366b2d145d29cd44 (good) and 99e09eac25f752b25f65392da7bd747b77040fea (bad). Unfortunately, all commits between those two either don't compile, or oops in the v4l subsystem. I've tried the latest 30-rc and the problem is still there. Any idea how to proceed for here? I can provide screenshots on request. Here's the relevant chunk from demsg on 2.6.25: Linux video capture interface: v2.00 saa7130/34: v4l2 driver version 0.2.14 loaded saa7133[0]: found at :03:06.0, rev: 209, irq: 21, latency: 64, mmio: 0xfdeff000 saa7133[0]: subsystem: 11bd:002f, board: Pinnacle PCTV 310i [card=101,autodetected] saa7133[0]: board init: gpio is 600c000 saa7133[0]: i2c eeprom 00: bd 11 2f 00 54 20 1c 00 43 43 a9 1c 55 d2 b2 92 saa7133[0]: i2c eeprom 10: ff e0 60 06 ff 20 ff ff 00 30 8d 36 5b e2 ff ff saa7133[0]: i2c eeprom 20: 01 2c 01 23 23 01 04 30 98 ff 00 e7 ff 21 00 c2 saa7133[0]: i2c eeprom 30: 96 10 03 32 15 20 ff 15 0e 6c a3 eb 04 50 de 7d saa7133[0]: i2c eeprom 40: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff saa7133[0]: i2c eeprom 50: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff saa7133[0]: i2c eeprom 60: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff saa7133[0]: i2c eeprom 70: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff saa7133[0]: i2c eeprom 80: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff saa7133[0]: i2c eeprom 90: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff saa7133[0]: i2c eeprom a0: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff saa7133[0]: i2c eeprom b0: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff saa7133[0]: i2c eeprom c0: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff saa7133[0]: i2c eeprom d0: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff saa7133[0]: i2c eeprom e0: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff saa7133[0]: i2c eeprom f0: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff tuner' 1-004b: chip found @ 0x96 (saa7133[0]) tda8290 1-004b: setting tuner address to 61 tda8290 1-004b: type set to tda8290+75a saa7133[0]: registered device video0 [v4l2] saa7133[0]: registered device vbi0 saa7133[0]: registered device radio0 saa7134 ALSA driver for DMA sound loaded saa7133[0]/alsa: saa7133[0] at 0xfdeff000 irq 21 registered as card -1 DVB: registering new adapter (saa7133[0]) DVB: registering frontend 0 (Philips TDA10046H DVB-T)... tda1004x: setting up plls for 48MHz sampling clock tda1004x: found firmware revision 20 -- ok All help appreciated, -Anders -- 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
