This thread has been locked.

If you have a related question, please click the "Ask a related question" button in the top right corner. The newly created question will be automatically linked to this question.

Problem with suspend/resume DM3730 on PSP 03.00.01.06

Other Parts Discussed in Thread: DM3730, TSC2004

I'm using the PSP 2.6.32 kernel (03.00.01.06), and I'm having trouble with suspend/resume on my DM3730 board.

If I have a BDI attached, then suspend/resume works fine(can resume via sending character to serial console), outside of some clock/power domains not shutting off.  If I remove the BDI it suspends fine but doesn't resume.

I've added code to kernel to flush the printk buffer (figuring there's an oops in it) and also keep track of where it is (log_buf, lob_buf_len, log_end) and flush this into the start of DRAM.  I've also modified X-loader to look for this structure and if found, then dump out the last 4KB of printk log_buf data.  After suspending and attempting to resume, then restting the board, I see the following:

 

DM-37x login: root
Password:
OMAP-35x# echo mem > /sys/power/state
PM: Syncing filesystems ... done.
PM: Preparing system for mem sleep
Freezing user space processes ... (elapsed 0.02 seconds) done.
Freezing remaining freezable tasks ... (elapsed 0.01 seconds) done.
PM: Entering mem sleep


Texas Instruments X-Loader 1.46 (Feb 11 2011 - 12:57:25)
DRAM: MT29C4G48MAZAPAKQ5 256MB
printk_debug_dump: found tag, buf 8034b834 size 65536 start 11125 end 11251
printk_debug_dump log_end 7170 printk_debug->log_end 11251
<6>serial8250.1: ttyS2 at MMIO 0x4806c000 (irq = 73) is a ST16654
<6>brd: module loaded
<6>loop: module loaded
<6>mice: PS/2 mouse device common for all mice
<7>mux: Setting signal mcbsp4_dr.gpio153@fa002186 0x0101 -> 0x4104
<6>input: TSC2004 Touchscreen as /devices/virtual/input/input0
<6>twl_rtc twl_rtc: rtc core: registered twl_rtc as rtc0
<6>i2c /dev entries driver
<6>OMAP Watchdog Timer Rev 0x31: initial timeout 60 sec
<6>Registered led device: led1
<6>Registered led device: led2
<6>TCP cubic registered
<6>NET: Registered protocol family 17
<6>NET: Registered protocol family 15
<3>Power Management for TI OMAP3.
<6>SmartReflex driver initialized
<7>Disabling unused clock "sr2_fck"
<7>Disabling unused clock "sr1_fck"
<7>Disabling unused clock "mcbsp_fck"
<7>Disabling unused clock "mcbsp_fck"
<7>Disabling unused clock "mcbsp_fck"
<7>Disabling unused clock "mcbsp_ick"
<7>Disabling unused clock "mcbsp_ick"
<7>Disabling unused clock "mcbsp_ick"
<7>Disabling unused clock "gpt2_ick"
<7>Disabling unused clock "gpt3_ick"
<7>Disabling unused clock "gpt4_ick"
<7>Disabling unused clock "gpt5_ick"
<7>Disabling unused clock "gpt6_ick"
<7>Disabling unused clock "gpt7_ick"
<7>Disabling unused clock "gpt8_ick"
<7>Disabling unused clock "gpt9_ick"
<7>Disabling unused clock "wdt3_ick"
<7>Disabling unused clock "wdt3_fck"
<7>Disabling unused clock "gpio2_dbck"
<7>Disabling unused clock "gpio3_dbck"
<7>Disabling unused clock "gpio4_dbck"
<7>Disabling unused clock "gpio6_dbck"
<7>Disabling unused clock "gpt9_fck"
<7>Disabling unused clock "gpt8_fck"
<7>Disabling unused clock "gpt7_fck"
<7>Disabling unused clock "gpt6_fck"
<7>Disabling unused clock "gpt5_fck"
<7>Disabling unused clock "gpt4_fck"
<7>Disabling unused clock "gpt3_fck"
<7>Disabling unused clock "gpt2_fck"
<7>Disabling unused clock "gpt12_ick"
<7>Disabling unused clock "wdt1_ick"
<7>Disabling unused clock "gpio1_dbck"
<7>Disabling unused clock "cam_ick"
<7>Disabling unused clock "cam_mclk"
<7>Disabling unused clock "dss_ick"
<7>Disabling unused clock "dss_96m_fck"
<7>Disabling unused clock "dss1_alwon_fck"
<7>Disabling unused clock "des1_ick"
<7>Disabling unused clock "sha11_ick"
<7>Disabling unused clock "rng_ick"
<7>Disabling unused clock "aes1_ick"
<7>Disabling unused clock "ssi_ick"
<7>Disabling unused clock "mailboxes_ick"
<7>Disabling unused clock "mcbsp_ick"
<7>Disabling unused clock "mcbsp_ick"
<7>Disabling unused clock "gpt10_ick"
<7>Disabling unused clock "gpt11_ick"
<7>Disabling unused clock "mcspi_ick"
<7>Disabling unused clock "mcspi_ick"
<7>Disabling unused clock "mcspi_ick"
<7>Disabling unused clock "mcspi_ick"
<7>Disabling unused clock "hdq_ick"
<7>Disabling unused clock "mspro_ick"
<7>Disabling unused clock "des2_ick"
<7>Disabling unused clock "sha12_ick"
<7>Disabling unused clock "aes2_ick"
<7>Disabling unused clock "icr_ick"
<7>Disabling unused clock "pka_ick"
<7>Disabling unused clock "ssi_ssr_fck"
<7>Disabling unused clock "hdq_fck"
<7>Disabling unused clock "mcspi_fck"
<7>Disabling unused clock "mcspi_fck"
<7>Disabling unused clock "mcspi_fck"
<7>Disabling unused clock "mcspi_fck"
<7>Disabling unused clock "mcbsp_fck"
<7>Disabling unused clock "mcbsp_fck"
<7>Disabling unused clock "mspro_fck"
<7>Disabling unused clock "gpt11_fck"
<7>Disabling unused clock "gpt10_fck"
<7>Disabling unused clock "sad2d_ick"
<7>Disabling unused clock "dpll4_m6x2_ck"
<7>Disabling unused clock "dpll4_m3x2_ck"
<7>Disabling unused clock "dpll3_m3x2_ck"
<7>Disabling unused clock "sys_clkout1"
<6>VFP support v0.3: implementor 41 architecture 3 part 30 variant c rev 3
<4>regulator_init_complete: incomplete constraints, leaving VMMC1 on
<6>twl_rtc twl_rtc: setting system clock to 2000-01-01 02:03:45 UTC (946692225)
<5>RAMDISK: gzip image found at block 0
<4>VFS: Mounted root (ext2 filesystem) on device 1:0.
<6>Freeing init memory: 136K
<6>PM: Syncing filesystems ... done.
<7>PM: Preparing system for mem sleep
<4>Freezing user space processes ... (elapsed 0.02 seconds) done.
<4>Freezing remaining freezable tasks ... (elapsed 0.01 seconds) done.
<7>PM: Entering mem sleep

Has anyone had trouble with suspend/resume of the 03.00.01.06 linux-2.6.32 kernel on the DM3730?

Any suggestions on how to go about debugging resume w/o a BDI?

 

  • Hi Peter,

    Let me understand your setup before commenting anything -

     - Which board/EVM are you using? Is it Mistral EVM with DM3730 processor card? it doesn't look like, its Mistral EVM., since we do not have TSC2004 on EVM.

     - What is silicon version of DM3730? (Bootup log should point you to the silicon version)

     - Are you trying to suspend with full off mode? Have you enabled any of the PM flags "enable_off_mode" OR "sleep_while_idle"?

     

    Some options to try -

     - Remove all drivers from your configuration and try. It could possible that some driver is miss-behaving here.

     - Use "no_console_suspend" option in your bootargs, this may give you some pointers on status of system.

     - You mentioned that, when you  connect BDI  it works, so you may want to review the clocking mechanism for your JTAG interface.

     

    And as far as suspend/resume on DM3730 is concerned, YES, its been supported on PSP03.00.01.06 release and validated on Mistral DM3730EVM.

    Thanks,

    Vaibhav

  • Hi Peter,

    It is a new question about  the Touchscreen wake up on DM3730.

    We have a DM3730 based board.

    My LCD is suspending after sometime [FB suspend].

    On the Keypad event, LCD is resuming but on the touch screen event LCD is not resuming.

    I am using GPIO - 183  for touch screen, GPIO-126,129 for the Keypad.

    I have verified the wake up capability for GPIOs [ PADCONFIG , PER domain, GPIO WKEN, GRPSEL like this...]

    I confirmed that LCD resumes only on the keypad event and not the keypad interrupt.

    We are using tsc2004 controller for touchscreen.

    Any suggestions....

    Thanks & Regards

    ANIL

     

  • Vaibhav,

     

    1) The board is Logic's upcoming DM3730 Torpedo/SOM LV modules, temporarily using a DM3630for development due to DM3730 availability.  I took the PSP03.00.01.06, kernel, cloned the omap3evm board file for my board, and started porting over the drivers from our OMAP35x 2.6.32 kernel into it.

    2) OMAP3630/DM3730 ES1.0 (l2cache iva sgx neon isp 192mhz_clk )

    3) No, just "echo mem > /sys/powert/state" and sending characters to it to wake it back up.

    I went through stripping things out of the kernel config to get to a minimal state, but I may have missed something.  My "minimal" kernel acts the same way.  Do you happen to have a minimal kernel configuration that is known to suspend?  If so, can you send it to me (I'd only have to add my CONFIG_MACH_DM3730_SOM_LV=y and CONFIG_MACH_MD3730_TORPEDO=y to get my board file built).

    I am using no_console_suspend; it doesn't shed any more light on why it doesn't come back.

    What do you mean by "review the clocking mechanism" for my JTAG interface?  Can I see what's different in the JTAG clocking when the BDI is attached from withing Linux?

    To test the hardware, I pulled in Tony's "for-next" tree, did a quick hack to get serial/MMC up and using the omap2plus_defconfig I can build a kernel to boots on my board and does suspend/resume.

    I've just gotten a DM3730 EVM, and the stock linux build distributed on the MMC card doesn't recover from suspend (i.e. just "echo mem >/sys/power/state" wait, then touch the screen or send characters to the console).  That version is: "Linux version 2.6.32 (sdk@nemo) (gcc version 4.3.3 (Sourcery G++ Lite 2009q1-203
    ) ) #1 Mon Aug 16 08:38:36 CDT 2010" - Which PSP version is distributed on the 3730EVM?

     

    Thanks!

     

  • Vaibhav,

    I was wondering if you can boot up a DM3730EVM using the ti-dvsdk_dm3730-evm_4_01_00_09 that came with the kit I have (which has the linux-2.6.32-psp03.00.01.06 kernel), and log in as root, then execute "echo mem > /sys/power/state" to put the board into suspend.  When I do that I see:

    |  _  |___ ___ ___ ___   |  _  |___ ___  |_|___ ___| |_                        
    | | _| .'| . | . | | __| _| . | | | -_| _| _|
    |__|__|_| |__,|_ |___| |__| |_| |___|_| |___|___|_|
    |___| |___|

    Arago Project http://arago-project.org dm3730-am3715-evm ttyS0

    Arago 2010.05 dm3730-am3715-evm ttyS0

    dm3730-am3715-evm login: root
    root@dm3730-am3715-evm:~# cat /proc/version
    Linux version 2.6.32 (sdk@nemo) (gcc version 4.3.3 (Sourcery G++ Lite 2009q1-203
    ) ) #1 Mon Aug 16 08:38:36 CDT 2010
    root@dm3730-am3715-evm:~# echo mem > /sys/power/state
    PM: Syncing filesystems ... done.


    At this point the display is still active and if I hit Control-C on the console I see:

    Freezing user space processes ... (elapsed 0.02 seconds) done.
    Freezing remaining freezable tasks ... (elapsed 0.01 seconds) done.
    Suspending console(s) (use no_console_suspend to debug)

    And the display is still active, and the system comes back only by hitting the reset button. I rebooted into u-boot and tried adding "no_console_suspend ignore_loglevel" to the booargs to see if more output is generated:

    OMAP3_EVM# setenv bootargs 'console=ttyS0,115200n8 root=/dev/mmcblk0p2 rw ip=off mem=99M mpurate=1000 omap_vout.vid1_static_vrfb_alloc=y omapfb.mode=dvi:720x480MR-16@60 omapdss.def_disp=lcd rootwait ignore_loglevel no_console_suspend'
    OMAP3_EVM# mmc init
    mmc1 is available
    OMAP3_EVM# fatload mmc 0 0x80200000 uImage
    reading uImage

    2400924 bytes read
    OMAP3_EVM# bootm 0x80200000

    After logging in as root and executing "echo mem > /sys/power/state", I only see:

    Arago Project http://arago-project.org dm3730-am3715-evm ttyS0

    Arago 2010.05 dm3730-am3715-evm ttyS0

    dm3730-am3715-evm login: root
    root@dm3730-am3715-evm:~# echo mem > /sys/power/state
    PM: Syncing filesystems ... done.
    PM: Preparing system for mem sleep

    and no other output. The display is still active, and the cursor tracks touch events, so I don't believe the kernel is suspending.

    Any idea why the system does not go into suspend?

    OMAP3_EVM# fatload mmc 0 80200000 uImage

  • Peter Barada said:

    I'm using the PSP 2.6.32 kernel (03.00.01.06), and I'm having trouble with suspend/resume on my DM3730 board.

    If I have a BDI attached, then suspend/resume works fine(can resume via sending character to serial console), outside of some clock/power domains not shutting off.  If I remove the BDI it suspends fine but doesn't resume.

    Which UART port are you using for the wakeup event ? Please look at 19.3.2.3 Wake-up Request in the TRM (sprugn4h.pdf). When core power domain is not active, uart1 and uart2 are not available for a wakeup event. I'm suspecting that the core power domain is kept on when jtag is connected and it goes to off when it's not connected.

    Peter Barada said:

    Any suggestions on how to go about debugging resume w/o a BDI?

    Can you wakeup the device from other wakeup event like timer and compare previous CORE power domain status w/wo the jtag connected after successful suspend/resume from the different wakeup event ? If the core power domain going to off would be the issue, you could use a GPIO multiplexed on the uarti_cts pin as a alternative wakeup event.

     

  • Kazunobo,

    Thank you for the response. We first saw this problem on our custom DM37x hardware, but Peter has since reproduced it with the Mistral EVM[1] and DVSDK[2], we expect that there may be something simple that is different between our setup/procedure, and yours.

    1.) What hardware, kernel, uboot, and x-loader versions did you test?

    2.) What steps did you follow to suspend?

    2.) What steps did you follow to resume?

    I'm working on getting a proper response to your questions (Peter's on vacation this week), but in the meantime, it would be helpful to us to know the required steps to suspend and resume on the EVM. 

    Thanks,
    Dan Weaver

    [1] http://www.mistralsolutions.com/pes-products/development-platforms/amdm37x-evm.html

    [2] ti-dvsdk_dm3730-evm_4_01_00_09

     

  • Hello Dan,

    Here is the wiki that shows steps to demonstrate the lowest power standby mode (OFF mode) for DM37x devices. I think your questions are answered in the wiki.

    http://processors.wiki.ti.com/index.php/AM/DM37x_Low_Power_Standby_Support

    I think the different behavior between w/ JTAG and w/o JTAG is from the different core power domain status. The clock provided to DM37x from JTAG pod keeps the core domain active when it's connected so uart1 or uart2 in the core power domain is still active and could be a wake up event. When the JTAG is not connected, the core power domain goes to off with suspend command and uarts in the core power domain are no longer available for a wake up event since the power to the uart module is turned off.

  • Kazunobu,

    Thank you, that wiki page gives us exactly what we need. I don't think Peter removed any resistors from the processor card on the EVM, so that's already one potential difference. I'll work on my end to see if we can reproduce this by following the instructions on the wiki-- it may take a day or two because I don't currently have an EVM in my office.

    Thanks again for the quick followup.

    Dan

  • I was able to obtain an DM37 EVM and test suspend/resume using the test image linked from the wiki, and with the image shipped with the EVM. 

    • The test kernel image linked from the wiki page suspends and resumes successfully. It appeared to work whether or not R24 and R57 were removed. 
    • The kernel on the SD card shipped with the EVM does *not* suspend correctly (the display stays on), and also does not resume. 

    The kernel that works removes support for USB & HID, Graphics & Multimedia,  MMC/SD support, MTD/NAND support, and Audio. Do the drivers listed on the Wiki page need to be removed or disabled in order to support low power standby with the latest DVSDK? In other words, is this a known limitation of the DVSDK?

    Thanks,

    Dan

  • The drivers don't necessarily need to be removed however power management options have to be enabled in build option and all modules in the power domain have to be idled before attempting the power domain in retention or off. In the low power demo image, the most of drivers are removed to make sure that all modules used by the drivers are in idle state so user can try suspend/resume without taking care of idling the modules. For the DVSDK image, the power management options have to be enabled if not and all modules have to be idled before attempting suspend/resume.

     

  • Hi Dan,

    Sorry for delayed response, I was on vacation so could not able to respond.

     

    Can you please cross-check with the Arago repository for all latest patches on top of PSP03.00.01.06 release,

    Link to Arago repo - http://arago-project.org/git/projects/?p=linux-omap3.git;a=shortlog;h=refs/heads/OMAPPSP_03.00.01.06

     

    Suspend/Resume is the basic thing which I am sure we have tested this feature, not sure what going wrong at your end.

    Thanks,

    Vaibhav

  • Viabhav,

    Thanks for contacting us. Peter Barada is our lead developer for Linux, and is currently working on importing Arago patches we were missing. He will provide an update once this is complete.

    Dan

  • Kazunobu Shin said:

    Which UART port are you using for the wakeup event ? Please look at 19.3.2.3 Wake-up Request in the TRM (sprugn4h.pdf). When core power domain is not active, uart1 and uart2 are not available for a wakeup event. I'm suspecting that the core power domain is kept on when jtag is connected and it goes to off when it's not connected.

    We use UART1 for our console device.  I understand that uart1/2 can not wakeup the chip when the core domain is not active.  I've tried newer kernels and those do suspend/resume using uart1 as a wakeup source.  I suspect in the newer kernel that they pinmux the uart RX line as a gpio and trigger the wakeup that way.

    Kazunobu Shin said:

    Can you wakeup the device from other wakeup event like timer and compare previous CORE power domain status w/wo the jtag connected after successful suspend/resume from the different wakeup event ? If the core power domain going to off would be the issue, you could use a GPIO multiplexed on the uarti_cts pin as a alternative wakeup event.

    I've tried using a timer in the PSP kernel to wakeup the kernel via /debug/pm_debug/wakeup_timer_seconds, and it doesn't wake up the system.  I've also tried pulling in all the latest Arago changes from http://arago-project.org/git/projects/?p=linux-omap3.git;a=shortlog;h=refs/heads/OMAPPSP_03.00.01.06 and that doesn't look to change anything.

    I'm currently replicating the instructions found at http://processors.wiki.ti.com/index.php/AM/DM37x_Low_Power_Standby_Support on the DM3730EVM that I have.  Where can I find a pointer to the exact source used to build the kernel referenced so I can replicate the experiment on the DM3730EVM as well as my DM3730 hardware using the same kernel?


  • Peter Barada said:

    I'm currently replicating the instructions found at http://processors.wiki.ti.com/index.php/AM/DM37x_Low_Power_Standby_Support on the DM3730EVM that I have.  Where can I find a pointer to the exact source used to build the kernel referenced so I can replicate the experiment on the DM3730EVM as well as my DM3730 hardware using the same kernel?


    I'm able to boot the kernel from the DM37x_Low_Power_Standby_Support on the DM3730EVM and suspend/resume via serial and timer.  Where can I find the exact source of that kernel so I can build/boot it on my board using the same kernel config (plus my board file/configuration) to allow an A/B comparison?  I figure if I can build a kernel that supports/boots on both the DM3730EVM and my DM3730 board, I can try suspend/resume on my board knowing it works on the DM3730EVM (and verify after adding in my board's minimal support).

    Thanks in advance!

  • Hi Peter,

    Actually the uImage which is being shared under http://processors.wiki.ti.com/index.php/AM/DM37x_Low_Power_Standby_Support page is based on PSP03.00.01.06 release, I wouldn't expect the source code to be very different than Arago. There could be some bug fixes which we might have done on top of SDK release (based on PSP03.00.01.06).

    Since now you are seeing issues with OMAP3EVM itself, let me try this at my end. There could be some delay here, since we are at the edge of our next release cycle.

     

    Thanks,

    Vaibhav

  • Hi Peter,

    Today I could able to spend some time on this, I checkout the Arago repository (tag/head - OMAPPSP_03.00.01.06) for all x-loader/uboot/kernel and found that normal suspend resume is working without any issues on OMAP3EVM. Also I tried enabling “enable_off_mode” and “sleep_while_idle” flags and it does also work without any issues. I am attaching the log here for your reference.

    Please note that I am using default configuration (omap3_evm_defconfig) available under this tag.


    Another important point I would like to mention here, during this testing, I observed that, if I use newer x-loader and uboot version (prepared for our next release), then normal suspend/resume doesn’t work, it hangs; but it does work with both flags set.

    I will be debugging this issue as part of next release development activity, so can not commit anything on this.

     

    Thanks,

    Vaibhav