On Thu, 2012-11-22 at 16:44 +0200, Tomi Valkeinen wrote: > On 2012-11-22 16:34, Tero Kristo wrote: > > > I guess you checked that DSS pwrdm is switching between RET and ON in > > your setup? > > Yes: > > # cat /debug/pm_debug/count |grep dss > [ 35.356567] pwrdm state mismatch(l3init_pwrdm) 3 != 1 > [ 35.361938] pwrdm state mismatch(cam_pwrdm) 3 != 0 > [ 35.366973] pwrdm state mismatch(ivahd_pwrdm) 3 != 1 > [ 35.372253] pwrdm state mismatch(tesla_pwrdm) 3 != 1 > [ 35.377532] pwrdm state mismatch(abe_pwrdm) 3 != 1 > dss_pwrdm (RET),OFF:1,RET:11,INA:0,ON:11,RET-LOGIC-OFF:0,RET-MEMBANK1-OFF:0 > l3_dss_clkdm->dss_pwrdm (0) > > then I load and unload the dss modules, and then: > > # cat /debug/pm_debug/count |grep dss > [ 60.813629] pwrdm state mismatch(l3init_pwrdm) 3 != 1 > [ 60.819000] pwrdm state mismatch(cam_pwrdm) 3 != 0 > [ 60.824127] pwrdm state mismatch(ivahd_pwrdm) 3 != 1 > [ 60.829376] pwrdm state mismatch(tesla_pwrdm) 3 != 1 > [ 60.834625] pwrdm state mismatch(abe_pwrdm) 3 != 1 > dss_pwrdm (ON),OFF:1,RET:21,INA:0,ON:22,RET-LOGIC-OFF:0,RET-MEMBANK1-OFF:0 > l3_dss_clkdm->dss_pwrdm (0) > > >> Does the pwrdm mistakenly think that in RET state the DSS still keeps > >> the register contents? > > > > This might be the case, however the pwrdm code should be generic and > > handle all domains properly. What is the tree / branch / commit you are > > using for testing this stuff? I can take a look at this also. > > arm-soc/for-next I guess this is caused because some of the patches are still not in the for-next branch, it looks like at least this is missing: https://patchwork.kernel.org/patch/1608901/ ...or the latest update done by Paul to that one. The patch I posted appears to have a small merge induced bug, it is registering the context loss soc_ops for am33xx when it should actually register those for omap4. This might explain another bug I've been looking at in a different branch recently... The update Paul posted does not seem to have this problem, but I haven't tested it myself. -Tero -- 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
