* Sebastian Andrzej Siewior [off-list ref] [140710 08:50]:

On 07/10/2014 09:09 AM, Tony Lindgren wrote:

quoted

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.
 

quoted

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
 

quoted

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.
 

quoted

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.
 

quoted

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