From: Tero Kristo <t-kristo@ti.com>
To: Rajendra Nayak <rnayak@ti.com>
Cc: Kevin Hilman <khilman@ti.com>,
linux-omap@vger.kernel.org, paul@pwsan.com,
linux-arm-kernel@lists.infradead.org
Subject: Re: [PATCHv3 1/4] ARM: OMAP4: suspend: Program all domains to retention
Date: Tue, 6 Mar 2012 11:23:53 +0200 [thread overview]
Message-ID: <1331025833.2116.159.camel@sokoban> (raw)
In-Reply-To: <4F55D1D6.80909@ti.com>
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@ti.com> writes:
> >>>>
> >>>>> From: Rajendra Nayak<rnayak@ti.com>
> >>>>>
> >>>>> Remove the FIXME's in the suspend sequence since
> >>>>> we now intend to support system level RET support.
> >>>>>
> >>>>> Signed-off-by: Rajendra Nayak<rnayak@ti.com>
> >>>>> Signed-off-by: Tero Kristo<t-kristo@ti.com>
> >>>>> Reviewed-by: Santosh Shilimkar<santosh.shilimkar@ti.com>
> >>>>
> >>>> 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)
> >>>
> >>>
> >>
> >
> >
>
WARNING: multiple messages have this Message-ID (diff)
From: t-kristo@ti.com (Tero Kristo)
To: linux-arm-kernel@lists.infradead.org
Subject: [PATCHv3 1/4] ARM: OMAP4: suspend: Program all domains to retention
Date: Tue, 6 Mar 2012 11:23:53 +0200 [thread overview]
Message-ID: <1331025833.2116.159.camel@sokoban> (raw)
In-Reply-To: <4F55D1D6.80909@ti.com>
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@ti.com> writes:
> >>>>
> >>>>> From: Rajendra Nayak<rnayak@ti.com>
> >>>>>
> >>>>> Remove the FIXME's in the suspend sequence since
> >>>>> we now intend to support system level RET support.
> >>>>>
> >>>>> Signed-off-by: Rajendra Nayak<rnayak@ti.com>
> >>>>> Signed-off-by: Tero Kristo<t-kristo@ti.com>
> >>>>> Reviewed-by: Santosh Shilimkar<santosh.shilimkar@ti.com>
> >>>>
> >>>> 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)
> >>>
> >>>
> >>
> >
> >
>
next prev parent reply other threads:[~2012-03-06 9:24 UTC|newest]
Thread overview: 34+ messages / expand[flat|nested] mbox.gz Atom feed top
2012-02-29 15:25 [PATCHv3 0/4] ARM: OMAP4: core retention support Tero Kristo
2012-02-29 15:25 ` Tero Kristo
2012-02-29 15:25 ` [PATCHv3 1/4] ARM: OMAP4: suspend: Program all domains to retention Tero Kristo
2012-02-29 15:25 ` Tero Kristo
2012-03-06 0:33 ` Kevin Hilman
2012-03-06 0:33 ` Kevin Hilman
2012-03-06 8:31 ` Tero Kristo
2012-03-06 8:31 ` Tero Kristo
2012-03-06 8:43 ` Rajendra Nayak
2012-03-06 8:43 ` Rajendra Nayak
2012-03-06 8:54 ` Tero Kristo
2012-03-06 8:54 ` Tero Kristo
2012-03-06 8:59 ` Rajendra Nayak
2012-03-06 8:59 ` Rajendra Nayak
2012-03-06 9:23 ` Tero Kristo [this message]
2012-03-06 9:23 ` Tero Kristo
2012-02-29 15:25 ` [PATCHv3 2/4] ARM: OMAP4: prm: fix interrupt register offsets Tero Kristo
2012-02-29 15:25 ` Tero Kristo
2012-02-29 16:51 ` Paul Walmsley
2012-02-29 16:51 ` Paul Walmsley
2012-02-29 15:25 ` [PATCHv3 3/4] TEMP: ARM: OMAP4: hwmod_data: Do not get DSP out of reset at boot time Tero Kristo
2012-02-29 15:25 ` Tero Kristo
2012-02-29 15:25 ` [PATCHv3 4/4] ARM: OMAP3+: add prcm chain interrupts to the interrupt list Tero Kristo
2012-02-29 15:25 ` Tero Kristo
2012-03-01 7:01 ` Rajendra Nayak
2012-03-01 7:01 ` Rajendra Nayak
2012-03-01 8:23 ` Tero Kristo
2012-03-01 8:23 ` Tero Kristo
2012-03-01 9:46 ` Russell King - ARM Linux
2012-03-01 9:46 ` Russell King - ARM Linux
2012-03-01 10:03 ` Tero Kristo
2012-03-01 10:03 ` Tero Kristo
2012-02-29 15:34 ` [PATCHv3 0/4] ARM: OMAP4: core retention support Shilimkar, Santosh
2012-02-29 15:34 ` Shilimkar, Santosh
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=1331025833.2116.159.camel@sokoban \
--to=t-kristo@ti.com \
--cc=khilman@ti.com \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=linux-omap@vger.kernel.org \
--cc=paul@pwsan.com \
--cc=rnayak@ti.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.