| Message ID | 55B38C59.8060001@metafoo.de (mailing list archive) |
|---|---|
| State | New, archived |
| Headers | show |
On Saturday 25 July 2015 15:17:13 Lars-Peter Clausen wrote: > On 07/25/2015 12:28 PM, Pali Rohár wrote: > > Hello, > > > > sometimes after rebooting Nokia N900 initializing alsa audio fails. > > Here output from dmesg log when it happen: > > > > [ 6.925140] tpa6130a2 2-0060: Write failed > > [ 6.929534] tpa6130a2 2-0060: Failed to initialize chip > > [ 6.935272] tpa6130a2: probe of 2-0060 failed with error -121 > > [ 7.624237] rx51-audio n900-audio: Failed to add TPA6130A2 > > controls [ 7.635101] rx51-audio n900-audio: ASoC: failed to > > init TLV320AIC34: -19 [ 7.645874] rx51-audio n900-audio: ASoC: > > failed to instantiate card -19 [ 7.665740] rx51-audio > > n900-audio: snd_soc_register_card failed (-19) [ 8.063049] ALSA > > device list: > > [ 8.070343] No soundcards found. > > > > Any idea what to do? > > Looks like the chip is not responding. Try to add a small delay after > powerup to give the device to be fully ready, something like the > following: > > --- a/sound/soc/codecs/tpa6130a2.c > +++ b/sound/soc/codecs/tpa6130a2.c > @@ -152,6 +152,8 @@ static int tpa6130a2_power(u8 power) > if (data->power_gpio >= 0) > gpio_set_value(data->power_gpio, 1); > > + msleep(5); > + > data->power_state = 1; > ret = tpa6130a2_initialize(); > if (ret < 0) { Hello, your patch did not helped. Problem is still there... Now I found another problem: [ 28.102233] omap_i2c 48072000.i2c: controller timed out Anyway, if you are interested here is full dmesg log: [ 0.000000] Booting Linux on physical CPU 0x0 [ 0.000000] Initializing cgroup subsys cpu [ 0.000000] Linux version 4.2.0-rc2+ (pali@Pali-Latitude) (gcc version 4.6.3 (Ubuntu/Linaro 4.6.3-1ubuntu5) ) #368 PREEMPT Sat Aug 1 12:07:46 CEST 2015 [ 0.000000] CPU: ARMv7 Processor [411fc083] revision 3 (ARMv7), cr=10c5387d [ 0.000000] CPU: PIPT / VIPT nonaliasing data cache, VIPT nonaliasing instruction cache [ 0.000000] Machine model: Nokia N900 [ 0.000000] Memory policy: Data cache writeback [ 0.000000] On node 0 totalpages: 65280 [ 0.000000] free_area_init_node: node 0, pgdat c069a40c, node_mem_map cfcf9000 [ 0.000000] Normal zone: 512 pages used for memmap [ 0.000000] Normal zone: 0 pages reserved [ 0.000000] Normal zone: 65280 pages, LIFO batch:15 [ 0.000000] CPU: All CPU(s) started in SVC mode. [ 0.000000] OMAP3430/3530 ES3.1 (l2cache iva sgx neon isp ) [ 0.000000] pcpu-alloc: s0 r0 d32768 u32768 alloc=1*32768 [ 0.000000] pcpu-alloc: [0] 0 [ 0.000000] Built 1 zonelists in Zone order, mobility grouping on. Total pages: 64768 [ 0.000000] Kernel command line: rootdelay root=/dev/ram0 log_buf_len=20M [ 0.000000] log_buf_len: 33554432 bytes [ 0.000000] early log buf free: 64332(98%) [ 0.000000] PID hash table entries: 1024 (order: 0, 4096 bytes) [ 0.000000] Dentry cache hash table entries: 32768 (order: 5, 131072 bytes) [ 0.000000] Inode-cache hash table entries: 16384 (order: 4, 65536 bytes) [ 0.000000] Memory: 203424K/261120K available (4443K kernel code, 308K rwdata, 1720K rodata, 264K init, 266K bss, 57696K reserved, 0K cma-reserved, 0K highmem) [ 0.000000] Virtual kernel memory layout: [ 0.000000] vector : 0xffff0000 - 0xffff1000 ( 4 kB) [ 0.000000] fixmap : 0xffc00000 - 0xfff00000 (3072 kB) [ 0.000000] vmalloc : 0xd0800000 - 0xff000000 ( 744 MB) [ 0.000000] lowmem : 0xc0000000 - 0xd0000000 ( 256 MB) [ 0.000000] pkmap : 0xbfe00000 - 0xc0000000 ( 2 MB) [ 0.000000] modules : 0xbf000000 - 0xbfe00000 ( 14 MB) [ 0.000000] .text : 0xc0008000 - 0xc060d0c8 (6165 kB) [ 0.000000] .init : 0xc060e000 - 0xc0650000 ( 264 kB) [ 0.000000] .data : 0xc0650000 - 0xc069d3dc ( 309 kB) [ 0.000000] .bss : 0xc069d3dc - 0xc06dfc4c ( 267 kB) [ 0.000000] SLUB: HWalign=64, Order=0-3, MinObjects=0, CPUs=1, Nodes=1 [ 0.000000] Preemptible hierarchical RCU implementation. [ 0.000000] Build-time adjustment of leaf fanout to 32. [ 0.000000] NR_IRQS:16 nr_irqs:16 16 [ 0.000000] IRQ: Found an INTC at 0xfa200000 (revision 4.0) with 96 interrupts [ 0.000000] Clocking rate (Crystal/Core/MPU): 19.2/332/500 MHz [ 0.000000] OMAP clockevent source: timer1 at 32768 Hz [ 0.000000] clocksource: 32k_counter: mask: 0xffffffff max_cycles: 0xffffffff, max_idle_ns: 58327039986419 ns [ 0.000000] sched_clock: 32 bits at 32kHz, resolution 30517ns, wraps every 65535999984741ns [ 0.000000] OMAP clocksource: 32k_counter at 32768 Hz [ 0.000305] Console: colour dummy device 80x30 [ 0.001586] console [tty0] enabled [ 0.001647] Calibrating delay loop... 496.43 BogoMIPS (lpj=2482176) [ 0.048828] pid_max: default: 32768 minimum: 301 [ 0.048980] Security Framework initialized [ 0.049102] Mount-cache hash table entries: 1024 (order: 0, 4096 bytes) [ 0.049163] Mountpoint-cache hash table entries: 1024 (order: 0, 4096 bytes) [ 0.050354] Initializing cgroup subsys blkio [ 0.050445] Initializing cgroup subsys freezer [ 0.050567] CPU: Testing write buffer coherency: ok [ 0.051239] Setting up static identity map for 0x80008200 - 0x80008258 [ 0.054779] devtmpfs: initialized [ 0.101928] VFP support v0.3: implementor 41 architecture 3 part 30 variant c rev 1 [ 0.123107] omap_hwmod: mcbsp2_sidetone using broken dt data from mcbsp [ 0.123840] omap_hwmod: mcbsp3_sidetone using broken dt data from mcbsp [ 0.173553] clocksource: jiffies: mask: 0xffffffff max_cycles: 0xffffffff, max_idle_ns: 19112604462750000 ns [ 0.174530] pinctrl core: initialized pinctrl subsystem [ 0.176361] NET: Registered protocol family 16 [ 0.177978] DMA: preallocated 256 KiB pool for atomic coherent allocations [ 0.208465] cpuidle: using governor ladder [ 0.238403] cpuidle: using governor menu [ 0.239074] Reprogramming SDRC clock to 332000000 Hz [ 0.245819] OMAP GPIO hardware version 2.5 [ 0.252288] irq: no irq domain found for /ocp/l4@48000000/scm@2000/pinmux@30 ! [ 0.252990] irq: no irq domain found for /ocp/l4@48000000/scm@2000/pinmux@30 ! [ 0.267974] omap-gpmc 6e000000.gpmc: could not find pctldev for node /ocp/l4@48000000/scm@2000/pinmux@30/pinmux_gpmc_pins, deferring probe [ 0.272857] RX-51: Enabling ARM errata 430973 workaround [ 0.274658] RX-51: Registring OMAP3 HWRNG device [ 0.278564] hw-breakpoint: debug architecture 0x4 unsupported. [ 0.280212] Reserving DMA channels 0 and 1 for HS ROM code [ 0.280273] OMAP DMA hardware revision 4.0 [ 0.330078] omap-dma-engine 48056000.dma-controller: OMAP DMA engine driver [ 0.335510] omap-iommu 480bd400.mmu: 480bd400.mmu registered [ 0.336303] usbcore: registered new interface driver usbfs [ 0.336486] usbcore: registered new interface driver hub [ 0.336730] usbcore: registered new device driver usb [ 0.337860] omap_i2c 48070000.i2c: could not find pctldev for node /ocp/l4@48000000/scm@2000/pinmux@30/pinmux_i2c1_pins, deferring probe [ 0.338012] omap_i2c 48072000.i2c: could not find pctldev for node /ocp/l4@48000000/scm@2000/pinmux@30/pinmux_i2c2_pins, deferring probe [ 0.338226] omap_i2c 48060000.i2c: could not find pctldev for node /ocp/l4@48000000/scm@2000/pinmux@30/pinmux_i2c3_pins, deferring probe [ 0.339782] omap-mailbox 48094000.mailbox: omap mailbox rev 0x40 [ 0.340423] Advanced Linux Sound Architecture Driver Initialized. [ 0.341979] clocksource: Switched to clocksource 32k_counter [ 0.383239] NET: Registered protocol family 2 [ 0.384521] TCP established hash table entries: 2048 (order: 1, 8192 bytes) [ 0.384643] TCP bind hash table entries: 2048 (order: 1, 8192 bytes) [ 0.384735] TCP: Hash tables configured (established 2048 bind 2048) [ 0.384948] UDP hash table entries: 256 (order: 0, 4096 bytes) [ 0.385009] UDP-Lite hash table entries: 256 (order: 0, 4096 bytes) [ 0.385314] NET: Registered protocol family 1 [ 0.385864] Trying to unpack rootfs image as initramfs... [ 0.386383] rootfs image is not initramfs (junk in compressed archive); looks like an initrd [ 0.518432] Freeing initrd memory: 15240K (ce900000 - cf7e2000) [ 0.519073] hw perfevents: Failed to parse /pmu/interrupt-affinity[0] [ 0.519226] hw perfevents: enabled with armv7_cortex_a8 PMU driver, 5 counters available [ 0.523986] futex hash table entries: 256 (order: -1, 3072 bytes) [ 0.541168] VFS: Disk quotas dquot_6.6.0 [ 0.541687] VFS: Dquot-cache hash table entries: 1024 (order 0, 4096 bytes) [ 0.544769] io scheduler noop registered [ 0.545288] io scheduler cfq registered (default) [ 0.546813] pinctrl-single 48002030.pinmux: 284 pins at pa fa002030 size 568 [ 0.547302] pinctrl-single 48002a00.pinmux: 46 pins at pa fa002a00 size 92 [ 0.548004] pinctrl-single 480025d8.pinmux: 18 pins at pa fa0025d8 size 36 [ 0.550445] 48050000.dss supply vdda_video not found, using dummy regulator [ 0.550781] OMAP DSS rev 2.0 [ 0.551452] omapdss_dss 48050000.dss: bound 48050400.dispc (ops dispc_component_ops) [ 0.551910] omapdss_dss 48050000.dss: bound 48050c00.encoder (ops venc_component_ops) [ 0.553375] omapfb omapfb: no displays [ 0.553588] omapfb omapfb: failed to setup omapfb [ 0.554199] Serial: 8250/16550 driver, 4 ports, IRQ sharing disabled [ 0.557464] 4806c000.serial: ttyO1 at MMIO 0x4806c000 (irq = 89, base_baud = 3000000) is a OMAP UART1 [ 0.558685] 49020000.serial: ttyO2 at MMIO 0x49020000 (irq = 90, base_baud = 3000000) is a OMAP UART2 [ 0.560394] omap3_rom_rng: initializing [ 0.586517] brd: module loaded [ 0.596771] loop: module loaded [ 0.598266] mtdoops: mtd device (mtddev=name/number) must be supplied [ 0.611114] acx565akm spi1.2: omapfb: acx565akm rev ad LCD detected [ 0.615112] HS USB OTG: no transceiver configured [ 0.615203] musb-hdrc musb-hdrc.0.auto: musb_init_controller failed with status -517 [ 0.616577] i2c /dev entries driver [ 0.618164] omap_hsmmc 4809c000.mmc: unable to get vmmc regulator -517 [ 0.643157] omap_hsmmc 480b4000.mmc: unable to get vmmc regulator -517 [ 0.675903] rx51-audio n900-audio: could not get speaker enable gpio [ 0.676788] Initializing XFRM netlink socket [ 0.676940] NET: Registered protocol family 17 [ 0.677062] NET: Registered protocol family 15 [ 0.677185] NET: Registered protocol family 35 [ 0.677429] Key type dns_resolver registered [ 0.677734] omap2_set_init_voltage: unable to find boot up OPP for vdd_mpu_iva [ 0.677825] omap2_set_init_voltage: unable to set vdd_mpu_iva [ 0.677886] omap2_set_init_voltage: unable to find boot up OPP for vdd_core [ 0.677947] omap2_set_init_voltage: unable to set vdd_core [ 0.682861] ThumbEE CPU extension supported. [ 0.682952] SmartReflex Class3 initialized [ 0.689971] registered taskstats version 1 [ 0.692565] omap-gpmc 6e000000.gpmc: GPMC revision 5.0 [ 0.692657] gpmc_mem_init: disabling cs 0 mapped at 0x0-0x1000000 [ 0.693359] omap2-onenand omap2-onenand: initializing on CS0, phys base 0x01000000, virtual base d0940000, freq 66 MHz [ 0.693450] OneNAND Manufacturer: Samsung (0xec) [ 0.693481] Muxed OneNAND 256MB 1.8V 16-bit (0x40) [ 0.693542] OneNAND version = 0x0121 [ 0.693572] Chip support all block unlock [ 0.693572] Chip has 2 plane [ 0.695281] Scanning device for bad blocks [ 0.795776] 6 ofpart partitions found on MTD device omap2-onenand [ 0.795837] Creating 6 MTD partitions on "omap2-onenand": [ 0.795898] 0x000000000000-0x000000020000 : "bootloader" [ 0.796783] 0x000000020000-0x000000080000 : "config" [ 0.797637] 0x000000080000-0x0000000c0000 : "log" [ 0.798370] 0x0000000c0000-0x0000002c0000 : "kernel" [ 0.799133] 0x0000002c0000-0x0000004c0000 : "initfs" [ 0.799896] 0x0000004c0000-0x000010000000 : "rootfs" [ 1.102752] twl 1-0048: PIH (irq 23) chaining IRQs 340..348 [ 1.102966] twl 1-0048: power (irq 345) chaining IRQs 348..355 [ 1.662963] twl4030_gpio twl4030-gpio: gpio (irq 340) chaining IRQs 356..373 [ 1.922668] twl4030_usb 48070000.i2c:twl@48:twl4030-usb: Initialized TWL4030 USB module [ 1.925415] input: twl4030_pwrbutton as /devices/platform/68000000.ocp/48070000.i2c/i2c-1/1-0048/48070000.i2c:twl@48:pwrbutton/input/input0 [ 1.927185] input: TWL4030 Keypad as /devices/platform/68000000.ocp/48070000.i2c/i2c-1/1-0048/48070000.i2c:twl@48:keypad/input/input1 [ 5.942382] omap_i2c 48070000.i2c: bus 1 rev3.3 at 2200 kHz [ 5.962585] tpa6130a2 2-0060: Write failed [ 5.962707] tpa6130a2 2-0060: Failed to initialize chip [ 5.962860] tpa6130a2: probe of 2-0060 failed with error -121 [ 5.963439] omap_i2c 48072000.i2c: bus 2 rev3.3 at 100 kHz [ 5.965820] omap_i2c 48060000.i2c: bus 3 rev3.3 at 400 kHz [ 5.992004] Console: switching to colour frame buffer device 100x30 [ 6.072662] omapfb omapfb: using display 'lcd' mode 800x480 [ 6.273071] musb-hdrc: ConfigData=0xde (UTMI-8, dyn FIFOs, bulk combine, bulk split, HB-ISO Rx, HB-ISO Tx, SoftConn) [ 6.273101] musb-hdrc: MHDRC RTL version 1.400 [ 6.273132] musb-hdrc: setup fifo_mode 4 [ 6.273162] musb-hdrc: 28/31 max ep, 16384/16384 memory [ 6.574035] rx51-audio n900-audio: Failed to add TPA6130A2 controls [ 6.580657] rx51-audio n900-audio: ASoC: failed to init TLV320AIC34: -19 [ 6.587554] rx51-audio n900-audio: ASoC: failed to instantiate card -19 [ 6.594146] gpiod_unexport: invalid GPIO [ 6.600555] rx51-audio n900-audio: snd_soc_register_card failed (-19) [ 6.623199] hctosys: unable to open rtc device (rtc0) [ 6.629699] sr_init: No PMIC hook to init smartreflex [ 6.637237] using random self ethernet address [ 6.643829] using random host ethernet address [ 6.650268] Number of LUNs=8 [ 6.657165] smartreflex smartreflex.0: omap_sr_probe: SmartReflex driver initialized [ 6.664276] Mass Storage Function, version: 2009/09/11 [ 6.671386] LUN: removable file: (no medium) [ 6.678833] smartreflex smartreflex.1: omap_sr_probe: SmartReflex driver initialized [ 6.692260] Number of LUNs=2 [ 6.699798] LUN: removable file: (no medium) [ 6.719238] VCSI: disabling [ 6.726684] LUN: removable file: (no medium) [ 6.733795] Number of LUNs=2 [ 6.741546] g_nokia gadget: USB CDC Phonet function [ 6.748138] g_nokia gadget: using musb-hdrc, OUT ep1out, IN ep1in [ 6.755035] ALSA device list: [ 6.761291] No soundcards found. [ 6.768676] usb0: HOST MAC 52:35:2b:7b:77:0e [ 6.775085] usb0: MAC 32:e8:ee:88:a4:58 [ 6.782043] RAMDISK: cramfs filesystem found at block 0 [ 6.788543] RAMDISK: Loading 15240KiB [1 disk] into ram disk... / [ 6.792358] g_nokia gadget: USB CDC Phonet function [ 6.804992] - [ 6.822235] g_nokia gadget: using musb-hdrc, OUT ep1out, IN ep1in [ 6.834808] \ [ 6.852539] g_nokia gadget: N900 (PC-Suite Mode) [ 6.865417] / [ 6.872253] g_nokia gadget: g_nokia ready [ 6.885009] done. [ 7.333801] VFS: Mounted root (cramfs filesystem) readonly on device 1:0. [ 7.340911] Freeing unused kernel memory: 264K (c060e000 - c0650000) [ 7.621368] g_nokia gadget: high-speed config #1: Bus Powered [ 7.681365] omap_wdt: OMAP Watchdog Timer Rev 0x31: initial timeout 60 sec [ 13.258148] omap-sham 480c3000.sham: hw accel on OMAP rev 0.9 [ 13.333465] input: TSC2005 touchscreen as /devices/platform/68000000.ocp/48098000.spi/spi_master/spi1/spi1.0/input/input2 [ 15.720733] input: twl4030:vibrator as /devices/platform/68000000.ocp/48070000.i2c/i2c-1/1-0048/48070000.i2c:twl@48:audio/input/input3 [ 23.654785] media: Linux media interface: v0.10 [ 25.393402] tsl2563 2-0029: model 7, rev. 0 [ 25.772796] Linux video capture interface: v2.00 [ 28.102233] omap_i2c 48072000.i2c: controller timed out [ 29.463653] lp5523x 2-0032: lp5523 Programmable led chip found [ 30.734191] omap_i2c 48072000.i2c: controller timed out waiting for start condition to finish [ 32.142333] i2c i2c-2: SCL is stuck low, exit recovery [ 33.162322] i2c i2c-2: SCL is stuck low, exit recovery [ 34.462249] i2c i2c-2: SCL is stuck low, exit recovery [ 35.482299] i2c i2c-2: SCL is stuck low, exit recovery [ 36.862762] omap_ssi 48058000.ssi-controller: ssi controller 0 initialized (1 ports)! [ 37.113800] smc91x: not found (-19). [ 37.132263] i2c i2c-2: SCL is stuck low, exit recovery [ 38.962341] i2c i2c-2: SCL is stuck low, exit recovery [ 39.122406] twl_rtc 48070000.i2c:twl@48:rtc: Enabling TWL-RTC [ 39.233428] twl_rtc 48070000.i2c:twl@48:rtc: rtc core: registered 48070000.i2c:twl@48 as rtc0 [ 39.972198] i2c i2c-2: SCL is stuck low, exit recovery [ 40.992309] i2c i2c-2: SCL is stuck low, exit recovery [ 42.050415] i2c i2c-2: SCL is stuck low, exit recovery [ 43.062316] i2c i2c-2: SCL is stuck low, exit recovery [ 44.072235] i2c i2c-2: SCL is stuck low, exit recovery [ 44.072265] si4713 2-0063: Error while sending command 0x01 [ 45.092224] i2c i2c-2: SCL is stuck low, exit recovery [ 45.092254] si4713 2-0063: Error while sending command 0x10 [ 45.092285] si4713 2-0063: Failed to probe device information. [ 45.092620] si4713: probe of 2-0063 failed with error -16 [ 45.094757] bq27x00-battery 2-0055: support ver. 1.2.0 enabled [ 45.364929] Bluetooth: Core ver 2.20 [ 45.365356] NET: Registered protocol family 31 [ 45.365356] Bluetooth: HCI device and connection manager initialized [ 45.365386] Bluetooth: HCI socket layer initialized [ 45.365417] Bluetooth: L2CAP socket layer initialized [ 45.365478] Bluetooth: SCO socket layer initialized [ 46.102386] i2c i2c-2: SCL is stuck low, exit recovery [ 47.122344] i2c i2c-2: SCL is stuck low, exit recovery [ 48.212310] i2c i2c-2: SCL is stuck low, exit recovery [ 48.342651] lis3lv02d: 8 bits sensor found [ 48.473175] input: ST LIS3LV02DL Accelerometer as /devices/platform/lis3lv02d/input/input4 [ 49.402313] i2c i2c-2: SCL is stuck low, exit recovery [ 50.422302] i2c i2c-2: SCL is stuck low, exit recovery [ 51.442291] i2c i2c-2: SCL is stuck low, exit recovery [ 52.462219] i2c i2c-2: SCL is stuck low, exit recovery [ 53.668853] i2c i2c-2: SCL is stuck low, exit recovery [ 54.682312] i2c i2c-2: SCL is stuck low, exit recovery [ 54.882263] random: nonblocking pool is initialized [ 55.692291] i2c i2c-2: SCL is stuck low, exit recovery [ 56.220550] isp1704_charger isp1704: init gpio 67 [ 56.342437] isp1704_charger isp1704: registered with product id isp1707 [ 56.702209] i2c i2c-2: SCL is stuck low, exit recovery [ 57.674682] g_nokia gadget: high-speed config #1: Bus Powered [ 57.823730] i2c i2c-2: SCL is stuck low, exit recovery [ 59.412292] i2c i2c-2: SCL is stuck low, exit recovery [ 59.412322] bq2415x-charger 2-006b: failed to set default values: -16 [ 89.415588] cfg80211: Calling CRDA to update world regulatory domain [ 93.862243] cfg80211: Calling CRDA to update world regulatory domain [ 97.128662] cfg80211: Calling CRDA to update world regulatory domain [ 100.392242] cfg80211: Calling CRDA to update world regulatory domain [ 104.742370] cfg80211: Calling CRDA to update world regulatory domain [ 105.832824] ieee80211 phy0: Selected rate control algorithm 'minstrel_ht' [ 105.873840] wl1251: loaded [ 107.223327] wl1251: initialized [ 108.932312] cfg80211: Calling CRDA to update world regulatory domain [ 113.012298] cfg80211: Calling CRDA to update world regulatory domain [ 117.022308] cfg80211: Calling CRDA to update world regulatory domain [ 120.962310] cfg80211: Calling CRDA to update world regulatory domain [ 124.192291] cfg80211: Calling CRDA to update world regulatory domain [ 127.362243] cfg80211: Calling CRDA to update world regulatory domain [ 131.712249] cfg80211: Exceeded CRDA call max attempts. Not calling CRDA
Hi On 08/01/2015 01:18 PM, Pali Rohár wrote: > On Saturday 25 July 2015 15:17:13 Lars-Peter Clausen wrote: >> On 07/25/2015 12:28 PM, Pali Rohár wrote: >>> Hello, >>> >>> sometimes after rebooting Nokia N900 initializing alsa audio fails. >>> Here output from dmesg log when it happen: >>> >>> [ 6.925140] tpa6130a2 2-0060: Write failed >>> [ 6.929534] tpa6130a2 2-0060: Failed to initialize chip >>> [ 6.935272] tpa6130a2: probe of 2-0060 failed with error -121 >>> [ 7.624237] rx51-audio n900-audio: Failed to add TPA6130A2 >>> controls [ 7.635101] rx51-audio n900-audio: ASoC: failed to >>> init TLV320AIC34: -19 [ 7.645874] rx51-audio n900-audio: ASoC: >>> failed to instantiate card -19 [ 7.665740] rx51-audio >>> n900-audio: snd_soc_register_card failed (-19) [ 8.063049] ALSA >>> device list: >>> [ 8.070343] No soundcards found. >>> >>> Any idea what to do? >> >> Looks like the chip is not responding. Try to add a small delay after >> powerup to give the device to be fully ready, something like the >> following: >> >> --- a/sound/soc/codecs/tpa6130a2.c >> +++ b/sound/soc/codecs/tpa6130a2.c >> @@ -152,6 +152,8 @@ static int tpa6130a2_power(u8 power) >> if (data->power_gpio >= 0) >> gpio_set_value(data->power_gpio, 1); >> >> + msleep(5); >> + >> data->power_state = 1; >> ret = tpa6130a2_initialize(); >> if (ret < 0) { > > > Hello, your patch did not helped. Problem is still there... > For me v4.2-rc5 works, i.e. TPA6130A2 can still play loudly to headphones. Don't know were there any i2c etc regression before it or how easy it would be to reproduce. Logs below made me thinking can it be a HW issue? Although if it is an HW issue it shouldn't work sometimes I guess. Do you have any earlier well known configuration you could try is it an SW regression or something else? > [ 5.962585] tpa6130a2 2-0060: Write failed > [ 5.962707] tpa6130a2 2-0060: Failed to initialize chip > [ 5.962860] tpa6130a2: probe of 2-0060 failed with error -121 -121 == EREMOTEIO which is returned from i2c-omap.c when there is no ACK from the chip. > [ 28.102233] omap_i2c 48072000.i2c: controller timed out > [ 29.463653] lp5523x 2-0032: lp5523 Programmable led chip found > [ 30.734191] omap_i2c 48072000.i2c: controller timed out waiting for start condition to finish > [ 32.142333] i2c i2c-2: SCL is stuck low, exit recovery If SCL is really stuck it also explains why chip doesn't acknowledge.
On Monday 03 August 2015 20:03:16 Jarkko Nikula wrote: > Hi > > On 08/01/2015 01:18 PM, Pali Rohár wrote: > > On Saturday 25 July 2015 15:17:13 Lars-Peter Clausen wrote: > >> On 07/25/2015 12:28 PM, Pali Rohár wrote: > >>> Hello, > >>> > >>> sometimes after rebooting Nokia N900 initializing alsa audio > >>> fails. Here output from dmesg log when it happen: > >>> > >>> [ 6.925140] tpa6130a2 2-0060: Write failed > >>> [ 6.929534] tpa6130a2 2-0060: Failed to initialize chip > >>> [ 6.935272] tpa6130a2: probe of 2-0060 failed with error -121 > >>> [ 7.624237] rx51-audio n900-audio: Failed to add TPA6130A2 > >>> controls [ 7.635101] rx51-audio n900-audio: ASoC: failed to > >>> init TLV320AIC34: -19 [ 7.645874] rx51-audio n900-audio: ASoC: > >>> failed to instantiate card -19 [ 7.665740] rx51-audio > >>> n900-audio: snd_soc_register_card failed (-19) [ 8.063049] > >>> ALSA device list: > >>> [ 8.070343] No soundcards found. > >>> > >>> Any idea what to do? > >> > >> Looks like the chip is not responding. Try to add a small delay > >> after powerup to give the device to be fully ready, something > >> like the following: > >> > >> --- a/sound/soc/codecs/tpa6130a2.c > >> +++ b/sound/soc/codecs/tpa6130a2.c > >> @@ -152,6 +152,8 @@ static int tpa6130a2_power(u8 power) > >> > >> if (data->power_gpio >= 0) > >> > >> gpio_set_value(data->power_gpio, 1); > >> > >> + msleep(5); > >> + > >> > >> data->power_state = 1; > >> ret = tpa6130a2_initialize(); > >> if (ret < 0) { > > > > Hello, your patch did not helped. Problem is still there... > > For me v4.2-rc5 works, i.e. TPA6130A2 can still play loudly to > headphones. Don't know were there any i2c etc regression before it or > how easy it would be to reproduce. > Did you tested it on Nokia N900? Or other device? > Logs below made me thinking can it be a HW issue? Although if it is > an HW issue it shouldn't work sometimes I guess. Do you have any > earlier well known configuration you could try is it an SW > regression or something else? > Stock Nokia's 2.6.28 kernel works always. With that kernel I have never seen this problem. So I do not think this is HW problem. This problem is there in more kernel versions, maybe in some older (like v3.5) is was there not so often. But do not remember correctly... > > [ 5.962585] tpa6130a2 2-0060: Write failed > > [ 5.962707] tpa6130a2 2-0060: Failed to initialize chip > > [ 5.962860] tpa6130a2: probe of 2-0060 failed with error -121 > > -121 == EREMOTEIO which is returned from i2c-omap.c when there is no > ACK from the chip. > Maybe some power management problem? Something is not always initialized correctly? I remember that there is some problem (maybe in NoLo - Nokia bootloader) that sometimes chainloaded U-Boot (booted via NoLo) is not able to initialize mmc chip (all read operation fails). In U-Boot I added some code to enable some parts in twl4030 regulator and after that mmc is working always... So maybe something similar? Kernel expects that some PM or regulator parts are initialized, but they are only sometimes? Just speculation... > > [ 28.102233] omap_i2c 48072000.i2c: controller timed out > > [ 29.463653] lp5523x 2-0032: lp5523 Programmable led chip found > > [ 30.734191] omap_i2c 48072000.i2c: controller timed out waiting > > for start condition to finish [ 32.142333] i2c i2c-2: SCL is > > stuck low, exit recovery > > If SCL is really stuck it also explains why chip doesn't acknowledge.
On 08/03/2015 09:17 PM, Pali Rohár wrote: > On Monday 03 August 2015 20:03:16 Jarkko Nikula wrote: >> Hi >> >> On 08/01/2015 01:18 PM, Pali Rohár wrote: >>> On Saturday 25 July 2015 15:17:13 Lars-Peter Clausen wrote: >>> Hello, your patch did not helped. Problem is still there... >> >> For me v4.2-rc5 works, i.e. TPA6130A2 can still play loudly to >> headphones. Don't know were there any i2c etc regression before it or >> how easy it would be to reproduce. >> > > Did you tested it on Nokia N900? Or other device? > N900. Seems to be only user of TPA6130A2 in mainline :-) >> Logs below made me thinking can it be a HW issue? Although if it is >> an HW issue it shouldn't work sometimes I guess. Do you have any >> earlier well known configuration you could try is it an SW >> regression or something else? >> > > Stock Nokia's 2.6.28 kernel works always. With that kernel I have never > seen this problem. So I do not think this is HW problem. > > This problem is there in more kernel versions, maybe in some older (like > v3.5) is was there not so often. But do not remember correctly... > It is well possible that some regression got introduced to TPA6130A2 I2C communication over the years without nobody than you now notices. We used to do QA back in Meego N900 days but that was pre 3.x kernels. > Maybe some power management problem? Something is not always initialized > correctly? > > I remember that there is some problem (maybe in NoLo - Nokia bootloader) > that sometimes chainloaded U-Boot (booted via NoLo) is not able to > initialize mmc chip (all read operation fails). In U-Boot I added some > code to enable some parts in twl4030 regulator and after that mmc is > working always... > > So maybe something similar? Kernel expects that some PM or regulator > parts are initialized, but they are only sometimes? Just speculation... > I'm thinking the same. I could figure SCL could be stuck low if TPA or some other chip connected to the same I2C bus is without power and is pulling I2C signals down.
On Monday 03 August 2015 20:48:28 Jarkko Nikula wrote: > On 08/03/2015 09:17 PM, Pali Rohár wrote: > > On Monday 03 August 2015 20:03:16 Jarkko Nikula wrote: > >> Hi > >> > >> On 08/01/2015 01:18 PM, Pali Rohár wrote: > >>> On Saturday 25 July 2015 15:17:13 Lars-Peter Clausen wrote: > >>> Hello, your patch did not helped. Problem is still there... > >> > >> For me v4.2-rc5 works, i.e. TPA6130A2 can still play loudly to > >> headphones. Don't know were there any i2c etc regression before it > >> or how easy it would be to reproduce. > > > > Did you tested it on Nokia N900? Or other device? > > N900. Seems to be only user of TPA6130A2 in mainline :-) > Great, can you do more tests? I get this error often after I reboot N900 (without power off) more times. But no idea if this is just "sometimes". > >> Logs below made me thinking can it be a HW issue? Although if it > >> is an HW issue it shouldn't work sometimes I guess. Do you have > >> any earlier well known configuration you could try is it an SW > >> regression or something else? > > > > Stock Nokia's 2.6.28 kernel works always. With that kernel I have > > never seen this problem. So I do not think this is HW problem. > > > > This problem is there in more kernel versions, maybe in some older > > (like v3.5) is was there not so often. But do not remember > > correctly... > > It is well possible that some regression got introduced to TPA6130A2 > I2C communication over the years without nobody than you now > notices. We used to do QA back in Meego N900 days but that was pre > 3.x kernels. > Do you still have these pre 3.x kernels? This could be good starting point as 2.6.28 kernel is tooo old and heavily patches... > > Maybe some power management problem? Something is not always > > initialized correctly? > > > > I remember that there is some problem (maybe in NoLo - Nokia > > bootloader) that sometimes chainloaded U-Boot (booted via NoLo) is > > not able to initialize mmc chip (all read operation fails). In > > U-Boot I added some code to enable some parts in twl4030 regulator > > and after that mmc is working always... > > > > So maybe something similar? Kernel expects that some PM or > > regulator parts are initialized, but they are only sometimes? Just > > speculation... > > I'm thinking the same. I could figure SCL could be stuck low if TPA > or some other chip connected to the same I2C bus is without power > and is pulling I2C signals down. We should know which devices are connected to which i2c bus. So maybe detecting which i2c device is incorrectly initialized?
On 08/03/2015 09:48 PM, Jarkko Nikula wrote: > It is well possible that some regression got introduced to TPA6130A2 I2C > communication over the years without nobody than you now notices. We > used to do QA back in Meego N900 days but that was pre 3.x kernels. No major changes has been done to the tpa driver during the past years... I wanted to do some updates, like moving it to regmap, but as you said, n900 is the only user (and n9) and I do not feel comfortable to hack on a device where I do not have serial console... And I'm using the n900 time to time also. >> So maybe something similar? Kernel expects that some PM or regulator >> parts are initialized, but they are only sometimes? Just speculation... >> > I'm thinking the same. I could figure SCL could be stuck low if TPA or > some other chip connected to the same I2C bus is without power and is > pulling I2C signals down. What would happen with the SCL stuck on i2c.2 bus if you remove the tpa driver from the kernel? If you remove the other drivers for the devices on i2c.2?
Hi! > Maybe some power management problem? Something is not always initialized > correctly? > > I remember that there is some problem (maybe in NoLo - Nokia bootloader) > that sometimes chainloaded U-Boot (booted via NoLo) is not able to > initialize mmc chip (all read operation fails). In U-Boot I added some > code to enable some parts in twl4030 regulator and after that mmc is > working always... Could I get some details? Thay code should be moved to kernel, I'd really like mmc to work, no matter how machine was booted. Best regards, Pavel
On Friday 14 August 2015 22:46:49 Pavel Machek wrote: > Hi! > > > Maybe some power management problem? Something is not always > > initialized correctly? > > > > I remember that there is some problem (maybe in NoLo - Nokia > > bootloader) that sometimes chainloaded U-Boot (booted via NoLo) is > > not able to initialize mmc chip (all read operation fails). In > > U-Boot I added some code to enable some parts in twl4030 regulator > > and after that mmc is working always... > > Could I get some details? Thay code should be moved to kernel, > I'd really like mmc to work, no matter how machine was booted. > > Best regards, > > Pavel I think I was inspirited by kernel code when I added that functionality into u-boot... But I do not remember which kernel version... If you are interested and what to play with that, just look at few lines of twl4030 code in uboot rx51.c (until "restore I2C access state"): http://git.denx.de/?p=u-boot.git;a=blob;f=board/nokia/rx51/rx51.c;h=3d019b01428b5392fb5d0b8c7428a6d1d2ba31af;hb=HEAD#l388 All are just i2c calls to twl4030 chipset.
On Tuesday 04 August 2015 09:02:39 Peter Ujfalusi wrote: > On 08/03/2015 09:48 PM, Jarkko Nikula wrote: > > It is well possible that some regression got introduced to > > TPA6130A2 I2C communication over the years without nobody than you > > now notices. We used to do QA back in Meego N900 days but that was > > pre 3.x kernels. > > No major changes has been done to the tpa driver during the past > years... I wanted to do some updates, like moving it to regmap, but > as you said, n900 is the only user (and n9) and I do not feel > comfortable to hack on a device where I do not have serial > console... And I'm using the n900 time to time also. > > >> So maybe something similar? Kernel expects that some PM or > >> regulator parts are initialized, but they are only sometimes? > >> Just speculation... > > > > I'm thinking the same. I could figure SCL could be stuck low if TPA > > or some other chip connected to the same I2C bus is without power > > and is pulling I2C signals down. > > What would happen with the SCL stuck on i2c.2 bus if you remove the > tpa driver from the kernel? If you remove the other drivers for the > devices on i2c.2? Hi Peter and Jarkko! Do you have some code samples for testing? Or something else which I can test? This problem is still reproducible on more N900 devices and I would like to see it fixed.
Hi Pali, On Tue, Jan 05, 2016 at 12:34:12AM +0100, Pali Rohár wrote: > On Tuesday 04 August 2015 09:02:39 Peter Ujfalusi wrote: > > On 08/03/2015 09:48 PM, Jarkko Nikula wrote: > > > It is well possible that some regression got introduced to > > > TPA6130A2 I2C communication over the years without nobody than you > > > now notices. We used to do QA back in Meego N900 days but that was > > > pre 3.x kernels. > > > > No major changes has been done to the tpa driver during the past > > years... I wanted to do some updates, like moving it to regmap, but > > as you said, n900 is the only user (and n9) and I do not feel > > comfortable to hack on a device where I do not have serial > > console... And I'm using the n900 time to time also. > > > > >> So maybe something similar? Kernel expects that some PM or > > >> regulator parts are initialized, but they are only sometimes? > > >> Just speculation... > > > > > > I'm thinking the same. I could figure SCL could be stuck low if TPA > > > or some other chip connected to the same I2C bus is without power > > > and is pulling I2C signals down. > > > > What would happen with the SCL stuck on i2c.2 bus if you remove the > > tpa driver from the kernel? If you remove the other drivers for the > > devices on i2c.2? > > Hi Peter and Jarkko! Do you have some code samples for testing? Or > something else which I can test? This problem is still reproducible on > more N900 devices and I would like to see it fixed. I have not seen your error with N900, but while working on N950 I noticed similar problems when I added lp5523. I think the lp5523 reset routine locks up the omap i2c controller, since the lp5523 will stop responding in the middle of an ongoing communication: static void lp55xx_reset_device(struct lp55xx_chip *chip) { struct lp55xx_device_config *cfg = chip->cfg; u8 addr = cfg->reset.addr; u8 val = cfg->reset.val; /* no error checking here because no ACK from the device after reset */ lp55xx_write(chip, addr, val); } Since tpa6130a2 is on the same i2c bus, it would be affected by this. You can check this by just commenting out the call to lp55xx_reset_device() in the probe function, since it's not needed on N900 (chip reset is done via enable gpio anyways). I'm pretty sure, there were no bus lock problems when I added lp5523 to N900 dts, so this having problems with this is probably a regression in the omap-i2c driver. -- Sebastian
On Sunday 06 March 2016 16:23:39 Sebastian Reichel wrote: > Hi Pali, > > On Tue, Jan 05, 2016 at 12:34:12AM +0100, Pali Rohár wrote: > > On Tuesday 04 August 2015 09:02:39 Peter Ujfalusi wrote: > > > On 08/03/2015 09:48 PM, Jarkko Nikula wrote: > > > > It is well possible that some regression got introduced to > > > > TPA6130A2 I2C communication over the years without nobody than you > > > > now notices. We used to do QA back in Meego N900 days but that was > > > > pre 3.x kernels. > > > > > > No major changes has been done to the tpa driver during the past > > > years... I wanted to do some updates, like moving it to regmap, but > > > as you said, n900 is the only user (and n9) and I do not feel > > > comfortable to hack on a device where I do not have serial > > > console... And I'm using the n900 time to time also. > > > > > > >> So maybe something similar? Kernel expects that some PM or > > > >> regulator parts are initialized, but they are only sometimes? > > > >> Just speculation... > > > > > > > > I'm thinking the same. I could figure SCL could be stuck low if TPA > > > > or some other chip connected to the same I2C bus is without power > > > > and is pulling I2C signals down. > > > > > > What would happen with the SCL stuck on i2c.2 bus if you remove the > > > tpa driver from the kernel? If you remove the other drivers for the > > > devices on i2c.2? > > > > Hi Peter and Jarkko! Do you have some code samples for testing? Or > > something else which I can test? This problem is still reproducible on > > more N900 devices and I would like to see it fixed. > > I have not seen your error with N900, but while working on N950 I > noticed similar problems when I added lp5523. I think the lp5523 > reset routine locks up the omap i2c controller, since the lp5523 > will stop responding in the middle of an ongoing communication: > > static void lp55xx_reset_device(struct lp55xx_chip *chip) > { > struct lp55xx_device_config *cfg = chip->cfg; > u8 addr = cfg->reset.addr; > u8 val = cfg->reset.val; > > /* no error checking here because no ACK from the device after reset */ > lp55xx_write(chip, addr, val); > } > > Since tpa6130a2 is on the same i2c bus, it would be affected by > this. You can check this by just commenting out the call to > lp55xx_reset_device() in the probe function, since it's not > needed on N900 (chip reset is done via enable gpio anyways). > > I'm pretty sure, there were no bus lock problems when I added > lp5523 to N900 dts, so this having problems with this is probably > a regression in the omap-i2c driver. > > -- Sebastian Hi Sebastian! Thank you for info. That error occurs randomly, not always. When I see it next time, I will try to comment that function if it happens...
Hi, On 7.03.2016 13:59, Pali Rohár wrote: > > ... That error occurs randomly, not > always. When I see it next time, I will try to comment that function if > it happens... > IIRC it is easier to cause it by booting to stock kernel first and then rebooting to mainline (without power-down in between) Ivo -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
On Tuesday 08 March 2016 07:45:32 Ivaylo Dimitrov wrote: > Hi, > > On 7.03.2016 13:59, Pali Rohár wrote: > > ... That error occurs randomly, not > > always. When I see it next time, I will try to comment that > > function if it happens... > > IIRC it is easier to cause it by booting to stock kernel first and > then rebooting to mainline (without power-down in between) You are right, I'm getting it maybe always when I reboot from Nokia stock kernel to upstream...
On Sunday 06 March 2016 16:23:39 Sebastian Reichel wrote: > Hi Pali, > > On Tue, Jan 05, 2016 at 12:34:12AM +0100, Pali Rohár wrote: > > On Tuesday 04 August 2015 09:02:39 Peter Ujfalusi wrote: > > > On 08/03/2015 09:48 PM, Jarkko Nikula wrote: > > > > It is well possible that some regression got introduced to > > > > TPA6130A2 I2C communication over the years without nobody than > > > > you now notices. We used to do QA back in Meego N900 days but > > > > that was pre 3.x kernels. > > > > > > No major changes has been done to the tpa driver during the past > > > years... I wanted to do some updates, like moving it to regmap, > > > but as you said, n900 is the only user (and n9) and I do not > > > feel comfortable to hack on a device where I do not have serial > > > console... And I'm using the n900 time to time also. > > > > > > >> So maybe something similar? Kernel expects that some PM or > > > >> regulator parts are initialized, but they are only sometimes? > > > >> Just speculation... > > > > > > > > I'm thinking the same. I could figure SCL could be stuck low if > > > > TPA or some other chip connected to the same I2C bus is > > > > without power and is pulling I2C signals down. > > > > > > What would happen with the SCL stuck on i2c.2 bus if you remove > > > the tpa driver from the kernel? If you remove the other drivers > > > for the devices on i2c.2? > > > > Hi Peter and Jarkko! Do you have some code samples for testing? Or > > something else which I can test? This problem is still reproducible > > on more N900 devices and I would like to see it fixed. > > I have not seen your error with N900, but while working on N950 I > noticed similar problems when I added lp5523. I think the lp5523 > reset routine locks up the omap i2c controller, since the lp5523 > will stop responding in the middle of an ongoing communication: > > static void lp55xx_reset_device(struct lp55xx_chip *chip) > { > struct lp55xx_device_config *cfg = chip->cfg; > u8 addr = cfg->reset.addr; > u8 val = cfg->reset.val; > > /* no error checking here because no ACK from the device after reset > */ lp55xx_write(chip, addr, val); > } > > Since tpa6130a2 is on the same i2c bus, it would be affected by > this. You can check this by just commenting out the call to > lp55xx_reset_device() in the probe function, since it's not > needed on N900 (chip reset is done via enable gpio anyways). > > I'm pretty sure, there were no bus lock problems when I added > lp5523 to N900 dts, so this having problems with this is probably > a regression in the omap-i2c driver. > > -- Sebastian Hi Sebastian! Commenting calling lp55xx_reset_device function did not helped. Still getting that error. Tony, Peter, Jarkko: can you reproduce this problem? I'm really stucked here... do not know where is problem or how to fix it. What we know that it happens when rebooting from stock Nokia kernel (2.6.28) to upstream.
On 2016-03-12 14:42, Pali Rohár wrote: > Hi Sebastian! Commenting calling lp55xx_reset_device function did not > helped. Still getting that error. > > Tony, Peter, Jarkko: can you reproduce this problem? I'm really stucked > here... do not know where is problem or how to fix it. What we know that > it happens when rebooting from stock Nokia kernel (2.6.28) to upstream. I'm sorry, but I can not debug my n900 as I rely on it as primary phone time-to-time. I would try to disable one by one the drivers for devices on the i2c_2 bus in the stock kernel and see if this will point to something. It might worth looking at the driver init codes for the devices we have on i2c_2 also. Since rebooting to stock kernel does not have issue, it might be the chip init for at least one of the device might cause the i2c bus lock. It is also possible that the driver load order is different and we might need to load one of the drivers before the others? In the board file (board-rx51-peripherals.c) the tpa is the last entry in the i2c_board_info, so it is most likely the last one to load among the drivers for i2c_2 devices. In the dts si4713 and bq24150a is after the tpa... Try to move the tpa as last one in the dts? Does the i2c communication breaks with DT _and_ non DT boot?
Hi, On 14.03.2016 11:59, Peter Ujfalusi wrote: > > Does the i2c communication breaks with DT _and_ non DT boot? > IIRC, there was the same problem with legacy boot as well, but because there were tons of other problems, we did not investigate it :) Regards, Ivo -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Hi! We found out that tpa6130a2 device is being initialized before i2c_2
bus is initialized. So that is reason why tpa6130a2 fails...
Any idea why kernel first try to initialize one i2c device even before
bus itself is initialized?
On Monday 14 March 2016 11:59:13 Peter Ujfalusi wrote:
> Does the i2c communication breaks with DT _and_ non DT boot?
Yes, for both DT and non DT boot. And this problem is there for a long
time...
Hi, On Wed, Mar 16, 2016 at 02:33:19PM +0100, Pali Rohár wrote: > Hi! We found out that tpa6130a2 device is being initialized before > i2c_2 bus is initialized. So that is reason why tpa6130a2 fails... What do you mean by initialize? A call to tpa6130a2_probe()? In that case I wonder about client->adapter. Is it NULL? > Any idea why kernel first try to initialize one i2c device even before > bus itself is initialized? Just dump the stack during the tpa6130a2 initialization and you can see it in the kernel log: dump_stack(); --------------- I just had another look at the driver and I think there is a race condition for tpa6130a2_add_controls() and tpa6130a2_stereo_enable(). As far as I can see both functions check for "tpa6130a2_client != NULL". tpa6130a2_client is set before the probe function has finished, though. Simplified probe: ... tpa6130a2_client = client; set_default_regs(); acquire_power_gpio(); acquire_regulator(); tpa6130a2_power(1); // needs tpa6130a2_client check_device(); tpa6130a2_power(0); // needs tpa6130a2_client ... If tpa6130a2_add_controls() or tpa6130a2_stereo_enable() is called after tpa6130a2 probe has started, but before probe has completed, tpa6130a2_client is set, but not yet initialized. The race condition can be fixed easily by moving the tpa6130a2_client assignment directly after the regulator acquisition. -- Sebastian
Hi, On 16.03.2016 16:47, Sebastian Reichel wrote: > Hi, > > On Wed, Mar 16, 2016 at 02:33:19PM +0100, Pali Rohár wrote: >> Hi! We found out that tpa6130a2 device is being initialized before >> i2c_2 bus is initialized. So that is reason why tpa6130a2 fails... > > What do you mean by initialize? A call to tpa6130a2_probe()? In that > case I wonder about client->adapter. Is it NULL? > This is (a part of) the log when tpa6130a2 fails to initialize: Jan 1 08:03:07 Nokia-N900 kernel: [ 1.928344] twl 1-0048: PIH (irq 23) chaining IRQs 340..348 Jan 1 08:03:07 Nokia-N900 kernel: [ 1.934326] twl 1-0048: power (irq 345) chaining IRQs 348..355 Jan 1 08:03:07 Nokia-N900 kernel: [ 2.498504] twl4030_gpio twl4030-gpio: gpio (irq 340) chaining IRQs 356..373 Jan 1 08:03:07 Nokia-N900 kernel: [ 2.858215] twl4030_usb 48070000.i2c:twl@48:twl4030-usb: Initialized TWL4030 USB module Jan 1 08:03:07 Nokia-N900 kernel: [ 2.888702] input: twl4030_pwrbutton as /devices/platform/68000000.ocp/48070000.i2c/i2c-1/1-0048/48070000.i2c:twl@48:pwrbutton/input/input0 Jan 1 08:03:07 Nokia-N900 kernel: [ 2.903594] input: TWL4030 Keypad as /devices/platform/68000000.ocp/48070000.i2c/i2c-1/1-0048/48070000.i2c:twl@48:keypad/input/input1 Jan 1 08:03:07 Nokia-N900 kernel: [ 3.148040] 48070000.i2c:twl@48:madc supply vusb3v1 not found, using dummy regulator Jan 1 08:03:07 Nokia-N900 kernel: [ 6.997985] omap_i2c 48070000.i2c: bus 1 rev3.3 at 2200 kHz Jan 1 08:03:07 Nokia-N900 kernel: [ 7.010528] tpa6130a2 2-0060: Write failed Jan 1 08:03:07 Nokia-N900 kernel: [ 7.015563] omap_i2c 48072000.i2c: bus 2 rev3.3 at 100 kHz Jan 1 08:03:07 Nokia-N900 kernel: [ 7.023742] omap_i2c 48060000.i2c: bus 3 rev3.3 at 400 kHz Now, it is either tpa6130a2 probe() is called before i2c-2 is initialized or i2c driver first probes devices on the bus and only then logs successful probe ("omap_i2c 48072000.i2c: bus 2 rev3.3 at 100 kHz") in our case. > --------------- > > I just had another look at the driver and I think there is a race > condition for tpa6130a2_add_controls() and tpa6130a2_stereo_enable(). > > As far as I can see both functions check for "tpa6130a2_client != > NULL". tpa6130a2_client is set before the probe function has finished, > though. Simplified probe: > > ... > tpa6130a2_client = client; > set_default_regs(); > acquire_power_gpio(); > acquire_regulator(); > tpa6130a2_power(1); // needs tpa6130a2_client > check_device(); > tpa6130a2_power(0); // needs tpa6130a2_client > ... > > If tpa6130a2_add_controls() or tpa6130a2_stereo_enable() is called > after tpa6130a2 probe has started, but before probe has completed, > tpa6130a2_client is set, but not yet initialized. The race condition > can be fixed easily by moving the tpa6130a2_client assignment directly > after the regulator acquisition. > I'll try that, thanks. Regards, Ivo -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
On 03/16/2016 08:21 PM, Ivaylo Dimitrov wrote: > Hi, > > On 16.03.2016 16:47, Sebastian Reichel wrote: >> Hi, >> >> On Wed, Mar 16, 2016 at 02:33:19PM +0100, Pali Rohár wrote: >>> Hi! We found out that tpa6130a2 device is being initialized before >>> i2c_2 bus is initialized. So that is reason why tpa6130a2 fails... >> >> What do you mean by initialize? A call to tpa6130a2_probe()? In that >> case I wonder about client->adapter. Is it NULL? >> > > This is (a part of) the log when tpa6130a2 fails to initialize: > > Jan 1 08:03:07 Nokia-N900 kernel: [ 1.928344] twl 1-0048: PIH (irq > 23) chaining IRQs 340..348 > Jan 1 08:03:07 Nokia-N900 kernel: [ 1.934326] twl 1-0048: power (irq > 345) chaining IRQs 348..355 > Jan 1 08:03:07 Nokia-N900 kernel: [ 2.498504] twl4030_gpio > twl4030-gpio: gpio (irq 340) chaining IRQs 356..373 > Jan 1 08:03:07 Nokia-N900 kernel: [ 2.858215] twl4030_usb > 48070000.i2c:twl@48:twl4030-usb: Initialized TWL4030 USB module > Jan 1 08:03:07 Nokia-N900 kernel: [ 2.888702] input: > twl4030_pwrbutton as > /devices/platform/68000000.ocp/48070000.i2c/i2c-1/1-0048/48070000.i2c:twl@48:pwrbutton/input/input0 > > Jan 1 08:03:07 Nokia-N900 kernel: [ 2.903594] input: TWL4030 Keypad > as > /devices/platform/68000000.ocp/48070000.i2c/i2c-1/1-0048/48070000.i2c:twl@48:keypad/input/input1 > > Jan 1 08:03:07 Nokia-N900 kernel: [ 3.148040] > 48070000.i2c:twl@48:madc supply vusb3v1 not found, using dummy regulator > Jan 1 08:03:07 Nokia-N900 kernel: [ 6.997985] omap_i2c 48070000.i2c: > bus 1 rev3.3 at 2200 kHz > Jan 1 08:03:07 Nokia-N900 kernel: [ 7.010528] tpa6130a2 2-0060: > Write failed > Jan 1 08:03:07 Nokia-N900 kernel: [ 7.015563] omap_i2c 48072000.i2c: > bus 2 rev3.3 at 100 kHz > Jan 1 08:03:07 Nokia-N900 kernel: [ 7.023742] omap_i2c 48060000.i2c: > bus 3 rev3.3 at 400 kHz > > Now, it is either tpa6130a2 probe() is called before i2c-2 is > initialized or i2c driver first probes devices on the bus and only then > logs successful probe ("omap_i2c 48072000.i2c: bus 2 rev3.3 at 100 kHz") > in our case. No-no :) take a look on i2c-omap.c r = i2c_add_numbered_adapter(adap); ^^^^ here you see messages from tpa6130a2 (create i2c devices & probe if drivers are ready) if (r) { dev_err(omap->dev, "failure adding adapter\n"); goto err_unuse_clocks; } dev_info(omap->dev, "bus %d rev%d.%d at %d kHz\n", adap->nr, major, minor, omap->speed); ^^^^ and here "omap_i2c 48072000.i2c: bus 2 rev3.3 at 100 kHz" so everything is ok with probe order > >> --------------- >> >> I just had another look at the driver and I think there is a race >> condition for tpa6130a2_add_controls() and tpa6130a2_stereo_enable(). >> >> As far as I can see both functions check for "tpa6130a2_client != >> NULL". tpa6130a2_client is set before the probe function has finished, >> though. Simplified probe: >> >> ... >> tpa6130a2_client = client; >> set_default_regs(); >> acquire_power_gpio(); >> acquire_regulator(); >> tpa6130a2_power(1); // needs tpa6130a2_client >> check_device(); >> tpa6130a2_power(0); // needs tpa6130a2_client >> ... >> >> If tpa6130a2_add_controls() or tpa6130a2_stereo_enable() is called >> after tpa6130a2 probe has started, but before probe has completed, >> tpa6130a2_client is set, but not yet initialized. The race condition >> can be fixed easily by moving the tpa6130a2_client assignment directly >> after the regulator acquisition. >>
Hi, On 16.03.2016 20:32, Grygorii Strashko wrote: > > No-no :) take a look on i2c-omap.c > > r = i2c_add_numbered_adapter(adap); > > ^^^^ here you see messages from tpa6130a2 (create i2c devices & probe if drivers are ready) > > if (r) { > dev_err(omap->dev, "failure adding adapter\n"); > goto err_unuse_clocks; > } > > dev_info(omap->dev, "bus %d rev%d.%d at %d kHz\n", adap->nr, > major, minor, omap->speed); > > ^^^^ and here "omap_i2c 48072000.i2c: bus 2 rev3.3 at 100 kHz" > > so everything is ok with probe order > Sorry for the noise then :) here is the log with dump_stack() in tpa6130a2_i2c_write: Jan 1 06:01:43 Nokia-N900 kernel: [ 6.947998] omap_i2c 48070000.i2c: bus 1 rev3.3 at 2200 kHz Jan 1 06:01:43 Nokia-N900 kernel: [ 6.960632] tpa6130a2 2-0060: Write failed Jan 1 06:01:43 Nokia-N900 kernel: [ 6.965026] CPU: 0 PID: 6 Comm: kworker/u2:0 Not tainted 4.5.0-rc5+ #26 Jan 1 06:01:43 Nokia-N900 kernel: [ 6.972106] Hardware name: Nokia RX-51 board Jan 1 06:01:43 Nokia-N900 kernel: [ 6.976684] Workqueue: deferwq deferred_probe_work_func Jan 1 06:01:43 Nokia-N900 kernel: [ 6.982299] [<c0013c18>] (unwind_backtrace) from [<c0011f38>] (show_stack+0x10/0x14) Jan 1 06:01:43 Nokia-N900 kernel: [ 6.990570] [<c0011f38>] (show_stack) from [<c0390884>] (tpa6130a2_i2c_write+0x58/0x90) Jan 1 06:01:43 Nokia-N900 kernel: [ 6.999114] [<c0390884>] (tpa6130a2_i2c_write) from [<c0390968>] (tpa6130a2_power+0xac/0x1c4) Jan 1 06:01:43 Nokia-N900 kernel: [ 7.008239] [<c0390968>] (tpa6130a2_power) from [<c0390d80>] (tpa6130a2_probe+0x144/0x234) Jan 1 06:01:43 Nokia-N900 kernel: [ 7.017059] [<c0390d80>] (tpa6130a2_probe) from [<c032b650>] (i2c_device_probe+0x170/0x1b8) Jan 1 06:01:43 Nokia-N900 kernel: [ 7.025939] [<c032b650>] (i2c_device_probe) from [<c02a7bd4>] (driver_probe_device+0x120/0x2b0) Jan 1 06:01:43 Nokia-N900 kernel: [ 7.035247] [<c02a7bd4>] (driver_probe_device) from [<c02a62c8>] (bus_for_each_drv+0x48/0x8c) Jan 1 06:01:43 Nokia-N900 kernel: [ 7.044311] [<c02a62c8>] (bus_for_each_drv) from [<c02a7a20>] (__device_attach+0x88/0xf8) Jan 1 06:01:43 Nokia-N900 kernel: [ 7.053009] [<c02a7a20>] (__device_attach) from [<c02a70b0>] (bus_probe_device+0x28/0x80) Jan 1 06:01:43 Nokia-N900 kernel: [ 7.061737] [<c02a70b0>] (bus_probe_device) from [<c02a5680>] (device_add+0x3c0/0x55c) Jan 1 06:01:43 Nokia-N900 kernel: [ 7.070159] [<c02a5680>] (device_add) from [<c032cf28>] (i2c_new_device+0xf8/0x198) Jan 1 06:01:43 Nokia-N900 kernel: [ 7.078308] [<c032cf28>] (i2c_new_device) from [<c032d4e8>] (i2c_register_adapter+0x2d0/0x47c) Jan 1 06:01:43 Nokia-N900 kernel: [ 7.087432] [<c032d4e8>] (i2c_register_adapter) from [<c032f084>] (omap_i2c_probe+0x54c/0x64c) Jan 1 06:01:43 Nokia-N900 kernel: [ 7.096618] [<c032f084>] (omap_i2c_probe) from [<c02a93bc>] (platform_drv_probe+0x58/0xa0) Jan 1 06:01:43 Nokia-N900 kernel: [ 7.105438] [<c02a93bc>] (platform_drv_probe) from [<c02a7bd4>] (driver_probe_device+0x120/0x2b0) Jan 1 06:01:43 Nokia-N900 kernel: [ 7.114929] [<c02a7bd4>] (driver_probe_device) from [<c02a62c8>] (bus_for_each_drv+0x48/0x8c) Jan 1 06:01:43 Nokia-N900 kernel: [ 7.123962] [<c02a62c8>] (bus_for_each_drv) from [<c02a7a20>] (__device_attach+0x88/0xf8) Jan 1 06:01:43 Nokia-N900 kernel: [ 7.132659] [<c02a7a20>] (__device_attach) from [<c02a70b0>] (bus_probe_device+0x28/0x80) Jan 1 06:01:43 Nokia-N900 kernel: [ 7.141357] [<c02a70b0>] (bus_probe_device) from [<c02a7508>] (deferred_probe_work_func+0x58/0x84) Jan 1 06:01:43 Nokia-N900 kernel: [ 7.150939] [<c02a7508>] (deferred_probe_work_func) from [<c0042a50>] (process_one_work+0x1c4/0x324) Jan 1 06:01:43 Nokia-N900 kernel: [ 7.160705] [<c0042a50>] (process_one_work) from [<c0042ef4>] (worker_thread+0x314/0x4a8) Jan 1 06:01:43 Nokia-N900 kernel: [ 7.169433] [<c0042ef4>] (worker_thread) from [<c00474e4>] (kthread+0xcc/0xe0) Jan 1 06:01:43 Nokia-N900 kernel: [ 7.177154] [<c00474e4>] (kthread) from [<c000f218>] (ret_from_fork+0x14/0x3c) Jan 1 06:01:43 Nokia-N900 kernel: [ 7.184783] tpa6130a2 2-0060: Failed to initialize chip Jan 1 06:01:43 Nokia-N900 kernel: [ 7.190551] tpa6130a2: probe of 2-0060 failed with error -121 Jan 1 06:01:43 Nokia-N900 kernel: [ 7.197174] omap_i2c 48072000.i2c: bus 2 rev3.3 at 100 kHz now, the only thing I can think of remaining to test is the reset gpio set-up - I wonder if it is possible to be set in safe mode(or input, or... ?), so the reset is never deasserted. Ivo -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Hi, On Wed, Mar 16, 2016 at 09:50:40PM +0200, Ivaylo Dimitrov wrote: > Jan 1 06:01:43 Nokia-N900 kernel: [ 6.947998] omap_i2c 48070000.i2c: bus 1 rev3.3 at 2200 kHz > Jan 1 06:01:43 Nokia-N900 kernel: [ 6.960632] tpa6130a2 2-0060: Write failed > Jan 1 06:01:43 Nokia-N900 kernel: [ 6.965026] CPU: 0 PID: 6 Comm: kworker/u2:0 Not tainted 4.5.0-rc5+ #26 > Jan 1 06:01:43 Nokia-N900 kernel: [ 6.972106] Hardware name: Nokia RX-51 board > Jan 1 06:01:43 Nokia-N900 kernel: [ 6.976684] Workqueue: deferwq deferred_probe_work_func > Jan 1 06:01:43 Nokia-N900 kernel: [ 6.982299] [<c0013c18>] (unwind_backtrace) from [<c0011f38>] (show_stack+0x10/0x14) > Jan 1 06:01:43 Nokia-N900 kernel: [ 6.990570] [<c0011f38>] (show_stack) from [<c0390884>] (tpa6130a2_i2c_write+0x58/0x90) > Jan 1 06:01:43 Nokia-N900 kernel: [ 6.999114] [<c0390884>] (tpa6130a2_i2c_write) from [<c0390968>] (tpa6130a2_power+0xac/0x1c4) > Jan 1 06:01:43 Nokia-N900 kernel: [ 7.008239] [<c0390968>] (tpa6130a2_power) from [<c0390d80>] (tpa6130a2_probe+0x144/0x234) > Jan 1 06:01:43 Nokia-N900 kernel: [ 7.017059] [<c0390d80>] (tpa6130a2_probe) from [<c032b650>] (i2c_device_probe+0x170/0x1b8) > Jan 1 06:01:43 Nokia-N900 kernel: [ 7.025939] [<c032b650>] (i2c_device_probe) from [<c02a7bd4>] (driver_probe_device+0x120/0x2b0) > Jan 1 06:01:43 Nokia-N900 kernel: [ 7.035247] [<c02a7bd4>] (driver_probe_device) from [<c02a62c8>] (bus_for_each_drv+0x48/0x8c) > Jan 1 06:01:43 Nokia-N900 kernel: [ 7.044311] [<c02a62c8>] (bus_for_each_drv) from [<c02a7a20>] (__device_attach+0x88/0xf8) > Jan 1 06:01:43 Nokia-N900 kernel: [ 7.053009] [<c02a7a20>] (__device_attach) from [<c02a70b0>] (bus_probe_device+0x28/0x80) > Jan 1 06:01:43 Nokia-N900 kernel: [ 7.061737] [<c02a70b0>] (bus_probe_device) from [<c02a5680>] (device_add+0x3c0/0x55c) > Jan 1 06:01:43 Nokia-N900 kernel: [ 7.070159] [<c02a5680>] (device_add) from [<c032cf28>] (i2c_new_device+0xf8/0x198) > Jan 1 06:01:43 Nokia-N900 kernel: [ 7.078308] [<c032cf28>] (i2c_new_device) from [<c032d4e8>] (i2c_register_adapter+0x2d0/0x47c) > Jan 1 06:01:43 Nokia-N900 kernel: [ 7.087432] [<c032d4e8>] (i2c_register_adapter) from [<c032f084>] (omap_i2c_probe+0x54c/0x64c) > Jan 1 06:01:43 Nokia-N900 kernel: [ 7.096618] [<c032f084>] (omap_i2c_probe) from [<c02a93bc>] (platform_drv_probe+0x58/0xa0) > Jan 1 06:01:43 Nokia-N900 kernel: [ 7.105438] [<c02a93bc>] (platform_drv_probe) from [<c02a7bd4>] (driver_probe_device+0x120/0x2b0) > Jan 1 06:01:43 Nokia-N900 kernel: [ 7.114929] [<c02a7bd4>] (driver_probe_device) from [<c02a62c8>] (bus_for_each_drv+0x48/0x8c) > Jan 1 06:01:43 Nokia-N900 kernel: [ 7.123962] [<c02a62c8>] (bus_for_each_drv) from [<c02a7a20>] (__device_attach+0x88/0xf8) > Jan 1 06:01:43 Nokia-N900 kernel: [ 7.132659] [<c02a7a20>] (__device_attach) from [<c02a70b0>] (bus_probe_device+0x28/0x80) > Jan 1 06:01:43 Nokia-N900 kernel: [ 7.141357] [<c02a70b0>] (bus_probe_device) from [<c02a7508>] (deferred_probe_work_func+0x58/0x84) > Jan 1 06:01:43 Nokia-N900 kernel: [ 7.150939] [<c02a7508>] (deferred_probe_work_func) from [<c0042a50>] (process_one_work+0x1c4/0x324) > Jan 1 06:01:43 Nokia-N900 kernel: [ 7.160705] [<c0042a50>] (process_one_work) from [<c0042ef4>] (worker_thread+0x314/0x4a8) > Jan 1 06:01:43 Nokia-N900 kernel: [ 7.169433] [<c0042ef4>] (worker_thread) from [<c00474e4>] (kthread+0xcc/0xe0) > Jan 1 06:01:43 Nokia-N900 kernel: [ 7.177154] [<c00474e4>] (kthread) from [<c000f218>] (ret_from_fork+0x14/0x3c) > Jan 1 06:01:43 Nokia-N900 kernel: [ 7.184783] tpa6130a2 2-0060: Failed to initialize chip > Jan 1 06:01:43 Nokia-N900 kernel: [ 7.190551] tpa6130a2: probe of 2-0060 failed with error -121 > Jan 1 06:01:43 Nokia-N900 kernel: [ 7.197174] omap_i2c 48072000.i2c: bus 2 rev3.3 at 100 kHz > > now, the only thing I can think of remaining to test is the reset gpio set-up - > I wonder if it is possible to be set in safe mode(or input, or... ?), so the > reset is never deasserted. mh both, the power gpio is turned off in tpa6130a2_power(0). I guess if you don't see the problem during probe() everything works? I have another idea though: In opposit to the gpio, the regulator may also be referenced by something else/already enabled. I guess adding a sleep after the regulator_enable() is worth a try. Also I wonder if the same happens, if you avoid having the module available during boot and instead load it once everything has settled. That would rule out any side-effects of other modules being probed on the same i2c bus. -- Sebastian
Hi, On 17.03.2016 02:49, Sebastian Reichel wrote: > > mh both, the power gpio is turned off in tpa6130a2_power(0). I guess > if you don't see the problem during probe() everything works? > > I have another idea though: In opposit to the gpio, the regulator > may also be referenced by something else/already enabled. I guess > adding a sleep after the regulator_enable() is worth a try. > > Also I wonder if the same happens, if you avoid having the module > available during boot and instead load it once everything has > settled. That would rule out any side-effects of other modules > being probed on the same i2c bus. Well, I think I've figured it out - input pullups are not enabled on i2c bus pins, in stock kernel we have: ./devmem2 0x480021BC Value at address 0x480021BC (0x4001f1bc): 0x1180118 ./devmem2 0x480021C0 Value at address 0x480021C0 (0x4001f1c0): 0x1180118 in mainline ./devmem2 0x480021BC Value at address 0x480021BC (0xb6ff01bc): 0x1000100 ./devmem2 0x480021C0 Value at address 0x480021C0 (0xb6f6d1c0): 0x1000100 I wonder how i2c devices work at all :) Will fix the board DTS file later on an will report Regards, Ivo -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
On Thursday 17 March 2016 09:56:22 Ivaylo Dimitrov wrote: > Hi, > > On 17.03.2016 02:49, Sebastian Reichel wrote: > > > >mh both, the power gpio is turned off in tpa6130a2_power(0). I guess > >if you don't see the problem during probe() everything works? > > > >I have another idea though: In opposit to the gpio, the regulator > >may also be referenced by something else/already enabled. I guess > >adding a sleep after the regulator_enable() is worth a try. > > > >Also I wonder if the same happens, if you avoid having the module > >available during boot and instead load it once everything has > >settled. That would rule out any side-effects of other modules > >being probed on the same i2c bus. > > > Well, I think I've figured it out - input pullups are not enabled > on i2c bus pins, in stock kernel we have: > > ./devmem2 0x480021BC > Value at address 0x480021BC (0x4001f1bc): 0x1180118 > > ./devmem2 0x480021C0 > Value at address 0x480021C0 (0x4001f1c0): 0x1180118 > > in mainline > > ./devmem2 0x480021BC > Value at address 0x480021BC (0xb6ff01bc): 0x1000100 > > ./devmem2 0x480021C0 > Value at address 0x480021C0 (0xb6f6d1c0): 0x1000100 > > I wonder how i2c devices work at all :) Is camera on same bus as tpa? Maybe this is reason why camera is non-functional too? > Will fix the board DTS file later on an will report Thanks for investigation! Is that problem in both DTS and also legacy board code?
Hi, On 17.03.2016 15:01, Pali Rohár wrote: > On Thursday 17 March 2016 09:56:22 Ivaylo Dimitrov wrote: >> Hi, >> > > Is camera on same bus as tpa? Maybe this is reason why camera is > non-functional too? > It doesn't matter, all the i2c busses are missing the pullups. >> Will fix the board DTS file later on an will report > > Thanks for investigation! Is that problem in both DTS and also legacy > board code? > I guess legacy board code does not set i2c pull-ups either, as we have that problem since the beginning of time. Anyway, let me first check if enabling pullups really solves the issue, I hope to test that in a couple of hours when I am back home. Or you can do it yourself, it is just a matter of replacing PIN_INPUT with PIN_INPUT_PULLUP in https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/tree/arch/arm/boot/dts/omap3-n900.dts?id=refs/tags/v4.5#n199 for all the 3 ic2 busses Regards, Ivo -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
* Ivaylo Dimitrov <ivo.g.dimitrov.75@gmail.com> [160317 06:11]: > Hi, > > On 17.03.2016 15:01, Pali Rohár wrote: > >On Thursday 17 March 2016 09:56:22 Ivaylo Dimitrov wrote: > >>Hi, > >> > > > >Is camera on same bus as tpa? Maybe this is reason why camera is > >non-functional too? > > > > It doesn't matter, all the i2c busses are missing the pullups. > > >>Will fix the board DTS file later on an will report > > > >Thanks for investigation! Is that problem in both DTS and also legacy > >board code? > > > > I guess legacy board code does not set i2c pull-ups either, as we > have that problem since the beginning of time. Anyway, let me first > check if enabling pullups really solves the issue, I hope to test that in a > couple of hours when I am back home. > > Or you can do it yourself, it is just a matter of replacing PIN_INPUT with > PIN_INPUT_PULLUP in https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/tree/arch/arm/boot/dts/omap3-n900.dts?id=refs/tags/v4.5#n199 > for all the 3 ic2 busses Check the schematics. If the hardware has external pull-ups on a line then don't enable the internal pull-ups. Otherwise both the external and intenal pulls are parallel the pull value will be wrong. My guess is that on n900 all the i2c lines have external pulls. Regards, Tony -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Hi, On 17.03.2016 15:33, Tony Lindgren wrote: > > Check the schematics. If the hardware has external pull-ups on a > line then don't enable the internal pull-ups. Otherwise both the > external and intenal pulls are parallel the pull value will be > wrong. My guess is that on n900 all the i2c lines have external > pulls. There are, 1k connected to VIO_18, but still, stock Nokia kernel enables the internal pull-ups as well. I doubt Nokia devs did that by mistake. Could it be that VIO_18 is disabled by the time TPA6130A2 is probed? Also, what is the problem to have both internal and external pull-ups in parallel? Regards, Ivo -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
* Ivaylo Dimitrov <ivo.g.dimitrov.75@gmail.com> [160317 06:51]: > Hi, > > On 17.03.2016 15:33, Tony Lindgren wrote: > > > >Check the schematics. If the hardware has external pull-ups on a > >line then don't enable the internal pull-ups. Otherwise both the > >external and intenal pulls are parallel the pull value will be > >wrong. My guess is that on n900 all the i2c lines have external > >pulls. > > There are, 1k connected to VIO_18, but still, stock Nokia kernel enables the > internal pull-ups as well. I doubt Nokia devs did that by mistake. Could it > be that VIO_18 is disabled by the time TPA6130A2 is probed? Seems like a bug to me. My bets are on the deferred probe related Peter posted. > Also, what is the problem to have both internal and external pull-ups in > parallel? You can calculate the parallel resistor value of the weak internal pull with the 1k external pull :) If the i2c line pulls are wrong the signal quality won't match the spec and you will be getting i2c bus errors. If you can read and write to the i2c chip, this is not the issue. Regards, Tony -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Hi, On 17.03.2016 16:32, Tony Lindgren wrote: > > Seems like a bug to me. My bets are on the deferred probe related > Peter posted. > I will test Peter's patch as well, however I really doubt internal pull-ups enabled by Nokia to be a bug - keep in mind there are (or at least were) enough devices on the field for such a bug to not remain unnoticed, esp if it directly affects the signal quality over the i2c bus. > > You can calculate the parallel resistor value of the weak internal > pull with the 1k external pull :) Sure :) > If the i2c line pulls are wrong > the signal quality won't match the spec and you will be getting > i2c bus errors. If you can read and write to the i2c chip, this > is not the issue. > And it seems stock kernel can read/write without problems with those pull-ups enabled. However, lets continue the discussion after I have tested both the Peter's patch and internal pull-ups enabled. Thanks, Ivo -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
On Wednesday 16 March 2016 15:47:10 Sebastian Reichel wrote: > I just had another look at the driver and I think there is a race > condition for tpa6130a2_add_controls() and tpa6130a2_stereo_enable(). > > As far as I can see both functions check for "tpa6130a2_client != > NULL". tpa6130a2_client is set before the probe function has finished, > though. Simplified probe: > > ... > tpa6130a2_client = client; > set_default_regs(); > acquire_power_gpio(); > acquire_regulator(); > tpa6130a2_power(1); // needs tpa6130a2_client > check_device(); > tpa6130a2_power(0); // needs tpa6130a2_client > ... > > If tpa6130a2_add_controls() or tpa6130a2_stereo_enable() is called > after tpa6130a2 probe has started, but before probe has completed, > tpa6130a2_client is set, but not yet initialized. The race condition > can be fixed easily by moving the tpa6130a2_client assignment directly > after the regulator acquisition. > > -- Sebastian Is this race condition really relevant? If yes, then it should be fixed.
--- a/sound/soc/codecs/tpa6130a2.c +++ b/sound/soc/codecs/tpa6130a2.c @@ -152,6 +152,8 @@ static int tpa6130a2_power(u8 power) if (data->power_gpio >= 0) gpio_set_value(data->power_gpio, 1); + msleep(5); + data->power_state = 1; ret = tpa6130a2_initialize(); if (ret < 0) {