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?
--
Pali Rohár
[email protected]
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) {
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
--
Pali Rohár
[email protected]
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.
--
Jarkko
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.
--
Pali Rohár
[email protected]
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.
--
Jarkko
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?
--
Pali Rohár
[email protected]
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?
--
Péter
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
--
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html
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.
--
Pali Rohár
[email protected]
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...
--
Pali Rohár
[email protected]
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
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...
--
Pali Rohár
[email protected]
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.
--
Pali Rohár
[email protected]
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?
--
Péter
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
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...
--
Pali Rohár
[email protected]
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
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.
>>
--
regards,
-grygorii
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
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
On 03/16/16 21:50, Ivaylo Dimitrov wrote:
> 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.
can you try this:
diff --git a/sound/soc/codecs/tpa6130a2.c b/sound/soc/codecs/tpa6130a2.c
index 11d85c5c787a..7f5881bff5d9 100644
--- a/sound/soc/codecs/tpa6130a2.c
+++ b/sound/soc/codecs/tpa6130a2.c
@@ -386,6 +386,8 @@ static int tpa6130a2_probe(struct i2c_client *client,
data->power_gpio = pdata->power_gpio;
} else if (np) {
data->power_gpio = of_get_named_gpio(np, "power-gpio", 0);
+ if (data->power_gpio == -EPROBE_DEFER)
+ return data->power_gpio;
} else {
dev_err(dev, "Platform data not set\n");
dump_stack();
--
P?ter
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
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?
--
Pali Rohár
[email protected]
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
* Ivaylo Dimitrov <[email protected]> [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
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
* Ivaylo Dimitrov <[email protected]> [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
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
Hi,
>
> can you try this:
> diff --git a/sound/soc/codecs/tpa6130a2.c b/sound/soc/codecs/tpa6130a2.c
> index 11d85c5c787a..7f5881bff5d9 100644
> --- a/sound/soc/codecs/tpa6130a2.c
> +++ b/sound/soc/codecs/tpa6130a2.c
> @@ -386,6 +386,8 @@ static int tpa6130a2_probe(struct i2c_client *client,
> data->power_gpio = pdata->power_gpio;
> } else if (np) {
> data->power_gpio = of_get_named_gpio(np, "power-gpio", 0);
> + if (data->power_gpio == -EPROBE_DEFER)
> + return data->power_gpio;
> } else {
> dev_err(dev, "Platform data not set\n");
> dump_stack();
>
Doesn't help :(
Ivo
On 03/17/16 19:26, Ivaylo Dimitrov wrote:
> Hi,
>
>>
>> can you try this:
>> diff --git a/sound/soc/codecs/tpa6130a2.c b/sound/soc/codecs/tpa6130a2.c
>> index 11d85c5c787a..7f5881bff5d9 100644
>> --- a/sound/soc/codecs/tpa6130a2.c
>> +++ b/sound/soc/codecs/tpa6130a2.c
>> @@ -386,6 +386,8 @@ static int tpa6130a2_probe(struct i2c_client *client,
>> data->power_gpio = pdata->power_gpio;
>> } else if (np) {
>> data->power_gpio = of_get_named_gpio(np, "power-gpio", 0);
>> + if (data->power_gpio == -EPROBE_DEFER)
>> + return data->power_gpio;
>> } else {
>> dev_err(dev, "Platform data not set\n");
>> dump_stack();
>>
>
>
> Doesn't help :(
it worth a try ;)
But enabling the pull via DT for the i2c2 works?
--
P?ter
Hi
On Fri Mar 18 12:33:14 2016 Peter Ujfalusi <[email protected]> wrote:
>
> But enabling the pull via DT for the i2c2 works?
>
No :(. I even migrated the driver to regmap - no gain. Maybe i2c bus is blocked by another device held in reset. The next thing I am going to try is to deassert reset/power gpios on all the devices on i2c-2 bus, to see if it will make any difference. Or if you have any other ideas, please share.
Ivo
On Fri, Mar 18, 2016 at 03:13:49PM +0200, Ивайло Димитров wrote:
> On Fri Mar 18 12:33:14 2016 Peter Ujfalusi <[email protected]> wrote:
> > But enabling the pull via DT for the i2c2 works?
>
> No :(. I even migrated the driver to regmap - no gain. Maybe i2c
> bus is blocked by another device held in reset. The next thing I
> am going to try is to deassert reset/power gpios on all the
> devices on i2c-2 bus, to see if it will make any difference. Or if
> you have any other ideas, please share.
Have you tried the ideas from <20160317004917.GA6750@earth> (Date:
Thu, 17 Mar 2016 01:49:18 +0100)?
-- Sebastian
Hi,
On 18.03.2016 15:36, Sebastian Reichel wrote:
>
> Have you tried the ideas from <20160317004917.GA6750@earth> (Date:
> Thu, 17 Mar 2016 01:49:18 +0100)?
>
To the extend I understood them :)
Regulator is V28_A, which is always-on, so it is enabled no matter what
probe does. Anyway, I added a various delays after regulator_enable(),
to no success.
I didn't try building the driver as a modules, instead I played with
bind/unbind functionality - makes no difference.
Thanks,
Ivo
Hi,
On Fri, Mar 18, 2016 at 03:45:26PM +0200, Ivaylo Dimitrov wrote:
> On 18.03.2016 15:36, Sebastian Reichel wrote:
>
> >Have you tried the ideas from <20160317004917.GA6750@earth> (Date:
> >Thu, 17 Mar 2016 01:49:18 +0100)?
> >
>
> To the extend I understood them :)
>
> Regulator is V28_A, which is always-on, so it is enabled no matter what
> probe does. Anyway, I added a various delays after regulator_enable(), to no
> success.
Did you by chance also test adding a delay after setting the power
gpio? According to the datasheet:
Start-up time from shutdown: typical 5ms
> I didn't try building the driver as a module, instead I played with
> bind/unbind functionality - makes no difference.
Ok.
-- Sebastian
Hi,
On 18.03.2016 17:04, Sebastian Reichel wrote:
> Did you by chance also test adding a delay after setting the power
> gpio? According to the datasheet:
>
> Start-up time from shutdown: typical 5ms
>
:)
if (data->power_gpio) {
dev_err(&tpa6130a2_client->dev,
"!!!!!!!!!!!! GPIO SET: %d\n", ret);
mdelay(10);
gpiod_set_value(data->power_gpio, 1);
mdelay(10);
}
Ivo
Hi,
On 18.03.2016 17:04, Sebastian Reichel wrote:
> Hi,
>
> On Fri, Mar 18, 2016 at 03:45:26PM +0200, Ivaylo Dimitrov wrote:
>> On 18.03.2016 15:36, Sebastian Reichel wrote:
>>
>>
>> Regulator is V28_A, which is always-on, so it is enabled no matter what
>> probe does. Anyway, I added a various delays after regulator_enable(), to no
>> success.
>
I guess we're getting closer - I put some printks in various functions
in the twl-regulator.c, here is the result:
on power-up:
[ 2.378601] twl4030ldo_get_voltage_sel VMMC2 vsel 0x00000008
[ 2.384948] twl4030reg_enable VMMC2 grp 0x00000020
[ 2.408416] twl4030ldo_get_voltage_sel VMMC2 vsel 0x00000008
[ 7.196685] twl4030reg_is_enabled VMMC2 state 0x0000002e
[ 7.202819] twl4030reg_is_enabled VMMC2 state 0x0000002e
[ 7.209777] twl4030reg_is_enabled VMMC2 state 0x0000002e
[ 7.215728] twl4030reg_is_enabled VMMC2 state 0x0000002e
[ 7.223205] twl4030reg_is_enabled VMMC2 state 0x0000002e
after restart from stock kernel:
[ 2.388610] twl4030ldo_get_voltage_sel VMMC2 vsel 0x0000000a
[ 2.394958] twl4030reg_enable VMMC2 grp 0x00000028
[ 2.418426] twl4030ldo_get_voltage_sel VMMC2 vsel 0x0000000a
[ 7.186645] twl4030reg_is_enabled VMMC2 state 0x00000020
[ 7.192718] twl4030reg_is_enabled VMMC2 state 0x00000020
[ 7.199615] twl4030reg_is_enabled VMMC2 state 0x00000020
[ 7.205535] twl4030reg_is_enabled VMMC2 state 0x00000020
[ 7.212951] twl4030reg_is_enabled VMMC2 state 0x00000020
I don't see twl4030ldo_set_voltage_sel() for VMMC2(V28_A) regulator,
though there are calls for VMMC1 and VAUX3.
So, it seems to me that V28_A is not enabled or correctly set-up and all
devices connected to it does not function. And it looks like even after
power-on VMMC2 is not correctly set-up - it is supposed to have voltage
of 2.85V (10) but kernel leaves it to 2.60V (8). However my twl-fu ends
here so any help is appreciated.
Ivo
Hi,
On Sat, Mar 19, 2016 at 10:49:57AM +0200, Ivaylo Dimitrov wrote:
> On 18.03.2016 17:04, Sebastian Reichel wrote:
> >On Fri, Mar 18, 2016 at 03:45:26PM +0200, Ivaylo Dimitrov wrote:
> >>On 18.03.2016 15:36, Sebastian Reichel wrote:
> >>Regulator is V28_A, which is always-on, so it is enabled no matter what
> >>probe does. Anyway, I added a various delays after regulator_enable(), to no
> >>success.
>
> I guess we're getting closer - I put some printks in various functions in
> the twl-regulator.c, here is the result:
>
> on power-up:
>
> [ 2.378601] twl4030ldo_get_voltage_sel VMMC2 vsel 0x00000008
> [ 2.384948] twl4030reg_enable VMMC2 grp 0x00000020
> [ 2.408416] twl4030ldo_get_voltage_sel VMMC2 vsel 0x00000008
> [ 7.196685] twl4030reg_is_enabled VMMC2 state 0x0000002e
> [ 7.202819] twl4030reg_is_enabled VMMC2 state 0x0000002e
> [ 7.209777] twl4030reg_is_enabled VMMC2 state 0x0000002e
> [ 7.215728] twl4030reg_is_enabled VMMC2 state 0x0000002e
> [ 7.223205] twl4030reg_is_enabled VMMC2 state 0x0000002e
Ok, so normal power up results in running VMMC2 (always-on works),
but voltage is not configured correctly. 2.6V is default according
to the TRM. I think this is a "bug" in the regulator framework. It
should setup the minimum allowed voltage before enabling the
always-on regulator.
In case of the tpa6130a2/tpa6140a2 driver it may also be nice to add
something like this to the driver (Vdd may be between 2.5V and 5.5V
according to both datasheets):
if (regulator_can_change_voltage(data->supply))
regulator_set_voltage(data->supply, 2500000, 5500000);
> after restart from stock kernel:
>
> [ 2.388610] twl4030ldo_get_voltage_sel VMMC2 vsel 0x0000000a
> [ 2.394958] twl4030reg_enable VMMC2 grp 0x00000028
I had a quick glance at this. I think stock kernel put VMMC2
into sleep mode. Mainline kernel does not expect sleep mode
being set and does not disable it.
> [ 2.418426] twl4030ldo_get_voltage_sel VMMC2 vsel 0x0000000a
> [ 7.186645] twl4030reg_is_enabled VMMC2 state 0x00000020
> [ 7.192718] twl4030reg_is_enabled VMMC2 state 0x00000020
> [ 7.199615] twl4030reg_is_enabled VMMC2 state 0x00000020
> [ 7.205535] twl4030reg_is_enabled VMMC2 state 0x00000020
> [ 7.212951] twl4030reg_is_enabled VMMC2 state 0x00000020
>
> I don't see twl4030ldo_set_voltage_sel() for VMMC2(V28_A) regulator, though
> there are calls for VMMC1 and VAUX3.
I guess that's because the voltage is only configured if at least
one regulator consumer requests anything specific.
> So, it seems to me that V28_A is not enabled or correctly set-up
> and all devices connected to it does not function. And it looks
> like even after power-on VMMC2 is not correctly set-up - it is
> supposed to have voltage of 2.85V (10) but kernel leaves it to
> 2.60V (8). However my twl-fu ends here so any help is appreciated.
So in case of reboot from stock kernel voltage is already configured
to 2.8V, but it does not work, because of the sleep mode.
-- Sebastian
Hi
On 20.03.2016 07:17, Sebastian Reichel wrote:
> Hi,
>
> On Sat, Mar 19, 2016 at 10:49:57AM +0200, Ivaylo Dimitrov wrote:
>> On 18.03.2016 17:04, Sebastian Reichel wrote:
>>> On Fri, Mar 18, 2016 at 03:45:26PM +0200, Ivaylo Dimitrov wrote:
>>>> On 18.03.2016 15:36, Sebastian Reichel wrote:
>>>> Regulator is V28_A, which is always-on, so it is enabled no matter what
>>>> probe does. Anyway, I added a various delays after regulator_enable(), to no
>>>> success.
>>
>> I guess we're getting closer - I put some printks in various functions in
>> the twl-regulator.c, here is the result:
>>
>> on power-up:
>>
>> [ 2.378601] twl4030ldo_get_voltage_sel VMMC2 vsel 0x00000008
>> [ 2.384948] twl4030reg_enable VMMC2 grp 0x00000020
>> [ 2.408416] twl4030ldo_get_voltage_sel VMMC2 vsel 0x00000008
>> [ 7.196685] twl4030reg_is_enabled VMMC2 state 0x0000002e
>> [ 7.202819] twl4030reg_is_enabled VMMC2 state 0x0000002e
>> [ 7.209777] twl4030reg_is_enabled VMMC2 state 0x0000002e
>> [ 7.215728] twl4030reg_is_enabled VMMC2 state 0x0000002e
>> [ 7.223205] twl4030reg_is_enabled VMMC2 state 0x0000002e
>
> Ok, so normal power up results in running VMMC2 (always-on works),
> but voltage is not configured correctly. 2.6V is default according
> to the TRM. I think this is a "bug" in the regulator framework. It
> should setup the minimum allowed voltage before enabling the
> always-on regulator.
>
/sys/kernel/debug/regulator/regulator_summary shows 2850mV for V28_A, so
I would remove the quotes. Also, always-on is because if V28_A regulator
is turned off, there is a leakage through tlv320aic34 VIO. BTW one of
the things I did while trying to find the problem, was to remove that
always-on property from the DTS - it didn't help.
> In case of the tpa6130a2/tpa6140a2 driver it may also be nice to add
> something like this to the driver (Vdd may be between 2.5V and 5.5V
> according to both datasheets):
>
> if (regulator_can_change_voltage(data->supply))
> regulator_set_voltage(data->supply, 2500000, 5500000);
>
and add DT property for that voltage range, as max output power and
harmonics depend on the supply voltage.
>> after restart from stock kernel:
>>
>> [ 2.388610] twl4030ldo_get_voltage_sel VMMC2 vsel 0x0000000a
>> [ 2.394958] twl4030reg_enable VMMC2 grp 0x00000028
>
> I had a quick glance at this. I think stock kernel put VMMC2
> into sleep mode. Mainline kernel does not expect sleep mode
> being set and does not disable it.
>
Well, one would think that kernel should not have expectations on what
would be the state of the hardware by the time it takes control over it,
but setup everything needed instead.
>> [ 2.418426] twl4030ldo_get_voltage_sel VMMC2 vsel 0x0000000a
>> [ 7.186645] twl4030reg_is_enabled VMMC2 state 0x00000020
>> [ 7.192718] twl4030reg_is_enabled VMMC2 state 0x00000020
>> [ 7.199615] twl4030reg_is_enabled VMMC2 state 0x00000020
>> [ 7.205535] twl4030reg_is_enabled VMMC2 state 0x00000020
>> [ 7.212951] twl4030reg_is_enabled VMMC2 state 0x00000020
>>
>> I don't see twl4030ldo_set_voltage_sel() for VMMC2(V28_A) regulator, though
>> there are calls for VMMC1 and VAUX3.
>
> I guess that's because the voltage is only configured if at least
> one regulator consumer requests anything specific.
>
But then the board DTS is simply ignored. Doesn't look good :)
>> So, it seems to me that V28_A is not enabled or correctly set-up
>> and all devices connected to it does not function. And it looks
>> like even after power-on VMMC2 is not correctly set-up - it is
>> supposed to have voltage of 2.85V (10) but kernel leaves it to
>> 2.60V (8). However my twl-fu ends here so any help is appreciated.
>
> So in case of reboot from stock kernel voltage is already configured
> to 2.8V, but it does not work, because of the sleep mode.
>
Yeah, that sleep is pretty clear, I was rather asking - "any idea how to
fix that?". Or it is someone else expected to fix it?
Thanks,
Ivo
Hi,
On Sun, Mar 20, 2016 at 09:43:11PM +0200, Ivaylo Dimitrov wrote:
> On 20.03.2016 07:17, Sebastian Reichel wrote:
> >On Sat, Mar 19, 2016 at 10:49:57AM +0200, Ivaylo Dimitrov wrote:
> >>On 18.03.2016 17:04, Sebastian Reichel wrote:
> >>>On Fri, Mar 18, 2016 at 03:45:26PM +0200, Ivaylo Dimitrov wrote:
> >>>>On 18.03.2016 15:36, Sebastian Reichel wrote:
> >>>>Regulator is V28_A, which is always-on, so it is enabled no matter what
> >>>>probe does. Anyway, I added a various delays after regulator_enable(), to no
> >>>>success.
> >>
> >>I guess we're getting closer - I put some printks in various functions in
> >>the twl-regulator.c, here is the result:
> >>
> >>on power-up:
> >>
> >>[ 2.378601] twl4030ldo_get_voltage_sel VMMC2 vsel 0x00000008
> >>[ 2.384948] twl4030reg_enable VMMC2 grp 0x00000020
> >>[ 2.408416] twl4030ldo_get_voltage_sel VMMC2 vsel 0x00000008
> >>[ 7.196685] twl4030reg_is_enabled VMMC2 state 0x0000002e
> >>[ 7.202819] twl4030reg_is_enabled VMMC2 state 0x0000002e
> >>[ 7.209777] twl4030reg_is_enabled VMMC2 state 0x0000002e
> >>[ 7.215728] twl4030reg_is_enabled VMMC2 state 0x0000002e
> >>[ 7.223205] twl4030reg_is_enabled VMMC2 state 0x0000002e
> >
> >Ok, so normal power up results in running VMMC2 (always-on works),
> >but voltage is not configured correctly. 2.6V is default according
> >to the TRM. I think this is a "bug" in the regulator framework. It
> >should setup the minimum allowed voltage before enabling the
> >always-on regulator.
> >
>
> /sys/kernel/debug/regulator/regulator_summary shows 2850mV for V28_A, so I
> would remove the quotes. Also, always-on is because if V28_A regulator is
> turned off, there is a leakage through tlv320aic34 VIO. BTW one of the
> things I did while trying to find the problem, was to remove that always-on
> property from the DTS - it didn't help.
Right thinking about it, the voltage must also be configured for the
non always-on cases. So it's not a problem with the regulator
framework, but with twl-regulator's probe function, that should take
care of this.
> >In case of the tpa6130a2/tpa6140a2 driver it may also be nice to add
> >something like this to the driver (Vdd may be between 2.5V and 5.5V
> >according to both datasheets):
> >
> >if (regulator_can_change_voltage(data->supply))
> > regulator_set_voltage(data->supply, 2500000, 5500000);
> >
>
> and add DT property for that voltage range, as max output power and
> harmonics depend on the supply voltage.
I guess that's 2nd step.
> >>after restart from stock kernel:
> >>
> >>[ 2.388610] twl4030ldo_get_voltage_sel VMMC2 vsel 0x0000000a
> >>[ 2.394958] twl4030reg_enable VMMC2 grp 0x00000028
> >
> >I had a quick glance at this. I think stock kernel put VMMC2
> >into sleep mode. Mainline kernel does not expect sleep mode
> >being set and does not disable it.
> >
>
> Well, one would think that kernel should not have expectations on what would
> be the state of the hardware by the time it takes control over it, but setup
> everything needed instead.
I thought it's obvious, that this is not the desired behaviour :)
> >>[ 2.418426] twl4030ldo_get_voltage_sel VMMC2 vsel 0x0000000a
> >>[ 7.186645] twl4030reg_is_enabled VMMC2 state 0x00000020
> >>[ 7.192718] twl4030reg_is_enabled VMMC2 state 0x00000020
> >>[ 7.199615] twl4030reg_is_enabled VMMC2 state 0x00000020
> >>[ 7.205535] twl4030reg_is_enabled VMMC2 state 0x00000020
> >>[ 7.212951] twl4030reg_is_enabled VMMC2 state 0x00000020
> >>
> >>I don't see twl4030ldo_set_voltage_sel() for VMMC2(V28_A) regulator, though
> >>there are calls for VMMC1 and VAUX3.
> >
> >I guess that's because the voltage is only configured if at least
> >one regulator consumer requests anything specific.
> >
>
> But then the board DTS is simply ignored. Doesn't look good :)
>
> >>So, it seems to me that V28_A is not enabled or correctly set-up
> >>and all devices connected to it does not function. And it looks
> >>like even after power-on VMMC2 is not correctly set-up - it is
> >>supposed to have voltage of 2.85V (10) but kernel leaves it to
> >>2.60V (8). However my twl-fu ends here so any help is appreciated.
> >
> >So in case of reboot from stock kernel voltage is already configured
> >to 2.8V, but it does not work, because of the sleep mode.
> >
>
> Yeah, that sleep is pretty clear, I was rather asking - "any idea how to fix
> that?". Or it is someone else expected to fix it?
You may have noticed, that I included Mark and Liam. I hope they
can give some feedback. I think there are two bugs:
1. twl_probe() should setup a default voltage based on DT
information.
2. if regulator is in sleep mode, regulator enable should
disable sleep mode.
-- Sebastian
Hi,
On Mon, Mar 21, 2016 at 01:04:18AM +0100, Sebastian Reichel wrote:
> On Sun, Mar 20, 2016 at 09:43:11PM +0200, Ivaylo Dimitrov wrote:
> > On 20.03.2016 07:17, Sebastian Reichel wrote:
> > >On Sat, Mar 19, 2016 at 10:49:57AM +0200, Ivaylo Dimitrov wrote:
> > >>On 18.03.2016 17:04, Sebastian Reichel wrote:
> > >>>On Fri, Mar 18, 2016 at 03:45:26PM +0200, Ivaylo Dimitrov wrote:
> > >>>>On 18.03.2016 15:36, Sebastian Reichel wrote:
> > >>>>Regulator is V28_A, which is always-on, so it is enabled no matter what
> > >>>>probe does. Anyway, I added a various delays after regulator_enable(), to no
> > >>>>success.
> > >>
> > >>I guess we're getting closer - I put some printks in various functions in
> > >>the twl-regulator.c, here is the result:
> > >>
> > >>on power-up:
> > >>
> > >>[ 2.378601] twl4030ldo_get_voltage_sel VMMC2 vsel 0x00000008
> > >>[ 2.384948] twl4030reg_enable VMMC2 grp 0x00000020
> > >>[ 2.408416] twl4030ldo_get_voltage_sel VMMC2 vsel 0x00000008
> > >>[ 7.196685] twl4030reg_is_enabled VMMC2 state 0x0000002e
> > >>[ 7.202819] twl4030reg_is_enabled VMMC2 state 0x0000002e
> > >>[ 7.209777] twl4030reg_is_enabled VMMC2 state 0x0000002e
> > >>[ 7.215728] twl4030reg_is_enabled VMMC2 state 0x0000002e
> > >>[ 7.223205] twl4030reg_is_enabled VMMC2 state 0x0000002e
> > >
> > >Ok, so normal power up results in running VMMC2 (always-on works),
> > >but voltage is not configured correctly. 2.6V is default according
> > >to the TRM. I think this is a "bug" in the regulator framework. It
> > >should setup the minimum allowed voltage before enabling the
> > >always-on regulator.
> > >
> >
> > /sys/kernel/debug/regulator/regulator_summary shows 2850mV for V28_A, so I
> > would remove the quotes. Also, always-on is because if V28_A regulator is
> > turned off, there is a leakage through tlv320aic34 VIO. BTW one of the
> > things I did while trying to find the problem, was to remove that always-on
> > property from the DTS - it didn't help.
>
> Right thinking about it, the voltage must also be configured for the
> non always-on cases. So it's not a problem with the regulator
> framework, but with twl-regulator's probe function, that should take
> care of this.
>
> > >In case of the tpa6130a2/tpa6140a2 driver it may also be nice to add
> > >something like this to the driver (Vdd may be between 2.5V and 5.5V
> > >according to both datasheets):
> > >
> > >if (regulator_can_change_voltage(data->supply))
> > > regulator_set_voltage(data->supply, 2500000, 5500000);
> > >
> >
> > and add DT property for that voltage range, as max output power and
> > harmonics depend on the supply voltage.
>
> I guess that's 2nd step.
>
> > >>after restart from stock kernel:
> > >>
> > >>[ 2.388610] twl4030ldo_get_voltage_sel VMMC2 vsel 0x0000000a
> > >>[ 2.394958] twl4030reg_enable VMMC2 grp 0x00000028
> > >
> > >I had a quick glance at this. I think stock kernel put VMMC2
> > >into sleep mode. Mainline kernel does not expect sleep mode
> > >being set and does not disable it.
> > >
> >
> > Well, one would think that kernel should not have expectations on what would
> > be the state of the hardware by the time it takes control over it, but setup
> > everything needed instead.
>
> I thought it's obvious, that this is not the desired behaviour :)
>
> > >>[ 2.418426] twl4030ldo_get_voltage_sel VMMC2 vsel 0x0000000a
> > >>[ 7.186645] twl4030reg_is_enabled VMMC2 state 0x00000020
> > >>[ 7.192718] twl4030reg_is_enabled VMMC2 state 0x00000020
> > >>[ 7.199615] twl4030reg_is_enabled VMMC2 state 0x00000020
> > >>[ 7.205535] twl4030reg_is_enabled VMMC2 state 0x00000020
> > >>[ 7.212951] twl4030reg_is_enabled VMMC2 state 0x00000020
> > >>
> > >>I don't see twl4030ldo_set_voltage_sel() for VMMC2(V28_A) regulator, though
> > >>there are calls for VMMC1 and VAUX3.
> > >
> > >I guess that's because the voltage is only configured if at least
> > >one regulator consumer requests anything specific.
> > >
> >
> > But then the board DTS is simply ignored. Doesn't look good :)
> >
> > >>So, it seems to me that V28_A is not enabled or correctly set-up
> > >>and all devices connected to it does not function. And it looks
> > >>like even after power-on VMMC2 is not correctly set-up - it is
> > >>supposed to have voltage of 2.85V (10) but kernel leaves it to
> > >>2.60V (8). However my twl-fu ends here so any help is appreciated.
> > >
> > >So in case of reboot from stock kernel voltage is already configured
> > >to 2.8V, but it does not work, because of the sleep mode.
> > >
> >
> > Yeah, that sleep is pretty clear, I was rather asking - "any idea how to fix
> > that?". Or it is someone else expected to fix it?
>
> You may have noticed, that I included Mark and Liam. I hope they
> can give some feedback. I think there are two bugs:
>
> 1. twl_probe() should setup a default voltage based on DT
> information.
I just had a look at the regulator core code. I think the voltage
should be set automatically during regulator_register():
regulator_register()
-> set_machine_constraints()
--> machine_constraints_voltage()
---> _regulator_do_set_voltage()
----> _regulator_call_set_voltage()
-----> ops->set_voltage()
Looks like this currently only works automatically, if DT specifies
min-voltage = max-voltage. Adding this to twl-regulator's probe
function before devm_regulator_register()) should enable the voltage
setting:
init_data->constraints.apply_uV = 1;
I hope Mark can tell us why this only done, when the voltage is fixed.
> 2. if regulator is in sleep mode, regulator enable should
> disable sleep mode.
Stroke that. It should be disabled in probe of course, since
it can be modified later using regulator_set_mode(). Actually
it is already supported by adding this to the omap3-n900.dts:
&vmmc2 {
regulator-initial-mode = <2>;
};
Ivo, Can you try if this fixes your problems with tpa6130a2 after
rebooting from Nokia kernel?
-- Sebastian
On Sun, Mar 20, 2016 at 06:17:04AM +0100, Sebastian Reichel wrote:
> On Sat, Mar 19, 2016 at 10:49:57AM +0200, Ivaylo Dimitrov wrote:
> > [ 7.215728] twl4030reg_is_enabled VMMC2 state 0x0000002e
> > [ 7.223205] twl4030reg_is_enabled VMMC2 state 0x0000002e
> Ok, so normal power up results in running VMMC2 (always-on works),
> but voltage is not configured correctly. 2.6V is default according
> to the TRM. I think this is a "bug" in the regulator framework. It
> should setup the minimum allowed voltage before enabling the
> always-on regulator.
No, if the voltage is variable we can't tell what the current
constraints are without something telling us so we just don't vary the
voltage until we're told to do this. If we immediately lower the
voltage to the minimum supported voltage that's going to break things.
> In case of the tpa6130a2/tpa6140a2 driver it may also be nice to add
> something like this to the driver (Vdd may be between 2.5V and 5.5V
> according to both datasheets):
> if (regulator_can_change_voltage(data->supply))
> regulator_set_voltage(data->supply, 2500000, 5500000);
This is completely broken. A consumer should never need to check to see
if the voltage can be varied and if the device doesn't actually need to
change the voltage as a part of the functionality it delivers then it
should just leave it up to the board constraints to set something, the
actual constaints will be much tighter than the device constraints and
there's a reasonable chance that there may be software compatible
variants of the device with different supply requirements.
On Mon, Mar 21, 2016 at 01:04:18AM +0100, Sebastian Reichel wrote:
> Right thinking about it, the voltage must also be configured for the
> non always-on cases. So it's not a problem with the regulator
> framework, but with twl-regulator's probe function, that should take
> care of this.
Absolutely not! Like all other regulator drivers the twl driver should
be taking no decisions about what voltage to set except in response to a
set_voltage() call. All the logic about setting voltages is factored
out into the core.
Please try to understand the abstractions we're using in the framework.
Hi,
On 21.03.2016 13:45, Mark Brown wrote:
>
> No, if the voltage is variable we can't tell what the current
> constraints are without something telling us so we just don't vary the
> voltage until we're told to do this. If we immediately lower the
> voltage to the minimum supported voltage that's going to break things.
>
There are constraints set by the board DTS. Isn't it reasonable the
framework to set the voltage to minimum voltage from the dts if the
current set one is bellow it?
Regards,
Ivo
On Mon, Mar 21, 2016 at 03:39:15PM +0200, Ivaylo Dimitrov wrote:
> On 21.03.2016 13:45, Mark Brown wrote:
> >No, if the voltage is variable we can't tell what the current
> >constraints are without something telling us so we just don't vary the
> >voltage until we're told to do this. If we immediately lower the
> >voltage to the minimum supported voltage that's going to break things.
> There are constraints set by the board DTS. Isn't it reasonable the
> framework to set the voltage to minimum voltage from the dts if the current
> set one is bellow it?
Yes, if it's out of bounds for the constraints we should bring it
up/down to the minimum/maximum (when copying people into a thread it's a
good idea to explain what the problem you are trying to solve is,
especially if you're throwing around bodges).
Hi Mark,
On Mon, Mar 21, 2016 at 01:45:15PM +0000, Mark Brown wrote:
> On Mon, Mar 21, 2016 at 03:39:15PM +0200, Ivaylo Dimitrov wrote:
> > On 21.03.2016 13:45, Mark Brown wrote:
>
> > >No, if the voltage is variable we can't tell what the current
> > >constraints are without something telling us so we just don't vary the
> > >voltage until we're told to do this. If we immediately lower the
> > >voltage to the minimum supported voltage that's going to break things.
>
> > There are constraints set by the board DTS. Isn't it reasonable the
> > framework to set the voltage to minimum voltage from the dts if the current
> > set one is bellow it?
>
> Yes, if it's out of bounds for the constraints we should bring it
> up/down to the minimum/maximum (when copying people into a thread it's a
> good idea to explain what the problem you are trying to solve is,
> especially if you're throwing around bodges).
We have this regulator definition in omap3-n900.dts:
&vmmc2 {
regulator-name = "V28_A";
regulator-min-microvolt = <2800000>;
regulator-max-microvolt = <3000000>;
regulator-always-on; /* due VIO leak to AIC34 VDDs */
};
The regulator is enabled during probe, but the voltage is not
configured. The default reset voltage of the regulator is 2.6V.
So basically when the regulator is enabled, it uses a voltage,
which is out of the DT specified range.
We also have a second problem: If the system has been rebooted from
Nokia's stock kernel the regulator is left in STANDBY mode. Since
the mode is not configured during probe, it results in different
problems. According to my understanding it can be fixed trivially
by adding
&vmmc2 {
regulator-initial-mode = <2>;
};
-- Sebastian
On 21.03.2016 16:53, Sebastian Reichel wrote:
> Hi Mark,
>
> On Mon, Mar 21, 2016 at 01:45:15PM +0000, Mark Brown wrote:
>> On Mon, Mar 21, 2016 at 03:39:15PM +0200, Ivaylo Dimitrov wrote:
>>> On 21.03.2016 13:45, Mark Brown wrote:
>>
>>>> No, if the voltage is variable we can't tell what the current
>>>> constraints are without something telling us so we just don't vary the
>>>> voltage until we're told to do this. If we immediately lower the
>>>> voltage to the minimum supported voltage that's going to break things.
>>
>>> There are constraints set by the board DTS. Isn't it reasonable the
>>> framework to set the voltage to minimum voltage from the dts if the current
>>> set one is bellow it?
>>
>> Yes, if it's out of bounds for the constraints we should bring it
>> up/down to the minimum/maximum (when copying people into a thread it's a
>> good idea to explain what the problem you are trying to solve is,
>> especially if you're throwing around bodges).
>
> We have this regulator definition in omap3-n900.dts:
>
> &vmmc2 {
> regulator-name = "V28_A";
> regulator-min-microvolt = <2800000>;
> regulator-max-microvolt = <3000000>;
> regulator-always-on; /* due VIO leak to AIC34 VDDs */
> };
>
> The regulator is enabled during probe, but the voltage is not
> configured. The default reset voltage of the regulator is 2.6V.
> So basically when the regulator is enabled, it uses a voltage,
> which is out of the DT specified range.
>
> We also have a second problem: If the system has been rebooted from
> Nokia's stock kernel the regulator is left in STANDBY mode. Since
> the mode is not configured during probe, it results in different
> problems. According to my understanding it can be fixed trivially
> by adding
>
> &vmmc2 {
> regulator-initial-mode = <2>;
> };
>
doesn't work:
"regulator-vmmc2: mapping for mode 2 not defined"
twl-regulator is missing .of_map_mode function.
Also, if we go that route, we should set the initial modes for all the
regulators, not only vmmc2 (and not only for N900), as we don't really
know what is the status of regulators at startup. I think a better
approach is if regulator framework sets all always-on regulators to
enabled, unless stated otherwise (which it already does iiuc).
I think there is a bug in twl-regulator twl4030reg_enable() and/or
twl4030reg_is_enabled() - the latter only checks if DEV_GRP is P1, but
not for the actual state of the regulator (bits 3:0). Also, what looks
suspicious to me is that all the regulators are put in P1 device group.
Legacy board code spreads the regulators all over the groups, so maybe
this is simply a regression compared to legacy boot.
Regards,
Ivo
On 21.03.2016 21:34, Ivaylo Dimitrov wrote:
>
>
> On 21.03.2016 16:53, Sebastian Reichel wrote:
>> Hi Mark,
>>
>> On Mon, Mar 21, 2016 at 01:45:15PM +0000, Mark Brown wrote:
>>> On Mon, Mar 21, 2016 at 03:39:15PM +0200, Ivaylo Dimitrov wrote:
>>>> On 21.03.2016 13:45, Mark Brown wrote:
>>>
>>>>> No, if the voltage is variable we can't tell what the current
>>>>> constraints are without something telling us so we just don't vary the
>>>>> voltage until we're told to do this. If we immediately lower the
>>>>> voltage to the minimum supported voltage that's going to break things.
>>>
>>>> There are constraints set by the board DTS. Isn't it reasonable the
>>>> framework to set the voltage to minimum voltage from the dts if the
>>>> current
>>>> set one is bellow it?
>>>
>>> Yes, if it's out of bounds for the constraints we should bring it
>>> up/down to the minimum/maximum (when copying people into a thread it's a
>>> good idea to explain what the problem you are trying to solve is,
>>> especially if you're throwing around bodges).
>>
>> We have this regulator definition in omap3-n900.dts:
>>
>> &vmmc2 {
>> regulator-name = "V28_A";
>> regulator-min-microvolt = <2800000>;
>> regulator-max-microvolt = <3000000>;
>> regulator-always-on; /* due VIO leak to AIC34 VDDs */
>> };
>>
>> The regulator is enabled during probe, but the voltage is not
>> configured. The default reset voltage of the regulator is 2.6V.
>> So basically when the regulator is enabled, it uses a voltage,
>> which is out of the DT specified range.
>>
>> We also have a second problem: If the system has been rebooted from
>> Nokia's stock kernel the regulator is left in STANDBY mode. Since
>> the mode is not configured during probe, it results in different
>> problems. According to my understanding it can be fixed trivially
>> by adding
>>
>> &vmmc2 {
>> regulator-initial-mode = <2>;
>> };
>>
>
> doesn't work:
>
> "regulator-vmmc2: mapping for mode 2 not defined"
>
> twl-regulator is missing .of_map_mode function.
>
> Also, if we go that route, we should set the initial modes for all the
> regulators, not only vmmc2 (and not only for N900), as we don't really
> know what is the status of regulators at startup. I think a better
> approach is if regulator framework sets all always-on regulators to
> enabled, unless stated otherwise (which it already does iiuc).
>
> I think there is a bug in twl-regulator twl4030reg_enable() and/or
> twl4030reg_is_enabled() - the latter only checks if DEV_GRP is P1, but
> not for the actual state of the regulator (bits 3:0). Also, what looks
> suspicious to me is that all the regulators are put in P1 device group.
> Legacy board code spreads the regulators all over the groups, so maybe
> this is simply a regression compared to legacy boot.
>
This is what seems to work, I would like some comments from those who
are more experienced with twl4030 than me before posting a formal patch.
I borrowed the code from stock Nokia kernel.
diff --git a/drivers/regulator/twl-regulator.c
b/drivers/regulator/twl-regulator.c
index 955a6fb..3740df4 100644
--- a/drivers/regulator/twl-regulator.c
+++ b/drivers/regulator/twl-regulator.c
@@ -21,7 +21,7 @@
#include <linux/regulator/machine.h>
#include <linux/regulator/of_regulator.h>
#include <linux/i2c/twl.h>
-
+#include <linux/delay.h>
/*
* The TWL4030/TW5030/TPS659x0/TWL6030 family chips include power
management, a
@@ -165,7 +165,7 @@ static int twl4030reg_is_enabled(struct
regulator_dev *rdev)
if (state < 0)
return state;
- return state & P1_GRP_4030;
+ return (state & 0x0f) != 0;
}
static int twl6030reg_is_enabled(struct regulator_dev *rdev)
@@ -188,11 +188,75 @@ static int twl6030reg_is_enabled(struct
regulator_dev *rdev)
return grp && (val == TWL6030_CFG_STATE_ON);
}
+static int twl4030_wait_pb_ready(void)
+{
+
+ int ret, timeout = 10;
+ u8 pb_state;
+
+ do {
+ ret = twl_i2c_read_u8(TWL_MODULE_PM_MASTER, &pb_state,
+ TWL4030_PM_MASTER_PB_CFG);
+ if (ret < 0)
+ return ret;
+
+ if (!(pb_state & 1))
+ return 0;
+
+ mdelay(1);
+ timeout--;
+
+ } while (timeout);
+
+ return -ETIMEDOUT;
+}
+
+static int twl4030_send_pb_msg(unsigned msg)
+{
+ u8 pb_state;
+ int ret;
+
+ /* save powerbus configuration */
+ ret = twl_i2c_read_u8(TWL_MODULE_PM_MASTER, &pb_state,
+ TWL4030_PM_MASTER_PB_CFG);
+ if (ret < 0)
+ return ret;
+
+ /* Enable I2C access to powerbus */
+ ret = twl_i2c_write_u8(TWL_MODULE_PM_MASTER, pb_state | BIT(1),
+ TWL4030_PM_MASTER_PB_CFG);
+ if (ret < 0)
+ return ret;
+
+ ret = twl4030_wait_pb_ready();
+ if (ret < 0)
+ return ret;
+
+ ret = twl_i2c_write_u8(TWL_MODULE_PM_MASTER, msg >> 8,
+ TWL4030_PM_MASTER_PB_WORD_MSB);
+ if (ret < 0)
+ return ret;
+
+ ret = twl_i2c_write_u8(TWL_MODULE_PM_MASTER, msg & 0xff,
+ TWL4030_PM_MASTER_PB_WORD_LSB);
+ if (ret < 0)
+ return ret;
+
+ ret = twl4030_wait_pb_ready();
+ if (ret < 0)
+ return ret;
+
+ /* Restore powerbus configuration */
+ return twl_i2c_write_u8(TWL_MODULE_PM_MASTER, pb_state,
+ TWL_MODULE_PM_MASTER);
+}
+
static int twl4030reg_enable(struct regulator_dev *rdev)
{
struct twlreg_info *info = rdev_get_drvdata(rdev);
int grp;
int ret;
+ unsigned message;
grp = twlreg_grp(rdev);
if (grp < 0)
@@ -201,8 +265,12 @@ static int twl4030reg_enable(struct regulator_dev
*rdev)
grp |= P1_GRP_4030;
ret = twlreg_write(info, TWL_MODULE_PM_RECEIVER, VREG_GRP, grp);
+ if (ret < 0)
+ return ret;
- return ret;
+ message = MSG_SINGULAR(DEV_GRP_P1, info->id, RES_STATE_ACTIVE);
+
+ return twl4030_send_pb_msg(message);
}
static int twl6030reg_enable(struct regulator_dev *rdev)
@@ -324,13 +392,7 @@ static int twl4030reg_set_mode(struct regulator_dev
*rdev, unsigned mode)
if (!(status & (P3_GRP_4030 | P2_GRP_4030 | P1_GRP_4030)))
return -EACCES;
- status = twl_i2c_write_u8(TWL_MODULE_PM_MASTER,
- message >> 8, TWL4030_PM_MASTER_PB_WORD_MSB);
- if (status < 0)
- return status;
-
- return twl_i2c_write_u8(TWL_MODULE_PM_MASTER,
- message & 0xff, TWL4030_PM_MASTER_PB_WORD_LSB);
+ return twl4030_send_pb_msg(message);
}
static int twl6030reg_set_mode(struct regulator_dev *rdev, unsigned mode)
Regards,
Ivo
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.
--
Pali Rohár
[email protected]