MFD USB host: prevents CORE retention in idle

Hi Keshava,

Using current l-o master, I noticed that CORE was not hitting retention in idle on my 3530/Overo. CORE hits retention on suspend just fine.

Debugging this, I found that usbtll_fck was still enabled during idle, thus preventing CORE from hitting retention.

To test, I disabled USB host (CONFIG_MFD_OMAP_USB_HOST=n in .config) and was then started seeing CORE hit retention in idle again.

I have nothing plugged into the USB host port on this board, so I would've expected that runtime PM would've kicked in and shutdown this clock.

Any ideas what's going on here? Is this expected behavior?

Quoted 9 lines · Kevin Hilman

Hi Keshava,

Using current l-o master, I noticed that CORE was not hitting retention in idle on my 3530/Overo.  CORE hits retention on suspend just fine.

Debugging this, I found that usbtll_fck was still enabled during idle, thus preventing CORE from hitting retention.

Quoted 9 lines

To test, I disabled USB host (CONFIG_MFD_OMAP_USB_HOST=n in .config) and was then started seeing CORE hit retention in idle again.

I have nothing plugged into the USB host port on this board, so I would've expected that runtime PM would've kicked in and shutdown this clock.

Any ideas what's going on here?  Is this expected behavior?

If it helps, attached is a bootlog after enabling debug for mfd/omap-usb-host.c as well.  Notice there's a couple of clock-related warnings from this driver as well.  Not sure if they're relevant:

usbhs_omap: alias fck already exists
usbhs_omap usbhs_omap: xclk60mhsp2_ck set parentfailed error:-22

With debug enabled, I see the runtime resume during init followed by the runtime suspend.

[    0.936248] usbhs_omap usbhs_omap: xclk60mhsp2_ck set parentfailed error:-22
[    0.944152] usbhs_omap usbhs_omap: starting TI HSUSB Controller [    0.944335] usbhs_omap usbhs_omap: usbhs_runtime_resume [    0.944641] usbhs_omap usbhs_omap: OMAP UHH_REVISION 0x10 [    0.944641] usbhs_omap usbhs_omap: OMAP3 ES version > ES2.1 [    0.944671] usbhs_omap usbhs_omap: UHH setup done,ry uhh_hostconfig=8000121d
[    0.947082] usbhs_omap usbhs_omap: usbhs_runtime_suspend

However, later in the boot I see a runtime_resume and never see another suspend.  That seems to be the root cause of CORE not hitting retention.

From the boot log:

[    2.018707] ehci_hcd: USB 2.0 'Enhanced' Host Controller (EHCI) Driver [    2.025787] ehci_hcd: block sizes: qh 64 qtd 96 itd 160 sitd 96 [    2.026306] ehci-omap ehci-omap.0: failed to get ehci port1 regulator [    2.026519] usbhs_omap usbhs_omap: usbhs_runtime_resume
[    3.030639] ehci-omap ehci-omap.0: phy reset operation timed out [    3.030700] ehci-omap ehci-omap.0: reset hcs_params 0x1313 dbg=0 cc=1 pcc=3 ordered ports=3
[    3.030731] ehci-omap ehci-omap.0: reset hcc_params 0016 thresh 1 uframes 256/512/1024 park
[    3.030761] ehci-omap ehci-omap.0: reset command 0080b02  park=3 ithresh=8 period=1024 Reset HALT
[    3.030792] ehci-omap ehci-omap.0: OMAP-EHCI Host Controller

Since the only get/puts I see are in omap_usbhs_init(), I'm not sure how this driver is being runtime resumed.  Presumably it's due to how the rest of the USB stack works, which I'm not at all familiar with.

Hopefully, the above is enough to debug the problem,

Thanks,

Kevin

Quoted 24 lines · Kevin Hilman

Quoted 9 lines · Kevin Hilman

Hi Keshava,

Using current l-o master, I noticed that CORE was not hitting retention in idle on my 3530/Overo.  CORE hits retention on suspend just fine.

Debugging this, I found that usbtll_fck was still enabled during idle, thus preventing CORE from hitting retention.

Quoted 9 lines

To test, I disabled USB host (CONFIG_MFD_OMAP_USB_HOST=n in .config) and was then started seeing CORE hit retention in idle again.

I have nothing plugged into the USB host port on this board, so I would've expected that runtime PM would've kicked in and shutdown this clock.

Any ideas what's going on here?  Is this expected behavior?

If it helps, attached is a bootlog after enabling debug for mfd/omap-usb-host.c as well.  Notice there's a couple of clock-related warnings from this driver as well.  Not sure if they're relevant:

Quoted 2 lines

usbhs_omap: alias fck already exists
usbhs_omap usbhs_omap: xclk60mhsp2_ck set parentfailed error:-22

these clocks were specific to omap4 and it should not cause any problem to omap3 boards.

I will try to reproduce this on 3430 sdp to explore further.

Quoted 25 lines · Keshava

Quoted 24 lines · Kevin Hilman

Quoted 9 lines · Kevin Hilman

Hi Keshava,

Using current l-o master, I noticed that CORE was not hitting retention in idle on my 3530/Overo.  CORE hits retention on suspend just fine.

Debugging this, I found that usbtll_fck was still enabled during idle, thus preventing CORE from hitting retention.

Quoted 9 lines

To test, I disabled USB host (CONFIG_MFD_OMAP_USB_HOST=n in .config) and was then started seeing CORE hit retention in idle again.

I have nothing plugged into the USB host port on this board, so I would've expected that runtime PM would've kicked in and shutdown this clock.

Any ideas what's going on here?  Is this expected behavior?

If it helps, attached is a bootlog after enabling debug for mfd/omap-usb-host.c as well.  Notice there's a couple of clock-related warnings from this driver as well.  Not sure if they're relevant:

Quoted 5 lines

Quoted 2 lines

usbhs_omap: alias fck already exists
usbhs_omap usbhs_omap: xclk60mhsp2_ck set parentfailed error:-22

these clocks were specific to omap4 and it should not cause any problem to omap3 boards.

OK, they seem unrelated to this CORE retention problem, but the warnings should still be understood and fixed.

Quoted 1 line

I will try to reproduce this on 3430 sdp to explore further.

Thanks for looking. Note that I only saw this problem on my 3530 platforms (Overo, OMAP3EVM.) My 3430/n900 doesn't support USBHS host AFAICT, so didn't test there.

Quoted 33 lines · Kevin Hilman

Quoted 25 lines · Keshava

Quoted 24 lines · Kevin Hilman

Quoted 9 lines · Kevin Hilman

Hi Keshava,

Using current l-o master, I noticed that CORE was not hitting retention in idle on my 3530/Overo. CORE hits retention on suspend just fine.

Debugging this, I found that usbtll_fck was still enabled during idle, thus preventing CORE from hitting retention.

Quoted 9 lines

To test, I disabled USB host (CONFIG_MFD_OMAP_USB_HOST=n in .config) and was then started seeing CORE hit retention in idle again.

I have nothing plugged into the USB host port on this board, so I would've expected that runtime PM would've kicked in and shutdown this clock.

Any ideas what's going on here? Is this expected behavior?

If it helps, attached is a bootlog after enabling debug for mfd/omap-usb-host.c as well. Notice there's a couple of clock-related warnings from this driver as well. Not sure if they're relevant:

Quoted 5 lines

Quoted 2 lines

usbhs_omap: alias fck already exists
usbhs_omap usbhs_omap: xclk60mhsp2_ck set parentfailed error:-22

these clocks were specific to omap4 and it should not cause any problem to omap3 boards.

Quoted 8 lines

OK, they seem unrelated to this CORE retention problem, but the warnings should still be understood and fixed.

Quoted 1 line

I will try to reproduce this on 3430 sdp to explore further.

Thanks for looking. Note that I only saw this problem on my 3530 platforms (Overo, OMAP3EVM.) My 3430/n900 doesn't support USBHS host AFAICT, so didn't test there.

After realizing that the same IP should exist on 3430/n900, I copied some board file support for USBHS host from overo into the n900 board file in order to test on 3430/n900.

Problem exists on n900 too.

Kevin
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html

hi kevin
        now I am using initramfs with kernel linux3.5.rc1, but the retention is not working in 3430 sdp.  I am seeing the following error followed by a crash

echo mem > /sys/power/state
[   35.609252] PM: Syncing filesystems ... done.
[   35.614654] PM: Preparing system for mem sleep
[   35.658630] Freezing user space processes ... (elapsed 0.01 seconds) done.
[   35.689727] Freezing remaining freezable tasks ... (elapsed 0.02 seconds) done.
[   35.697692] PM: Entering mem sleep
[   35.722442] usb usb1: usb auto-resume
[   35.726409] ehci-omap ehci-omap.0: resume root hub
[   35.775451] hub 1-0:1.0: hub_resume
[   35.779846] hub 1-0:1.0: hub_suspend
[   35.784240] usb usb1: bus suspend, wakeup 0
[   35.788665] ehci-omap ehci-omap.0: suspend root hub
[   35.805786] PM: suspend of devices complete after 99.304 msecs [   35.816497] PM: late suspend of devices complete after 4.364 msecs [   35.831573] PM: noirq suspend of devices complete after 8.331 msecs [   35.838500] Disabling non-boot CPUs ...
[   36.312164] Powerdomain (core_pwrdm) didn't enter target state 1 [   36.318481] Could not enter target state in pm_suspend
[   36.324859] Unable to handle kernel NULL pointer dereference at virtual address 00000018
[   36.333557] pgd = c6280000
[   36.336639] [00000018] *pgd=85c8f831, *pte=00000000, *ppte=00000000 [   36.343414] Internal error: Oops: 17 [#1] SMP ARM
[   36.348388] Modules linked in:
[   36.351623] CPU: 0    Tainted: G        W     (3.5.0-rc1 #1) [   36.357574] PC is at _od_resume_noirq+0x14/0x58
[   36.362365] LR is at dpm_run_callback+0x2c/0x74
[   36.367126] pc : [<c003c150>]    lr : [<c02d75e4>]    psr: a0000013 [   36.367126] sp : c5ebfe80  ip : c0a72fc0  fp : 00000006
[   36.379150] r10: c78af4b8  r9 : c0a3607c  r8 : c003c13c
[   36.384643] r7 : 00000000  r6 : 00000000  r5 : c78af408  r4 : c78af408 [   36.391479] r3 : 00000000  r2 : 00000000  r1 : c78af408  r0 : c78af400 [   36.398315] Flags: NzCv  IRQs on  FIQs on  Mode SVC_32  ISA ARM  Segment user
[   36.405792] Control: 10c5387d  Table: 86280019  DAC: 00000015 [   36.411834] Process sh (pid: 1254, stack limit = 0xc5ebe2f8) [   36.417785] Stack: (0xc5ebfe80 to 0xc5ec0000)
[   36.422363] fe80: c78af408 c02d75e4 c0a36020 c0a36040 00000000 00000000 c78af408 c0f9e4a8
[   36.430938] fea0: 00000010 c0a36014 c0a36074 c02d8178 58566b0d 00000008 58566b0d 00000008
[   36.439514] fec0: c0a1df38 00000010 ffffffff 00000003 c0a4d11c 00000000 00000000 c09da45c
[   36.448089] fee0: 000ed008 c02d8a14 c0a62c28 c0080360 00000003 c05b9ce8 00000000 00000004
[   36.456665] ff00: 00000000 c04c9704 c78012c0 c00806a4 c5c8e000 00000003 c05b9ce8 c007f8a8
[   36.465240] ff20: c5c8d4c0 c5c8d4d8 c5ebff80 c7863e00 c02674a8 c02674c0 00000004 c016d7fc
[   36.473815] ff40: c5d94a80 00000004 b6ff6000 c5ebff80 00000000 00000000 00000000 c010c244
[   36.482421] ff60: c0014400 c5c92280 c5d94a80 b6ff6000 00000004 00000004 00000000 c010c398
[   36.490997] ff80: 00000000 00000000 b6f235e8 00000000 00000004 b6ff6000 b6f235e8 c00144a8
[   36.499572] ffa0: c5ebe000 c00142e0 00000004 b6ff6000 00000001 b6ff6000 00000004 00000000
[   36.508148] ffc0: 00000004 b6ff6000 b6f235e8 00000004 00000004 00000964 0000000a 000ed008
[   36.516723] ffe0: b6ff6000 bee815d0 b6e61c70 b6eb1abc 60000010 00000001 00000000 00000000
[   36.525360] [<c003c150>] (_od_resume_noirq+0x14/0x58) from [<c02d75e4>] (dpm_run_callback+0x2c/0x74)
[   36.534973] [<c02d75e4>] (dpm_run_callback+0x2c/0x74) from [<c02d8178>] (dpm_resume_noirq+0xdc/0x2f4)
[   36.544677] [<c02d8178>] (dpm_resume_noirq+0xdc/0x2f4) from [<c02d8a14>] (dpm_resume_start+0xc/0x18)
[   36.554290] [<c02d8a14>] (dpm_resume_start+0xc/0x18) from [<c0080360>] (suspend_devices_and_enter+0x114/0x2d8)
[   36.564819] [<c0080360>] (suspend_devices_and_enter+0x114/0x2d8) from [<c00806a4>] (pm_suspend+0x180/0x1fc)
[   36.575042] [<c00806a4>] (pm_suspend+0x180/0x1fc) from [<c007f8a8>] (state_store+0x90/0x124)
[   36.583953] [<c007f8a8>] (state_store+0x90/0x124) from [<c02674c0>] (kobj_attr_store+0x18/0x1c)
[   36.593109] [<c02674c0>] (kobj_attr_store+0x18/0x1c) from [<c016d7fc>] (sysfs_write_file+0xfc/0x180)
[   36.602722] [<c016d7fc>] (sysfs_write_file+0xfc/0x180) from [<c010c244>] (vfs_write+0xb0/0x134)
[   36.611877] [<c010c244>] (vfs_write+0xb0/0x134) from [<c010c398>] (sys_write+0x40/0x70)
[   36.620300] [<c010c398>] (sys_write+0x40/0x70) from [<c00142e0>] (ret_fast_syscall+0x0/0x3c)
[   36.629180] Code: e1a04000 e2500008 01a02000 15902248 (e5d23018) [   36.635833] ---[ end trace b3b167c1e86e5512 ]---

which kernel version are you using? do you have any good commit on which retention works because of usb host?

regards
keshava

Quoted 712 lines · Keshava

yes! I am using the ramfs.

regards
keshava

Quoted 703 lines · Kevin Hilman

Quoted 4 lines · Keshava

   hi Ameya
        I was trying to reproduce the 3430 usb pm issues ; but i see that
   NFS is not working in 3430 sdp;

You don't need NFS to reproduce this.  If you can't get NFS to work, just use a busybox initramfs.

This bug needs to be fixed for v3.5-rc.

Kevin

Quoted 688 lines

   it is because of the following the UART patch series (21 patch). I couldn't able to figure out the actual patch which breaks NFS because individual patches in this series does not compile.
   these patches are already in lo master.
   here is the patch list:

 -----------------------------------------------------------------------
   ------------------------------------------------------------------
   commit da27468655540b083525177f5dc6f3b1f6e3b869
   Author: Govindraj.R <[email protected]>
   Date:   Wed Dec 14 21:24:11 2011 +0530
       ARM: OMAP2+: UART: Fix compilation/sparse warnings

       Fixes below compilation warning.

       drivers/tty/serial/omap-serial.c: In function 'serial_omap_irq':
       drivers/tty/serial/omap-serial.c:228:29: warning: 'ch' may be used
   uninitialized in this function [-Wuninitialized]

       Fix below sparse warning.

       drivers/tty/serial/omap-serial.c:392:52: warning: incorrect type in
   argument 2 (different signedness) drivers/tty/serial/omap-serial.c:392:52:    expected int *status drivers/tty/serial/omap-serial.c:392:52:    got unsigned int *<noident>

Reported-by Kevin Hilman <[email protected]>

Signed-off-by Govindraj.R <[email protected]>

Acked-by Greg Kroah-Hartman <[email protected]> (for drivers/tty

   changes)

Signed-off-by Kevin Hilman <[email protected]>

   commit 2fd149645eb46d26130d7070c6de037dddf34880
   Author: Govindraj.R <[email protected]>
   Date:   Wed Nov 9 17:41:21 2011 +0530
       ARM: OMAP2+: UART: Remove omap_uart_can_sleep and add pm_qos

       Omap_uart_can_sleep function blocks system wide low power state until
       uart is active remove this func and add qos requests to prevent MPU from transitioning.

       Keep qos request to default value which will allow MPU to transition
       and while uart baud rate is available calculate the latency value
       from the baudrate and use the same to hold constraint while uart clocks
       are enabled, and if uart is auto-idled the constraint is updated with
       default constraint value allowing MPU to transition.

       Qos requests are blocking notifier calls so put these requests to
       work queue, also the driver uses irq_safe version of runtime API's
       and callbacks can be called in interrupt disabled context. So to avoid warn on slow path warning while using qos update API's from runtime callbacks use the qos_work_queue.

       During bootup the runtime_resume call backs might not be called and
   runtime
       callback gets called only after uart is idled by setting the autosuspend
       timeout. So qos_request from runtime resume callback might not activated during
       boot if uart baudrate is calculated during bootup for console uart,
   so schedule
       the qos_work queue once we calc_latency while configuring the uart
   port.

       Flush and complete any pending qos jobs in work queue while suspending.

Signed-off-by Govindraj.R <[email protected]>

Acked-by Greg Kroah-Hartman <[email protected]> (for drivers/tty

   changes)

Signed-off-by Kevin Hilman <[email protected]>

   commit 36fc2d15b120ef85be74c68b5ad74ac04fbefa8a
   Author: Govindraj.R <[email protected]>
   Date:   Wed Sep 21 16:54:12 2011 +0530
       ARM: OMAP2+: UART: Do not gate uart clocks if used for debug_prints

       If OMAP UART is used as console uart and debug is enabled, avoid gating of uart clocks to print all debug prints.

       If uart clocks are gated then the debug prints from omap_device framework or hwmod framework can cause uart to enter recursive pm_runtime calls, which can cause a deadlock over power lock usage.

       For example: Say, uart clocks are cut and we get a print from omap_device_disable stating disabling uart clocks. This print calls omap_uart driver console_write which will call runtime API get_sync which means we enter from runtime API put context to runtime API get context.

       --> runtime put (take power lock)
           --> print disabling uart clocks
               --> call uart console write
                   --> call get_sync (try to take power lock)

       Also any clock enable API call from uart driver should not call any
   uart
       operation until clocks are enabled back. Like get_sync having debug
   print
       calling uart console write even before clocks are enabled.

       So to avoid these scenarios, identify from bootargs if OMAP_UART(ttyO) is used
       in debug mode. If so, do not set device_may_wakeup. This will prevent
       pm_runtime_enable in uart driver and will avoid uart clock gating.
       Debug is enabled either by adding debug word in bootarg or by setting
       loglevel=10

Signed-off-by Govindraj.R <[email protected]>

Signed-off-by Kevin Hilman <[email protected]>

   commit 08f86b3eab9807e6d36de7e00025abad893ff557
   Author: Govindraj.R <[email protected]>
   Date:   Tue Oct 18 17:09:10 2011 +0530
       ARM: OMAP2+: UART: Avoid uart idling on suspend for no_console_suspend usecase

       If no_console_suspend is used we have prevent uart idling during suspend
       to provide debug prints.

       Power domain hooks can idle uarts if left enabled during system wide suspend
       so re-use the omap_device_disable_idle_on_suspend API's to ensure
   console_uart
       is not idled during suspend.

       omap_device_disable_idle_on_suspend API was used on all uarts since
   the uart
       driver was not runtime adapted, now with runtime adaptation we can
   re-use this
       API only for no_console_suspend use cases.

Signed-off-by Govindraj.R <[email protected]>

Signed-off-by Kevin Hilman <[email protected]>

   commit 8612bd22f30369745d0fda0d540aca39ab591cc5
   Author: Govindraj.R <[email protected]>
   Date:   Mon Nov 7 19:05:44 2011 +0530
       ARM: OMAP2+: UART: Avoid console uart idling during bootup

       Omap-uart can be used as console uart to print early boot messages
   using
       earlyprintk so for console uart prevent hwmod reset or idling during bootup.

       Identify omap-uart used as console and avoid idling rather than preventing
       all omap-uarts from idling during bootup. Update the comments for
   the same.

       Remove the uart idling and enabling back using hwmod_idle/omap_device_enable
       for all uarts that where left enabled from boot to set the hwmod framework
       state machine right. This need not be taken care any more serial.c
   rather
       can be handled within the hwmod framework.
       Reference: http://www.spinics.net/lists/linux-omap/msg60300.html

Signed-off-by Govindraj.R <[email protected]>

Signed-off-by Kevin Hilman <[email protected]>

   commit 969996a57fd2345a1141280dddcf9e10fa5f6690
   Author: Govindraj.R <[email protected]>
   Date:   Tue Oct 18 16:32:14 2011 +0530
       ARM: OMAP2+: UART: remove temporary variable used to count uart instance

       Reuse the num_uarts variable itself to count number of uarts.

Signed-off-by Govindraj.R <[email protected]>

Signed-off-by Kevin Hilman <[email protected]>

   commit a9e210e0b7a344c0e44aa6bf6888176bbc635c42
   Author: Jon Hunter <[email protected]>
   Date:   Wed Nov 9 17:34:49 2011 +0530
       ARM: OMAP2+: UART: Make the RX_TIMEOUT for DMA configurable for each UART

       When using DMA there are two timeouts defined. The first timeout,
       rx_timeout, is really a polling rate in which software polls the DMA status to see if the DMA has finished. This is necessary for the RX side because we do not know how much data we will receive.
       The secound timeout, RX_TIMEOUT, is a timeout after which the DMA will be stopped if no more data is received. To make this clearer, rename rx_timeout as rx_poll_rate and rename the function serial_omap_rx_timeout() to serial_omap_rxdma_poll().

       The OMAP-Serial driver defines an RX_TIMEOUT of 3 seconds that is
       used to indicate when the DMA for UART can be stopped if no more data is received. The value is a global definition that is applied
       to all instances of the UART.

       Each UART may be used for a different purpose and so the timeout required may differ. Make this value configurable for each UART so
       that this value can be optimised for power savings.

Signed-off-by Jon Hunter <[email protected]>

Signed-off-by Govindraj.R <[email protected]>

Acked-by Greg Kroah-Hartman <[email protected]> (for drivers/tty

   changes)

Signed-off-by Kevin Hilman <[email protected]>

   commit c86845db77ce220f77e6645b18800744684946ac
   Author: Deepak K <[email protected]>
   Date:   Wed Nov 9 17:33:38 2011 +0530
       ARM: OMAP2+: UART: Allow UART parameters to be configured from board file.

       The following UART parameters are defined within the UART driver:

       1). Whether the UART uses DMA (dma_enabled), by default set to 0 2). The size of dma buffer (set to 4096 bytes)
       3). The time after which the dma should stop if no more data is received.
       4). The auto suspend delay that will be passed for pm_runtime_autosuspend
           where uart will be disabled after timeout

       Different UARTs may be used for different purpose such as the console,
       for interfacing bluetooth chip, for interfacing to a modem chip, etc.
       Therefore, it is necessary to be able to customize the above settings
       for a given board on a per UART basis.

       This change allows these parameters to be configured from the board
   file
       and allows the parameters to be configured for each UART independently.

       If a board does not define its own custom parameters for the UARTs,
   then
       use the default parameters in the structure "omap_serial_default_info".
       The default parameters are defined to be the same as the current settings
       in the UART driver to avoid breaking the UART for any cuurnelty supported
       boards. By default, make all boards use the default UART parameters.

Signed-off-by Deepak K <[email protected]>

Signed-off-by Jon Hunter <[email protected]>

Signed-off-by Govindraj.R <[email protected]>

Acked-by Greg Kroah-Hartman <[email protected]> (for drivers/tty

   changes)

Signed-off-by Kevin Hilman <[email protected]>

   commit 634bd6e4817cd6a7109be8d2eee5c578a283d1ee
   Author: Govindraj.R <[email protected]>
   Date:   Mon Nov 7 19:01:24 2011 +0530
       ARM: OMAP2+: UART: Remove old and unused clocks handling funcs

       With runtime adaptation done remove clock_enable/disbale API's

Signed-off-by Govindraj.R <[email protected]>

Signed-off-by Kevin Hilman <[email protected]>

   commit 62f3ec5fbd5fddce62b7a71adc04723a5eb903da
   Author: Govindraj.R <[email protected]>
   Date:   Thu Oct 13 14:11:09 2011 +0530
       ARM: OMAP2+: UART: Add wakeup mechanism for omap-uarts

       From the runtime callbacks enable hwmod wakeups for uart which will
       internally enable io-pad wakeups for uarts if they have rx-pad pins
       set as wakeup capabale.

       Use the io-ring wakeup mechanism after uart clock gating and leave
       the PM_WKST set for uart to default reset values cleanup the code in serial.c which was handling PM_WKST reg. Irq_chaing(PRM_DRIVER) is used to wakeup uart after uart clocks are
   gated
       using pad wakeup mechanism.

Signed-off-by Govindraj.R <[email protected]>

Acked-by Greg Kroah-Hartman <[email protected]> (for drivers/tty

   changes)

Signed-off-by Kevin Hilman <[email protected]>

   commit 94734749af794c080f6af6ac3ce8c1c13ee2dbbd
   Author: Govindraj.R <[email protected]>
   Date:   Mon Nov 7 19:00:33 2011 +0530
       ARM: OMAP2+: UART: Move errata handling from serial.c to omap-serial

       Move the errata handling mechanism from serial.c to omap-serial file
       and utilise the same func in driver file.

       Errata i202, i291 are moved to be handled with omap-serial Moving the errata macro from serial.c file to driver header file as from on errata will be handled in driver file itself. Corrected errata id from chapter reference 2.15 to errata id i291.

       Removed errata and dma_enabled fields from omap_uart_state struct
       as they are no more needed with errata handling done within omap-serial.

Signed-off-by Govindraj.R <[email protected]>

Acked-by Alan Cox <[email protected]>

Acked-by Greg Kroah-Hartman <[email protected]>

Signed-off-by Kevin Hilman <[email protected]>

   commit ec3bebc6ec64aac23500e6b8ef5c0aaaeda735cf
   Author: Govindraj.R <[email protected]>
   Date:   Tue Oct 11 19:11:27 2011 +0530
       ARM: OMAP2+: UART: Get context loss count to context restore

       Avoid unconditional context restore every time we gate uart clocks. Check whether context loss happened based on which we can context restore uart regs from uart_port structure.

Signed-off-by Govindraj.R <[email protected]>

Acked-by Greg Kroah-Hartman <[email protected]> (for drivers/tty

   changes)

Signed-off-by Kevin Hilman <[email protected]>

   commit 32212897eeb8c2b2b3c74dbd44d842963084d808
   Author: Govindraj.R <[email protected]>
   Date:   Mon Nov 7 18:58:55 2011 +0530
       ARM: OMAP2+: UART: Remove uart reset function.

       Remove the uart reset function which is configuring the TX empty irq which can now be handled within omap-serial driver.

Signed-off-by Govindraj.R <[email protected]>

Acked-by Greg Kroah-Hartman <[email protected]> (for drivers/tty

   changes)

Signed-off-by Kevin Hilman <[email protected]>

   commit c538d20c7f437e56c5301357c492230d1d6d1b80
   Author: Govindraj.R <[email protected]>
   Date:   Mon Nov 7 18:57:03 2011 +0530
       ARM: OMAP2+: UART: Ensure all reg values configured are available
   from port structure

       Add missing uart regs to uart_port structure which can be used in
       context restore. Store dll, dlh, mdr1, scr, efr, lcr, mcr reg values
       into uart_port structure while configuring individual port in termios
       function.

Signed-off-by Govindraj.R <[email protected]>

Acked-by Greg Kroah-Hartman <[email protected]> (for drivers/tty

   changes)

Signed-off-by Kevin Hilman <[email protected]>

   commit 9f9ac1e84a24670eea1430040e0aef278b4daffa
   Author: Govindraj.R <[email protected]>
   Date:   Mon Nov 7 18:56:12 2011 +0530
       ARM: OMAP2+: UART: Remove context_save and move context restore to
   driver

       Remove context save function from serial.c and move context restore
       function to omap-serial. Remove all regs stored in omap_uart_state
       for contex_save/restore, reg read write funcs used in context_save/restore,
       io_addresses populated for read/write funcs.

       Clock gating mechanism was done in serial.c and had no info on uart
   state
       thus we needed context save and restore in serial.c With runtime conversion and clock gating done within uart driver context restore can be done from regs value available from uart_omap_port
       structure.

Signed-off-by Govindraj.R <[email protected]>

Acked-by Greg Kroah-Hartman <[email protected]> (for drivers/tty

   changes)

Signed-off-by Kevin Hilman <[email protected]>

   commit fcdca75728ac376f3de74376c791e1078ee83820
   Author: Govindraj.R <[email protected]>
   Date:   Mon Feb 28 18:12:23 2011 +0530
       ARM: OMAP2+: UART: Add runtime pm support for omap-serial driver

       Adapts omap-serial driver to use pm_runtime API's. Use runtime runtime API's to handle uart clocks and obtain device_usage statics. Set runtime API's usage to irq_safe so that
       we can use get_sync from irq context. Auto-suspend for port specific
       activities and put for reg access. Moving suspend/resume hooks to dev_pm_ops structure and bind with config_suspend to avoid any
       compilation warning if config_suspend is disabled.

       By default uart autosuspend delay is set to -1 to avoid character
   loss
       if uart's are autoidled and woken up on rx pin.

       After boot up UART's can be autoidled by setting autosuspend delay
   from sysfs.

       echo 3000 > /sys/devices/platform/omap/omap_uart.X/power/autosuspend_delay_ms X=0,1,2,3 for UART1/2/3/4. Number of uarts available may vary across omap_soc.

       Also if uart is not wakeup capable we can prevent runtime autosuspend by
       forbiding runtime.

Signed-off-by Govindraj.R <[email protected]>

Acked-by Alan Cox <[email protected]>

Acked-by Greg Kroah-Hartman <[email protected]>

Signed-off-by Kevin Hilman <[email protected]>

   commit edd70ad757e9b336116433e6e62de79ae1dfef54
   Author: Govindraj.R <[email protected]>
   Date:   Tue Oct 11 14:55:41 2011 +0530
       ARM: OMAP2+: UART: Remove mapbase/membase fields from pdata.

       The mapbase (start_address), membase(io_remap cookie) part of pdata struct omap_uart_port_info are removed as this should be derived within driver.

Signed-off-by Govindraj.R <[email protected]>

Acked-by Greg Kroah-Hartman <[email protected]> (for drivers/tty

   changes)

Signed-off-by Kevin Hilman <[email protected]>

   commit 7496ba309f2adbce74d917fbb8bd3da26222d49f
   Author: Govindraj.R <[email protected]>
   Date:   Mon Nov 7 18:55:05 2011 +0530
       ARM: OMAP2+: UART: Add default mux for all uarts.

       Padconf wakeup is used to wakeup uart after uart fclks/iclks are gated.
       Rx-Pad wakeup was done by writing to rx-pad offset value populated
   in
       serial.c idle_init. Remove the direct reading and writing into rx
   pad.
       Remove the padconf field part of omap_uart_state struct and pad offsets
       populated.

       Now with mux framework support we can use mux_utilities along with hmwod framework to handle io-pad configuration and enable rx-pad
       wake-up mechanism.

       To avoid breaking any board support add default mux data for all uart's
       if mux info is not passed from board file.
       With the default pads populated in serial.c wakeup capability for
       rx pads is set, this can be used to enable uart_rx io-pad wakeup from
       hwmod framework. The pad values in 3430sdp/4430sdp/omap4panda board
   file
       are same as the default pad values populated in serial.c. Remove pad values
       from 3430sdp/4430sdp/omap4panda board file and use the default pads
       from serial.c file.

Signed-off-by Govindraj.R <[email protected]>

Signed-off-by Kevin Hilman <[email protected]>

   commit 273558b3a0399e368d99da5b3daf1c0e11b93e06
   Author: Govindraj.R <[email protected]>
   Date:   Tue Sep 13 14:01:01 2011 +0530
       ARM: OMAP2+: UART: Cleanup part of clock gating mechanism for uart

       Currently we use a shared irq handler to identify uart activity and
   then
       trigger a timer. By default the timeout value is zero and can be set or
       modified from sysfs. If there was no uart activity for the period
   set
       through sysfs, the timer will expire and call timer handler this will
       set a flag can_sleep using which decision to gate uart clocks can
   be taken.

       Since the clock gating mechanism is outside the uart driver, we currently
       use this mechanism. In preparation to runtime implementation for omap-serial
       driver we can cleanup this mechanism and use runtime API's to gate
   uart clocks.

       Removes the following:
       * timer related info from local uart_state struct
       * the code used to set timeout value from sysfs.
       * irqflags used to set shared irq handler.
       * un-used function omap_uart_check_wakeup.

Signed-off-by Govindraj.R <[email protected]>

Acked-by Greg Kroah-Hartman <[email protected]> (for drivers/tty

   changes)

Signed-off-by Kevin Hilman <[email protected]>

   commit 8a60585159067f110075ef8ffda13abd94826daf
   Author: Govindraj.R <[email protected]>
   Date:   Tue Sep 13 13:32:32 2011 +0530
       ARM: OMAP2+: UART: cleanup 8250 console driver support

       We had been using traditional 8250 driver as uart console driver prior to omap-serial driver. Since we have omap-serial driver in mainline kernel for some time now it has been used as default uart console driver on omap2+ platforms. Remove 8250 support for omap-uarts.

       Serial_in and serial_out override for 8250 serial driver is also removed. Empty fifo read fix is already taken care with omap-serial
       driver with data ready bit check from LSR reg before reading RX fifo.
       Also waiting for THRE(transmit hold reg empty) is done with wait_for_xmitr
       in omap-serial driver.

       Serial_in/out overrides are not neceesary for omap-serial driver and things that are taken with omap-serial driver are removed here.

       Remove headers that were necessary to support 8250 support and remove all config bindings done to keep 8250 backward compatibility
       while adding omap-serial driver. Remove omap_uart_reset needed for
       8250 autoconf.

Signed-off-by Govindraj.R <[email protected]>

Signed-off-by Kevin Hilman <[email protected]>

   commit 8384c9749f8c31c6e1e64a63c8d50af7863ce657
   Author: Govindraj.R <[email protected]>
   Date:   Wed Nov 9 17:22:30 2011 +0530
       ARM: OMAP2+: UART: cleanup + remove uart pm specific API

       In preparation to UART runtime conversion remove uart specific calls
       from pm24xx/34xx files and their definition from serial.c These func calls will no more be used with upcoming uart runtime design.

       1.) omap_uart_prepare_suspend :- can be taken care with driver suspend hooks.
       2.) omap_uart_enable_irqs :- Used to enable/disable uart irq's in
   suspend
           path from PM code, this is removed as same is handled by uart_suspend_port/uart_resume_port in omap-serial driver which
   will
           do an port_shutdown on suspend freeing irq and port_startup on
   resume
           enabling back irq.
       3.) Remove prepare_idle/resume_idle calls used to gate uart clocks.
           UART clocks can be gated within driver using runtime funcs and be woken up using irq_chaining from omap_prm driver. 4.) Remove console_locking from idle path as clock gating is done
   withing
           driver itself with runtime API. Remove is_suspending check used
   to acquire
           console_lock.

Signed-off-by Govindraj.R <[email protected]>

Signed-off-by Kevin Hilman <[email protected]>

 -----------------------------------------------------------------------
   ------------------------------------------------------------------

   regards
   keshava

   On Wed, Jun 6, 2012 at 5:21 PM, Munegowda, Keshava <[email protected]> wrote:

     hi Kevin
      I have started this; I see that mainline is not booting in 3430 sdp
     i will fix this first.
     regards
     keshava

   On Tue, Jun 5, 2012 at 11:20 PM, Kevin Hilman <[email protected]> wrote:

     Keshava, Felipe,
     ping.  This problem is still preventing CORE retention in mainline.

   On 05/24/2012 03:13 PM, Kevin Hilman wrote:

   Kevin Hilman<[email protected]>  writes:

     "Munegowda, Keshava"<[email protected]>  writes:

     On Thu, May 24, 2012 at 5:55 AM, Kevin Hilman<[email protected]> wrote:

     On 05/23/2012 05:01 PM, Kevin Hilman wrote:

     Hi Keshava,
     Using current l-o master, I noticed that CORE was not hitting retention
     in idle on my 3530/Overo.  CORE hits retention on suspend just fine.
     Debugging this, I found that usbtll_fck was still enabled during idle,
     thus preventing CORE from hitting retention.
     To test, I disabled USB host (CONFIG_MFD_OMAP_USB_HOST=n in .config)
     and
     was then started seeing CORE hit retention in idle again. I have nothing plugged into the USB host port on this board, so I would've expected that runtime PM would've kicked in and shutdown this
     clock.
     Any ideas what's going on here?  Is this expected behavior?

     If it helps, attached is a bootlog after enabling debug for mfd/omap-usb-host.c as well.  Notice there's a couple of clock-related
     warnings from this driver as well.  Not sure if they're relevant:
     usbhs_omap: alias fck already exists
     usbhs_omap usbhs_omap: xclk60mhsp2_ck set parentfailed error:-22

     these clocks were specific to omap4 and it should not cause any problem to omap3 boards.

     OK, they seem unrelated to this CORE retention problem, but the warnings
     should still be understood and fixed.

     I will try to reproduce this on 3430 sdp to explore further.

     Thanks for looking.  Note that I only saw this problem on my 3530 platforms (Overo, OMAP3EVM.)  My 3430/n900 doesn't support USBHS host
     AFAICT, so didn't test there.

   After realizing that the same IP should exist on 3430/n900, I copied some board file support for USBHS host from overo into the n900 board
   file in order to test on 3430/n900.
   Problem exists on n900 too.
   Kevin

Quoted 27 lines · Keshava

hi kevin
        now I am using initramfs with kernel linux3.5.rc1, but the retention is not working in 3430 sdp.  I am seeing the following error followed by a crash

echo mem > /sys/power/state
[   35.609252] PM: Syncing filesystems ... done.
[   35.614654] PM: Preparing system for mem sleep
[   35.658630] Freezing user space processes ... (elapsed 0.01 seconds) done.
[   35.689727] Freezing remaining freezable tasks ... (elapsed 0.02 seconds) done.
[   35.697692] PM: Entering mem sleep
[   35.722442] usb usb1: usb auto-resume
[   35.726409] ehci-omap ehci-omap.0: resume root hub
[   35.775451] hub 1-0:1.0: hub_resume
[   35.779846] hub 1-0:1.0: hub_suspend
[   35.784240] usb usb1: bus suspend, wakeup 0
[   35.788665] ehci-omap ehci-omap.0: suspend root hub
[   35.805786] PM: suspend of devices complete after 99.304 msecs [   35.816497] PM: late suspend of devices complete after 4.364 msecs [   35.831573] PM: noirq suspend of devices complete after 8.331 msecs [   35.838500] Disabling non-boot CPUs ...
[   36.312164] Powerdomain (core_pwrdm) didn't enter target state 1 [   36.318481] Could not enter target state in pm_suspend
[   36.324859] Unable to handle kernel NULL pointer dereference at virtual

Quoted 8 lines

address 00000018
[   36.333557] pgd = c6280000
[   36.336639] [00000018] *pgd=85c8f831, *pte=00000000, *ppte=00000000 [   36.343414] Internal error: Oops: 17 [#1] SMP ARM
[   36.348388] Modules linked in:
[   36.351623] CPU: 0    Tainted: G        W     (3.5.0-rc1 #1) [   36.357574] PC is at _od_resume_noirq+0x14/0x58
[   36.362365] LR is at dpm_run_callback+0x2c/0x74

Hi Keshava,

Quoted 29 lines · Keshava

Quoted 27 lines · Keshava

hi kevin
        now I am using initramfs with kernel linux3.5.rc1, but the retention is not working in 3430 sdp.  I am seeing the following error followed by a crash

echo mem > /sys/power/state
[   35.609252] PM: Syncing filesystems ... done.
[   35.614654] PM: Preparing system for mem sleep
[   35.658630] Freezing user space processes ... (elapsed 0.01 seconds) done.
[   35.689727] Freezing remaining freezable tasks ... (elapsed 0.02 seconds) done.
[   35.697692] PM: Entering mem sleep
[   35.722442] usb usb1: usb auto-resume
[   35.726409] ehci-omap ehci-omap.0: resume root hub
[   35.775451] hub 1-0:1.0: hub_resume
[   35.779846] hub 1-0:1.0: hub_suspend
[   35.784240] usb usb1: bus suspend, wakeup 0
[   35.788665] ehci-omap ehci-omap.0: suspend root hub
[   35.805786] PM: suspend of devices complete after 99.304 msecs [   35.816497] PM: late suspend of devices complete after 4.364 msecs [   35.831573] PM: noirq suspend of devices complete after 8.331 msecs [   35.838500] Disabling non-boot CPUs ...
[   36.312164] Powerdomain (core_pwrdm) didn't enter target state 1 [   36.318481] Could not enter target state in pm_suspend
[   36.324859] Unable to handle kernel NULL pointer dereference at virtual

Quoted 8 lines

Quoted 8 lines

address 00000018
[   36.333557] pgd = c6280000
[   36.336639] [00000018] *pgd=85c8f831, *pte=00000000, *ppte=00000000 [   36.343414] Internal error: Oops: 17 [#1] SMP ARM
[   36.348388] Modules linked in:
[   36.351623] CPU: 0    Tainted: G        W     (3.5.0-rc1 #1) [   36.357574] PC is at _od_resume_noirq+0x14/0x58
[   36.362365] LR is at dpm_run_callback+0x2c/0x74

You need the fix from
https://gitorious.org/linux-omap-dss2/linux/commit/9e0ca55fa5d9ff012964a7c7cef8af1b814b2fdb

Hope this helps!

Regards,
Jean

Quoted 45 lines · Jean Pihet

Hi Keshava,

Quoted 29 lines · Keshava

Quoted 27 lines · Keshava

hi kevin
        now I am using initramfs with kernel linux3.5.rc1, but the retention is not working in 3430 sdp.  I am seeing the following error followed by a crash

echo mem > /sys/power/state
[   35.609252] PM: Syncing filesystems ... done.
[   35.614654] PM: Preparing system for mem sleep
[   35.658630] Freezing user space processes ... (elapsed 0.01 seconds) done.
[   35.689727] Freezing remaining freezable tasks ... (elapsed 0.02 seconds) done.
[   35.697692] PM: Entering mem sleep
[   35.722442] usb usb1: usb auto-resume
[   35.726409] ehci-omap ehci-omap.0: resume root hub
[   35.775451] hub 1-0:1.0: hub_resume
[   35.779846] hub 1-0:1.0: hub_suspend
[   35.784240] usb usb1: bus suspend, wakeup 0
[   35.788665] ehci-omap ehci-omap.0: suspend root hub
[   35.805786] PM: suspend of devices complete after 99.304 msecs [   35.816497] PM: late suspend of devices complete after 4.364 msecs [   35.831573] PM: noirq suspend of devices complete after 8.331 msecs [   35.838500] Disabling non-boot CPUs ...
[   36.312164] Powerdomain (core_pwrdm) didn't enter target state 1 [   36.318481] Could not enter target state in pm_suspend
[   36.324859] Unable to handle kernel NULL pointer dereference at virtual

Quoted 8 lines

Quoted 8 lines

address 00000018
[   36.333557] pgd = c6280000
[   36.336639] [00000018] *pgd=85c8f831, *pte=00000000, *ppte=00000000 [   36.343414] Internal error: Oops: 17 [#1] SMP ARM
[   36.348388] Modules linked in:
[   36.351623] CPU: 0    Tainted: G        W     (3.5.0-rc1 #1) [   36.357574] PC is at _od_resume_noirq+0x14/0x58
[   36.362365] LR is at dpm_run_callback+0x2c/0x74

You need the fix from
https://gitorious.org/linux-omap-dss2/linux/commit/9e0ca55fa5d9ff012964a7c7cef8af1b814b2fdb

Quoted 4 lines

Hope this helps!

Regards,
Jean

thanks Jean
I used this patch; this solved the crash issue, but suspend/resume
is still failing.

Quoted 51 lines · Keshava

Quoted 49 lines · Jean Pihet

Hi Keshava,

Quoted 29 lines · Keshava

Quoted 27 lines · Keshava

hi kevin
        now I am using initramfs with kernel linux3.5.rc1, but the retention is not working in 3430 sdp.  I am seeing the following error followed by a crash

echo mem > /sys/power/state
[   35.609252] PM: Syncing filesystems ... done.
[   35.614654] PM: Preparing system for mem sleep
[   35.658630] Freezing user space processes ... (elapsed 0.01 seconds) done.
[   35.689727] Freezing remaining freezable tasks ... (elapsed 0.02 seconds) done.
[   35.697692] PM: Entering mem sleep
[   35.722442] usb usb1: usb auto-resume
[   35.726409] ehci-omap ehci-omap.0: resume root hub
[   35.775451] hub 1-0:1.0: hub_resume
[   35.779846] hub 1-0:1.0: hub_suspend
[   35.784240] usb usb1: bus suspend, wakeup 0
[   35.788665] ehci-omap ehci-omap.0: suspend root hub
[   35.805786] PM: suspend of devices complete after 99.304 msecs [   35.816497] PM: late suspend of devices complete after 4.364 msecs [   35.831573] PM: noirq suspend of devices complete after 8.331 msecs [   35.838500] Disabling non-boot CPUs ...
[   36.312164] Powerdomain (core_pwrdm) didn't enter target state 1 [   36.318481] Could not enter target state in pm_suspend
[   36.324859] Unable to handle kernel NULL pointer dereference at virtual

Quoted 8 lines

Quoted 8 lines

address 00000018
[   36.333557] pgd = c6280000
[   36.336639] [00000018] *pgd=85c8f831, *pte=00000000, *ppte=00000000 [   36.343414] Internal error: Oops: 17 [#1] SMP ARM
[   36.348388] Modules linked in:
[   36.351623] CPU: 0    Tainted: G        W     (3.5.0-rc1 #1) [   36.357574] PC is at _od_resume_noirq+0x14/0x58
[   36.362365] LR is at dpm_run_callback+0x2c/0x74

You need the fix from
https://gitorious.org/linux-omap-dss2/linux/commit/9e0ca55fa5d9ff012964a7c7cef8af1b814b2fdb

Hope this helps!

Regards,
Jean

Quoted 3 lines

thanks Jean
    I used this patch; this solved the crash issue, but suspend/resume is still failing.

Failing in what way?  Did you debug any further?

It may be failing because of problems with the USB host driver, which is what I'm needing you to debug.

I'm convinced now that these USB host PM changes were not very well tested at all as they seem to be causing a variety of different problems on my boards: faults during boot, preventing CORE idle retention, hanging suspend/resume.

Anyways...

To get current l-o master to succesfully suspend/resume, you need 3 things:

1) the DSS fixes that Jean mentioned above (these are merged in v3.5-rc3, but not yet into l-o master)
2) disable USB host: set CONFIG_MFD_OMAP_USB_HOST=n
3) for for 32k timer which is also preventing CORE retention
  http://marc.info/?l=linux-omap&m=134000053229888&w=2

With that setup on top of current l-o master, suspend/resume is working for me on several OMAP3/4 platforms.

Kevin

Quoted 57 lines · Kevin Hilman

Quoted 54 lines · Keshava

Quoted 42 lines · Jean Pihet

Hi Keshava,

Quoted 29 lines · Keshava

Quoted 27 lines · Keshava

hi kevin
        now I am using initramfs with kernel linux3.5.rc1, but the retention is not working in 3430 sdp.  I am seeing the following error followed by a crash

echo mem > /sys/power/state
[   35.609252] PM: Syncing filesystems ... done.
[   35.614654] PM: Preparing system for mem sleep
[   35.658630] Freezing user space processes ... (elapsed 0.01 seconds) done.
[   35.689727] Freezing remaining freezable tasks ... (elapsed 0.02 seconds) done.
[   35.697692] PM: Entering mem sleep
[   35.722442] usb usb1: usb auto-resume
[   35.726409] ehci-omap ehci-omap.0: resume root hub
[   35.775451] hub 1-0:1.0: hub_resume
[   35.779846] hub 1-0:1.0: hub_suspend
[   35.784240] usb usb1: bus suspend, wakeup 0
[   35.788665] ehci-omap ehci-omap.0: suspend root hub
[   35.805786] PM: suspend of devices complete after 99.304 msecs [   35.816497] PM: late suspend of devices complete after 4.364 msecs [   35.831573] PM: noirq suspend of devices complete after 8.331 msecs [   35.838500] Disabling non-boot CPUs ...
[   36.312164] Powerdomain (core_pwrdm) didn't enter target state 1 [   36.318481] Could not enter target state in pm_suspend
[   36.324859] Unable to handle kernel NULL pointer dereference at virtual

Quoted 8 lines

Quoted 8 lines

address 00000018
[   36.333557] pgd = c6280000
[   36.336639] [00000018] *pgd=85c8f831, *pte=00000000, *ppte=00000000 [   36.343414] Internal error: Oops: 17 [#1] SMP ARM
[   36.348388] Modules linked in:
[   36.351623] CPU: 0    Tainted: G        W     (3.5.0-rc1 #1) [   36.357574] PC is at _od_resume_noirq+0x14/0x58
[   36.362365] LR is at dpm_run_callback+0x2c/0x74

Quoted 7 lines

You need the fix from
https://gitorious.org/linux-omap-dss2/linux/commit/9e0ca55fa5d9ff012964a7c7cef8af1b814b2fdb

Hope this helps!

Regards,
Jean

thanks Jean
    I used this patch; this solved the crash issue, but suspend/resume is still failing.

Quoted 4 lines

Failing in what way?  Did you debug any further?

It may be failing because of problems with the USB host driver, which is what I'm needing you to debug.

The suspend/resume was failing even without USB in the mainline kernel image.

Quoted 20 lines

I'm convinced now that these USB host PM changes were not very well tested at all as they seem to be causing a variety of different problems on my boards: faults during boot, preventing CORE idle retention, hanging suspend/resume.

Anyways...

To get current l-o master to succesfully suspend/resume, you need 3 things:

1) the DSS fixes that Jean mentioned above (these are merged in v3.5-rc3, but not yet into l-o master)
2) disable USB host: set CONFIG_MFD_OMAP_USB_HOST=n
3) for for 32k timer which is also preventing CORE retention
  http://marc.info/?l=linux-omap&m=134000053229888&w=2

With that setup on top of current l-o master, suspend/resume is working for me on several OMAP3/4 platforms.

Kevin

Quoted 81 lines · Keshava

Quoted 53 lines · Kevin Hilman

Quoted 51 lines · Keshava

Quoted 49 lines · Jean Pihet

Hi Keshava,

Quoted 29 lines · Keshava

Quoted 27 lines · Keshava

hi kevin
        now I am using initramfs with kernel linux3.5.rc1, but the retention is not working in 3430 sdp.  I am seeing the following error followed by a crash

echo mem > /sys/power/state
[   35.609252] PM: Syncing filesystems ... done.
[   35.614654] PM: Preparing system for mem sleep
[   35.658630] Freezing user space processes ... (elapsed 0.01 seconds) done.
[   35.689727] Freezing remaining freezable tasks ... (elapsed 0.02 seconds) done.
[   35.697692] PM: Entering mem sleep
[   35.722442] usb usb1: usb auto-resume
[   35.726409] ehci-omap ehci-omap.0: resume root hub
[   35.775451] hub 1-0:1.0: hub_resume
[   35.779846] hub 1-0:1.0: hub_suspend
[   35.784240] usb usb1: bus suspend, wakeup 0
[   35.788665] ehci-omap ehci-omap.0: suspend root hub
[   35.805786] PM: suspend of devices complete after 99.304 msecs [   35.816497] PM: late suspend of devices complete after 4.364 msecs [   35.831573] PM: noirq suspend of devices complete after 8.331 msecs [   35.838500] Disabling non-boot CPUs ...
[   36.312164] Powerdomain (core_pwrdm) didn't enter target state 1 [   36.318481] Could not enter target state in pm_suspend
[   36.324859] Unable to handle kernel NULL pointer dereference at virtual

Quoted 8 lines

Quoted 8 lines

address 00000018
[   36.333557] pgd = c6280000
[   36.336639] [00000018] *pgd=85c8f831, *pte=00000000, *ppte=00000000 [   36.343414] Internal error: Oops: 17 [#1] SMP ARM
[   36.348388] Modules linked in:
[   36.351623] CPU: 0    Tainted: G        W     (3.5.0-rc1 #1) [   36.357574] PC is at _od_resume_noirq+0x14/0x58
[   36.362365] LR is at dpm_run_callback+0x2c/0x74

You need the fix from
https://gitorious.org/linux-omap-dss2/linux/commit/9e0ca55fa5d9ff012964a7c7cef8af1b814b2fdb

Hope this helps!

Regards,
Jean

Quoted 8 lines

Quoted 3 lines

thanks Jean
    I used this patch; this solved the crash issue, but suspend/resume is still failing.

Failing in what way?  Did you debug any further?

It may be failing because of problems with the USB host driver, which is what I'm needing you to debug.

The suspend/resume was failing even without USB in the mainline kernel image.

Quoted 16 lines

I'm convinced now that these USB host PM changes were not very well tested at all as they seem to be causing a variety of different problems on my boards: faults during boot, preventing CORE idle retention, hanging suspend/resume.

Anyways...

To get current l-o master to succesfully suspend/resume, you need 3 things:

1) the DSS fixes that Jean mentioned above (these are merged in v3.5-rc3, but not yet into l-o master)
2) disable USB host: set CONFIG_MFD_OMAP_USB_HOST=n
3) for for 32k timer which is also preventing CORE retention
  http://marc.info/?l=linux-omap&m=134000053229888&w=2

Quoted 5 lines

Quoted 4 lines

With that setup on top of current l-o master, suspend/resume is working for me on several OMAP3/4 platforms.

Kevin

I tired the linux2.3.5.rc2 + DSS fixes + sync 32k timer fix without USB on beagle XM.

Quoted 83 lines · Keshava

Quoted 81 lines · Keshava

Quoted 53 lines · Kevin Hilman

Quoted 51 lines · Keshava

Quoted 49 lines · Jean Pihet

Hi Keshava,

Quoted 29 lines · Keshava

Quoted 27 lines · Keshava

hi kevin
        now I am using initramfs with kernel linux3.5.rc1, but the retention is not working in 3430 sdp.  I am seeing the following error followed by a crash

echo mem > /sys/power/state
[   35.609252] PM: Syncing filesystems ... done.
[   35.614654] PM: Preparing system for mem sleep
[   35.658630] Freezing user space processes ... (elapsed 0.01 seconds) done.
[   35.689727] Freezing remaining freezable tasks ... (elapsed 0.02 seconds) done.
[   35.697692] PM: Entering mem sleep
[   35.722442] usb usb1: usb auto-resume
[   35.726409] ehci-omap ehci-omap.0: resume root hub
[   35.775451] hub 1-0:1.0: hub_resume
[   35.779846] hub 1-0:1.0: hub_suspend
[   35.784240] usb usb1: bus suspend, wakeup 0
[   35.788665] ehci-omap ehci-omap.0: suspend root hub
[   35.805786] PM: suspend of devices complete after 99.304 msecs [   35.816497] PM: late suspend of devices complete after 4.364 msecs [   35.831573] PM: noirq suspend of devices complete after 8.331 msecs [   35.838500] Disabling non-boot CPUs ...
[   36.312164] Powerdomain (core_pwrdm) didn't enter target state 1 [   36.318481] Could not enter target state in pm_suspend
[   36.324859] Unable to handle kernel NULL pointer dereference at virtual

Quoted 8 lines

Quoted 8 lines

address 00000018
[   36.333557] pgd = c6280000
[   36.336639] [00000018] *pgd=85c8f831, *pte=00000000, *ppte=00000000 [   36.343414] Internal error: Oops: 17 [#1] SMP ARM
[   36.348388] Modules linked in:
[   36.351623] CPU: 0    Tainted: G        W     (3.5.0-rc1 #1) [   36.357574] PC is at _od_resume_noirq+0x14/0x58
[   36.362365] LR is at dpm_run_callback+0x2c/0x74

You need the fix from
https://gitorious.org/linux-omap-dss2/linux/commit/9e0ca55fa5d9ff012964a7c7cef8af1b814b2fdb

Hope this helps!

Regards,
Jean

Quoted 8 lines

Quoted 3 lines

thanks Jean
    I used this patch; this solved the crash issue, but suspend/resume is still failing.

Failing in what way?  Did you debug any further?

It may be failing because of problems with the USB host driver, which is what I'm needing you to debug.

The suspend/resume was failing even without USB in the mainline kernel image.

Quoted 16 lines

I'm convinced now that these USB host PM changes were not very well tested at all as they seem to be causing a variety of different problems on my boards: faults during boot, preventing CORE idle retention, hanging suspend/resume.

Anyways...

To get current l-o master to succesfully suspend/resume, you need 3 things:

1) the DSS fixes that Jean mentioned above (these are merged in v3.5-rc3, but not yet into l-o master)
2) disable USB host: set CONFIG_MFD_OMAP_USB_HOST=n
3) for for 32k timer which is also preventing CORE retention
  http://marc.info/?l=linux-omap&m=134000053229888&w=2

Quoted 8 lines

Quoted 5 lines

Quoted 4 lines

With that setup on top of current l-o master, suspend/resume is working for me on several OMAP3/4 platforms.

Kevin

I tired the linux2.3.5.rc2 + DSS fixes + sync 32k timer fix without USB on beagle XM.

I suggested using l-o master as a baseline, not -rc2.

I just pushed a branch with this baseline so we are sure to be testing the same baseline.  Please use the 'tmp/test/usb-host' branch from my tree[1] as the starting point.

Build using omap2plus_defconfig, boot, then suspend/resume and send the output of 'cat /debug/pm_debug/count'

This baseline is working fine for me on 3430/n900, 3530/Overo and 3630/Beagle-xM.

Kevin

[1] git://git.kernel.org/pub/scm/linux/kernel/git/khilman/linux.git

I did the clone of this , But I am not seeing the branch 'tmp/test/usb-host' I am seeing only the branch /wip/arm-nohz-cpusets other than master. I didn't any usb-host branch here too:
http://git.kernel.org/?p=linux/kernel/git/khilman/linux.git;a=summary

Quoted 4 lines · Keshava

I did the clone of this , But I am not seeing the branch 'tmp/test/usb-host' I am seeing only the branch /wip/arm-nohz-cpusets other than master. I didn't any usb-host branch here too:
http://git.kernel.org/?p=linux/kernel/git/khilman/linux.git;a=summary

It seems Kevin linked the wrong git tree, try this one:
http://git.kernel.org/?p=linux/kernel/git/khilman/linux-omap-pm.git