Russ Dill <russ.dill@xxxxxxxxx> writes: > On Mon, Mar 30, 2009 at 11:43 AM, Kevin Hilman > <khilman@xxxxxxxxxxxxxxxxxxx> wrote: >> Russ Dill <russ.dill@xxxxxxxxx> writes: >> >>> On Mon, Mar 30, 2009 at 3:08 AM, Premi, Sanjeev <premi@xxxxxx> wrote: >> [...] >>>> >>>> I had found that two drivers that could prevent clocks_off are >>>> USB and DSS because of the way they use clk_enable(). >>>> >>>> Can you try building without theses drivers just for verification? >>>> >>> >>> Building without dss makes things worse: >>> >>> Powerdomain (dss_pwrdm) didn't enter target state 0 >>> >>> Maybe by looking at what the dss driver is doing I can get core and >>> per to turn off. >> >> Russ, >> >> Can you try with the latest HEAD of PM branch. After suspend/resume, >> do >> >> # cat /debug/pm_debug/registers/1 >> >> and post results to list. We can then see the exact state of PM >> registers before going into WFI. Russ, With the dump below, what was the output after you resumed? Which powerdomains did not hit their target state? It looks like PER and CORE did not hit target state. Also, you didn't mention what hardware you're using or your .config or your bootloader etc. All of these play an important role. > root@beagleboard:/sys# cat /debug/pm_debug/registers/1 > MOD: CM_IVA2 (48014000) > 04 => 00000037 20 => 00000001 34 => 00000001 40 => 0009680c > 44 => 00000001 48 => 00000003 > MOD: CM_OCP (48004800) > 00 => 00000010 10 => 00000001 > MOD: CM_MPU (48004900) > 04 => 00000037 24 => 00000001 34 => 00000001 40 => 0011f40c > 44 => 00000001 48 => 00000003 4c => 00000001 > MOD: CM_CORE (48004a00) > 10 => 00000042 20 => ffffffbd 24 => 0000001f 28 => 0000000d > 30 => fffffed9 34 => 0000001f 38 => 0000000c 40 => 0000030a > 48 => 0000003f 4c => 00000003 > MOD: CM_SGX (48004b00) > 20 => 00000001 48 => 00000003 > MOD: CM_WKUP (48004c00) > 10 => 0000000e 20 => 000002f1 30 => 0000003f 40 => 00000015 Here is at least one problem. Offset 0x40 is CM_CLKSEL_WKUP, and bit 0 shows which clock is the source clock for GPTIMER1. Here, bit 0 is 1 which means SYS_CLK is used as the timer source. Based on this, you must have: System Type --> TI OMAP Implementations --> System Timer set to 'MPU timer'. Please change to 32k timer. Using MPU timer will keep timers not in WKUP powerdomain (which is all of them except GPT1) running across suspend, preventing PER from hitting RET. Using the 32k timer only uses GPT1 and sources it from the 32k clock, both of which are in the WKUP powerdomain. > MOD: CM_CCR (48004d00) > 00 => f8311037 04 => 00000017 20 => 00000201 30 => 00000009 > 34 => 00000001 40 => 094c0c00 44 => 0001b00c 48 => 00000009 > 50 => 00000001 70 => 00000003 > MOD: CM_DSS (48004e00) > 20 => 00000003 30 => 00000001 40 => 00001006 48 => 00000003 > MOD: CM_CAM (48004f00) > 20 => 00000001 30 => 00000001 40 => 00000004 48 => 00000003 > MOD: CM_PER (48005000) > 10 => 0003e000 20 => 00001fff 30 => 0003ffff 40 => 000000ff > 44 => 00000006 48 => 00000003 4c => 00000001 > MOD: CM_EMU (48005100) > 40 => 03020a50 48 => 00000002 4c => 00000001 > MOD: CM_NEON (48005300) > 48 => 00000003 > MOD: CM_USB (48005400) > 20 => 00000003 30 => 00000001 48 => 00000003 > MOD: PRM_IVA2 (48316000) > 50 => 00000007 e0 => 00ff0f04 f8 => 00000007 > MOD: PRM_OCP (48306800) > 04 => 00000010 14 => 00000001 1c => 00000201 > MOD: PRM_MPU (48306900) > 58 => 00000005 d4 => 00000012 e0 => 00030104 e4 => 000000c7 > e8 => 000000c7 > MOD: PRM_CORE (48306a00) > 58 => 00000301 a0 => c33ffe18 a4 => c33ffe18 a8 => c33ffe18 > e0 => 000f0304 e4 => 000000f7 e8 => 000000f7 f0 => 00000004 > f4 => 00000004 f8 => 00000004 > MOD: PRM_SGX (48306b00) > e0 => 00030104 > MOD: PRM_WKUP (48306c00) > a0 => 0000010b a4 => 0000010b > MOD: PRM_CCR (48306d00) > 40 => 00000003 > MOD: PRM_DSS (48306e00) > 58 => 00000005 a0 => 00000001 e0 => 00030104 > MOD: PRM_CAM (48306f00) > 58 => 00000001 e0 => 00030104 > MOD: PRM_PER (48307000) > 58 => 00000001 a0 => 0003efff a4 => 0003efff a8 => 0003efff > c8 => 00000007 e0 => 00030104 e4 => 00000007 e8 => 00000007 > MOD: PRM_EMU (48307100) > 58 => 00000005 e4 => 00000103 > MOD: PRM_GLBL (48307200) > 20 => 00120012 24 => 00010000 2c => 301e1e30 30 => 2c1e1e2c > 34 => 00120000 38 => 00000018 54 => 00001006 58 => 00000001 > 60 => 0000000e 64 => 00000050 70 => 00000088 90 => 0fff0fff > 94 => 000000ff 98 => 000000ff 9c => 00000002 a0 => 000000ff > c4 => 00000001 e4 => 00000001 > MOD: PRM_NEON (48307300) > 58 => 00000005 c8 => 00000002 e0 => 00000004 e4 => 00000003 > e8 => 00000003 > MOD: PRM_USB (48307400) > 58 => 00000001 a0 => 00000001 a4 => 00000001 a8 => 00000001 > e0 => 00030104 > > >> Also, post dump of >> > > root@beagleboard:/sys# cat /debug/pm_debug/count > usbhost_pwrdm (OFF),OFF:1,RET:1,INA:0,ON:1 > sgx_pwrdm (OFF),OFF:1,RET:0,INA:0,ON:1 > per_pwrdm (ON),OFF:0,RET:0,INA:0,ON:1 > dss_pwrdm (ON),OFF:2,RET:0,INA:0,ON:3 > cam_pwrdm (OFF),OFF:1,RET:1,INA:0,ON:1 > core_pwrdm (ON),OFF:0,RET:0,INA:0,ON:1 > neon_pwrdm (ON),OFF:2,RET:0,INA:14100,ON:14103 > mpu_pwrdm (ON),OFF:2,RET:0,INA:14100,ON:14103 > iva2_pwrdm (OFF),OFF:1,RET:1,INA:0,ON:1 > per_clkdm->per_pwrdm (9) > usbhost_clkdm->usbhost_pwrdm (0) > cam_clkdm->cam_pwrdm (0) > dss_clkdm->dss_pwrdm (2) > core_l4_clkdm->core_pwrdm (8) > core_l3_clkdm->core_pwrdm (4) > d2d_clkdm->core_pwrdm (0) > sgx_clkdm->sgx_pwrdm (0) > iva2_clkdm->iva2_pwrdm (0) > neon_clkdm->neon_pwrdm (0) > mpu_clkdm->mpu_pwrdm (0) > virt_opp_clkdm->wkup_pwrdm (0) > prm_clkdm->wkup_pwrdm (10) > cm_clkdm->core_pwrdm (3) Based on this, I see that you're DSS is not the problem anymore as it is hitting off, but neither PER nor CORE have made any transistions. PER is most likely because of the timer issue above. Not sure yet about CORE. In addtion to more details on your hardware and .config, Can you send me the console log of a full boot followed by trying just retention in suspend by doing the following right after boot: # cat /debug/pm_debug/count # echo 1 > /sys/power/clocks_off_while_idle # echo mem > /sys/power/state <after wakeup> # cat /debug/pm_debug/count # cat /debug/pm_debug/registers/1 Kevin -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
