Jean Pihet <jean.pihet@xxxxxxxxxxxxxx> writes: > Hi Kevin, Paul, > > On Fri, Jan 27, 2012 at 3:03 PM, Sakari Ailus <sakari.ailus@xxxxxx> wrote: >> Hi Jean, >> >> Thanks for you quick reply. >> >> On Fri, Jan 27, 2012 at 12:06:37PM +0100, Jean Pihet wrote: >>> Hi, >>> >>> On Fri, Jan 27, 2012 at 11:00 AM, Sakari Ailus <sakari.ailus@xxxxxx> wrote: >>> > MPU and CORE should stay awake if there is CAM domain ACTIVE. This is >>> > because that module doesn't have wake-up capability. >>> > >>> > The original patch was written by Jouni Högander in 2008 and this is the >>> > last part left of it which is not in upstream yet. >>> > >>> > I wonder if the approach taken in the patch is valid these days; >>> > nevertheless it seems to do the job... >>> The code in the function omap3_enter_idle_bm from >>> arch/arm/mach-omap2/cpuidle34xx.c is doing exactly the same thing: it >>> is choosing the cpuidle safe_state if the CAM power domain is active. >>> >>> Please note that this only works if CPU_IDLE is selected, which is >>> needed to reach any decent low power mode. >> >> I didn't have CONFIG_CPU_IDLE selected --- it works if I enable it. But >> still it should work even if it's disabled I guess. > What is your call on this? We made a concious decision a while back to move any idle decision making out of pm34xx.c and into the CPUidle driver. Longer term, the goal is that CPUidle should not be handling this either. CPUidle is for the CPU, not for the rest of the devices. Device constrataints should be handled by the device code itself. 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
