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. > 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. > 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. > 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? 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? > ... > > 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. > > Regards, > > Tony > Sebastian -- 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
