On Tue, 2012-03-06 at 14:29 +0530, Rajendra Nayak wrote: > On Tuesday 06 March 2012 02:24 PM, Tero Kristo wrote: > > On Tue, 2012-03-06 at 14:13 +0530, Rajendra Nayak wrote: > >> On Tuesday 06 March 2012 02:01 PM, Tero Kristo wrote: > >>> On Mon, 2012-03-05 at 16:33 -0800, Kevin Hilman wrote: > >>>> Tero Kristo<t-kristo@xxxxxx> writes: > >>>> > >>>>> From: Rajendra Nayak<rnayak@xxxxxx> > >>>>> > >>>>> Remove the FIXME's in the suspend sequence since > >>>>> we now intend to support system level RET support. > >>>>> > >>>>> Signed-off-by: Rajendra Nayak<rnayak@xxxxxx> > >>>>> Signed-off-by: Tero Kristo<t-kristo@xxxxxx> > >>>>> Reviewed-by: Santosh Shilimkar<santosh.shilimkar@xxxxxx> > >>>> > >>>> So this is the only patch in this series that is still needed. However... > >>>> > >>>> It doesn't seem like this all by itself is ready for mainline as we'll > >>>> suddenly start putting all powerdomains in retention without any > >>>> additional support. > >>>> > >>>> I guess at a minimum it needs working IO wakeup support from the IO > >>>> daisy chain series. Are there other dependencies here? > >>> > >>> Only IO chain is needed for wakeup capability. Actually even with the > >>> current mainline kernel, I am unable to wake-up the device from MPU > >>> retention, as there are no wakeup sources. So this patch doesn't really > >> > >> Why?, doesn't debug console wakeup work? > > > > At least I couldn't get it to work. I tried with no_console_suspend > > kernel param to no avail. Don't know if I was missing something else. > > Did you try enabling wakeup for the debug console? > echo enabled > /sys/devices/platform/omap/omap_uart.2/tty/ttyO2/power/wakeup I think not, however I wonder why the wakeups are not enabled by default if this helps? > > > > > -Tero > > > >> > >>> change the behavior to worse even without any additional patches. :) But > >>> yea, good to wait until IO chain is in. > >> > >> IO chain, according to documentation :) should be needed only if you > >> hit OSWR or OFF, async wakeups should be functional as long as you > >> only hit CSWR. > >> > >>> > >>> The other dependencies are that the stuff handled by patches 2,3 and 4 > >>> have to be handled somehow: > >>> > >>> -patch2: must be in (this patch is queued by Paul) > >>> -patch3: will be taken care of by Paul's pwrdm fixes (I guess this is > >>> queued by Paul himself already) > >>> -patch4: OMAP interrupt count must be increased (this is handled by > >>> Benoit's patch, which is queued by Tony) > >>> > >>> -Tero > >>> > >>>> > >>>> If not, I can queue this when Paul is ready to merge the IO wakeup > >>>> stuff. > >>>> > >>>> Kevin > >>>> > >>>>> --- > >>>>> arch/arm/mach-omap2/pm44xx.c | 6 ------ > >>>>> 1 files changed, 0 insertions(+), 6 deletions(-) > >>>>> > >>>>> diff --git a/arch/arm/mach-omap2/pm44xx.c b/arch/arm/mach-omap2/pm44xx.c > >>>>> index c264ef7..1ab30a3 100644 > >>>>> --- a/arch/arm/mach-omap2/pm44xx.c > >>>>> +++ b/arch/arm/mach-omap2/pm44xx.c > >>>>> @@ -151,12 +151,6 @@ static int __init pwrdms_setup(struct powerdomain *pwrdm, void *unused) > >>>>> if (!strncmp(pwrdm->name, "cpu", 3)) > >>>>> return 0; > >>>>> > >>>>> - /* > >>>>> - * FIXME: Remove this check when core retention is supported > >>>>> - * Only MPUSS power domain is added in the list. > >>>>> - */ > >>>>> - if (strcmp(pwrdm->name, "mpu_pwrdm")) > >>>>> - return 0; > >>>>> > >>>>> pwrst = kmalloc(sizeof(struct power_state), GFP_ATOMIC); > >>>>> if (!pwrst) > >>> > >>> > >> > > > > > -- 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
