<Tero.Kristo@xxxxxxxxx> writes: [...] >>>>> >>>>> + /* If DSS is active, prevent CORE RET/OFF */ >>>>> + dss_state = pwrdm_read_pwrst(dss_pd); >>>>> + if (dss_state == PWRDM_POWER_ON && >>>>> + core_next_state != PWRDM_POWER_ON) >>>>> + core_next_state = PWRDM_POWER_INACTIVE; >>>>> + >>>> >>>>Due to sleepdeps/autodeps, when this code runs, DSS powerdomain is >>>>always on. The result is that CORE is always set to INACTIVE. >>> >>> Now I recall that someone was asking about a patch similar to this >>> earlier, and had the same issue with DSS sleepdep collision. >> >>> >>> What is the reason for having the sleepdep for DSS powerdomain anyway? >>> At least I can't see any reason why the sleepdep for DSS should be >>> set. In my opinion it should be perfectly okay for DSS domain to idle >>> independently of MPU/CORE, as this is going to be better for power >>> consumption also. >> >>Agreed, but currently the sleepdeps with MPU are automatically managed >>(by clkdm autodeps and hwmod initiator deps.) Until we have merged a >>solution to more selectively enable sleepdeps (or remove them) $SUBJECT >>patch cannot be merged. > > Ok I thought this is the case... it would be possible to implement a > temporary/permanent solution that uses idle status check instead of > pwrdm state check, and prevent core idle if dss is not going to > idle. What is the current status with those idlest patches anyway? Paul will have to answer that one. 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
