>-----Original Message----- >From: linux-omap-owner@xxxxxxxxxxxxxxx [mailto:linux-omap- >owner@xxxxxxxxxxxxxxx] On Behalf Of ext Kevin Hilman >Sent: 04 March, 2011 18:56 >To: Kristo Tero (Nokia-MS/Tampere) >Cc: paul@xxxxxxxxx; linux-omap@xxxxxxxxxxxxxxx; linux-arm- >kernel@xxxxxxxxxxxxxxxxxxx >Subject: Re: [PATCH 1/2] OMAP3: cpuidle: prevent CORE power domain from >going to RET or OFF when DSS is on > >Hi Tero, > ><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? -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
