* Sebastian Andrzej Siewior <bigeasy@xxxxxxxxxxxxx> [140710 08:50]: > On 07/10/2014 09:09 AM, Tony Lindgren wrote: > > You can test this pretty easily on beagleboard xm for example > > using v3.16-r4: > > I tried this with am335x-evm, dra7-evm and beaglebone (omap5-uevm and > am335x-evmsk didn't want to boot a kernel and omap4-blaze didn't even > want to show MLO/U-boot) with the same result. None of these SoCs support off-idle with mainline kernel so testing with those is not enough :) Best to use some omap3 based device for testing this. So far I have verified that beagleboard xm, n900, and omap3730-evm all hit off-idle with v3.16-rc4. > > 1. Compile the kernel using omap2plus_defconfig and enable your > > driver. USB EHCI needs to be disabled and OTG port should > > not have a USB cable connected. > > EHCI was already disabled in the config. OTG was not connected. OK > > 2. Boot with init=/bin/sh to keep user space timers to minimum > > at least until you have verified to hit off-idle > > I had network up and configured. Was that okay? I also tried > "ifconfig eth0 down; sleep 10; ifconfig eth0 up" to see if it works. That's fine for GPMC connected devices, devices with Ethernet on EHCI won't idle properly AFAIK. > > 3. Enable UART timeouts with something like this. You may need > > to update it for ttyS, I just changed ttyO to ttyS here: > > > > #!/bin/bash > > uarts=$(find /sys/class/tty/ttyS*/device/power/ -type d) > > for uart in $uarts; do > > echo 3000 > $uart/autosuspend_delay_ms > > done > > > > uarts=$(find /sys/class/tty/ttyS*/power/ -type d) > > for uart in $uarts; do > > echo enabled > $uart/wakeup > > echo auto > $uart/control > > done > > > > echo 1 > /sys/kernel/debug/pm_debug/enable_off_mode > > > > 4. Wait for UART to time out and verify you hit off-idle by > > looking at the debugfs entry: > > > > # cat /sys/kernel/debug/pm_debug/count > > ... > > core_pwrdm (ON),OFF:6,RET:0,INA:0,ON:7,RET-LOGIC-OFF:0,RET-MEMBANK1-OFF:0,RET-MEMBANK2-OFF:0 > > That core_pwrdm shows only up on dra7. However with both drivers (mine > and the current omap serial) the UART went down after three secs (as > expected) and didn't accept any characters while writing on the > console. If I wrote something on it via network (like echo a > > /dev/ttyO0) it came back and was working as long as I kept it busy. The > thing is that RX does not wake it up. Any idea? If the RX pin does not wake it up, you need to configure the pinctrl-single entry for it, and configure that pin as a wake-up interrupt. See the interrupts-extended entry in omap3-beagle-xm.dts. > Also, while it was I checked the core_pwrdm and I had ON:1 and OFF:0. > So something is not right. > Since Dra7 has some things missing I tried it on am335x with the same > behavior. Should it work here? Yes only omap3 currently has the pieces needed for off-idle in the mainline kernel. > > I just tried testing this, but did not get far on my omap3 evm: > > > > [ 5.445953] Unhandled fault: external abort on non-linefetch (0x1028) at 0xfb020000 > > [ 5.453674] Internal error: : 1028 [#1] SMP ARM > > [ 5.458221] Modules linked in: > > [ 5.461334] CPU: 0 PID: 1 Comm: swapper/0 Not tainted 3.16.0-rc4-00006-gaab2c6a #98 > > [ 5.469024] task: ce058b00 ti: ce05a000 task.ti: ce05a000 > > [ 5.474456] PC is at mem32_serial_in+0xc/0x1c > > [ 5.478851] LR is at serial8250_do_startup+0xc8/0x89c > > [ 5.483917] pc : [<c0346f90>] lr : [<c034ab2c>] psr: 60000113 > > [ 5.483917] sp : ce05bd10 ip : c0a0aba8 fp : ce275400 > > [ 5.495452] r10: 00000000 r9 : cda7a680 r8 : ce27568c > > [ 5.500701] r7 : ce275400 r6 : 00000000 r5 : ce280408 r4 : c10b6234 > > [ 5.507263] r3 : fb020000 r2 : 00000002 r1 : fb020000 r0 : c10b6234 > > [ 5.513854] Flags: nZCv IRQs on FIQs on Mode SVC_32 ISA ARM Segment kernel > > [ 5.521179] Control: 10c5387d Table: 80004019 DAC: 00000015 > > [ 5.526977] Process swapper/0 (pid: 1, stack limit = 0xce05a248) > > [ 5.532989] Stack: (0xce05bd10 to 0xce05c000) > > ... > > [ 5.734771] [<c0346f90>] (mem32_serial_in) from [<c034ab2c>] (serial8250_do_startup+0xc8/0x89c) > > [ 5.743530] [<c034ab2c>] (serial8250_do_startup) from [<c03461f8>] (uart_startup.part.3+0x7c/0x1dc) > > [ 5.752624] [<c03461f8>] (uart_startup.part.3) from [<c0346d68>] (uart_open+0xe4/0x124) > > [ 5.760681] [<c0346d68>] (uart_open) from [<c032c19c>] (tty_open+0x130/0x58c) > > [ 5.767852] [<c032c19c>] (tty_open) from [<c01216f4>] (chrdev_open+0x9c/0x174) > > [ 5.775115] [<c01216f4>] (chrdev_open) from [<c011b8d4>] (do_dentry_open+0x1d0/0x310) > > [ 5.783020] [<c011b8d4>] (do_dentry_open) from [<c011bd98>] (finish_open+0x34/0x4c) > > [ 5.790710] [<c011bd98>] (finish_open) from [<c012a8f8>] (do_last.isra.27+0x5a4/0xb98) > > [ 5.798675] [<c012a8f8>] (do_last.isra.27) from [<c012afa0>] (path_openat+0xb4/0x5e4) > > [ 5.806549] [<c012afa0>] (path_openat) from [<c012b7dc>] (do_filp_open+0x2c/0x80) > > [ 5.814086] [<c012b7dc>] (do_filp_open) from [<c011cd14>] (do_sys_open+0x100/0x1d0) > > [ 5.821777] [<c011cd14>] (do_sys_open) from [<c07b7ce0>] (kernel_init_freeable+0x124/0x1c8) > > [ 5.830200] [<c07b7ce0>] (kernel_init_freeable) from [<c054eb90>] (kernel_init+0x8/0xe4) > > [ 5.838348] [<c054eb90>] (kernel_init) from [<c000e868>] (ret_from_fork+0x14/0x2c) > > > > Sounds like the clocks are not enabled properly? > > puh. So after staring a while at your backtrace I realized that > shutdown & startup callbacks are not overwritten properly. Well, thanks > for that. Anyway, even serial8250_do_startup() has > pm_runtime_get_sync() before first register access so I have no idea > where this is coming from. Maybe because the console is enabled for that port? Regards, Tony -- To unsubscribe from this list: send the line "unsubscribe linux-serial" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
