All of lore.kernel.org
 help / color / mirror / Atom feed
From: Rajendra Nayak <rnayak@ti.com>
To: t-kristo@ti.com
Cc: linux-omap@vger.kernel.org, linux-arm-kernel@lists.infradead.org,
	paul@pwsan.com, khilman@ti.com, b-cousson@ti.com,
	santosh.shilimkar@ti.com
Subject: Re: [RFC 0/4] OMAP Cpuidle/Suspend Cleanups
Date: Fri, 20 Jul 2012 14:33:28 +0530	[thread overview]
Message-ID: <50091EE0.1020007@ti.com> (raw)
In-Reply-To: <1342774773.4672.187.camel@sokoban>

On Friday 20 July 2012 02:29 PM, Tero Kristo wrote:
> On Fri, 2012-07-20 at 11:34 +0530, Rajendra Nayak wrote:
>> Hi,
>>
>> Here are some CPUidle/Suspend cleanup patches done by adding
>> some more functionality in the OMAP Powerdomain framework.
>> They mostly cleanup OMAP3 but the same ideas can be used/
>> applied for OMAP4 and beyond.
>>
>> The series is based off Teros' series [1] to add usecounting
>> support within the OMAP Powerdomain framework.
>>
>> The patches are tested with RET/OFF in CPUidle and Suspend
>> on 3630 beagle Xm and 3430 SDP.
>
> This set looks good to me, just requires careful testing that you don't
> break anything as you are moving lots of stuff around. For debugging
> purposes (maybe also permanently?), it might be good to keep some sort
> of failsafe mechanism in place that prevents actual core / per off
> transitions in case there is a problem with the usecounting, and you
> accidentally hit core / per off even though the usecounting doesn't
> expect it (some autoidle mechanism is overlooked for example.)
>
> Maybe add some caching for the programmed next state, and only program
> the HW register once we get to the callbacks, and restore the next state
> to ON after leaving...? This should get rid of any unexpected hangs.ly

Thats exactly what I have been thinking too. The caching is turning out
to be a little tricky though. But something like that would certainly be
needed, and should also get rid of unwanted (multiple) target state
programming.

>
> -Tero
>
>>
>> regards,
>> Rajendra
>>
>> [1] http://www.mail-archive.com/linux-omap@vger.kernel.org/msg72163.html
>>
>> Rajendra Nayak (4):
>>    ARM: OMAP3: cpuidle: Remove unused MPU OSWR support code
>>    ARM: OMAP: PM: Get rid of Powerdomain book-keeping from cpuidle
>>    ARM: OMAP: powerdomain: Add .power_on/.power_down hooks for
>>      powerdomains
>>    ARM: OMAP3: PM: Use .power_on/.power_down to clean omap_sram_idle
>>
>>   arch/arm/mach-omap2/omap-mpuss-lowpower.c |    4 +-
>>   arch/arm/mach-omap2/pm34xx.c              |  158 ++++++++++++++---------------
>>   arch/arm/mach-omap2/powerdomain.c         |   40 ++++----
>>   arch/arm/mach-omap2/powerdomain.h         |    8 +-
>>   arch/arm/mach-omap2/sleep34xx.S           |    4 +-
>>   5 files changed, 104 insertions(+), 110 deletions(-)
>>
>
>


WARNING: multiple messages have this Message-ID (diff)
From: rnayak@ti.com (Rajendra Nayak)
To: linux-arm-kernel@lists.infradead.org
Subject: [RFC 0/4] OMAP Cpuidle/Suspend Cleanups
Date: Fri, 20 Jul 2012 14:33:28 +0530	[thread overview]
Message-ID: <50091EE0.1020007@ti.com> (raw)
In-Reply-To: <1342774773.4672.187.camel@sokoban>

On Friday 20 July 2012 02:29 PM, Tero Kristo wrote:
> On Fri, 2012-07-20 at 11:34 +0530, Rajendra Nayak wrote:
>> Hi,
>>
>> Here are some CPUidle/Suspend cleanup patches done by adding
>> some more functionality in the OMAP Powerdomain framework.
>> They mostly cleanup OMAP3 but the same ideas can be used/
>> applied for OMAP4 and beyond.
>>
>> The series is based off Teros' series [1] to add usecounting
>> support within the OMAP Powerdomain framework.
>>
>> The patches are tested with RET/OFF in CPUidle and Suspend
>> on 3630 beagle Xm and 3430 SDP.
>
> This set looks good to me, just requires careful testing that you don't
> break anything as you are moving lots of stuff around. For debugging
> purposes (maybe also permanently?), it might be good to keep some sort
> of failsafe mechanism in place that prevents actual core / per off
> transitions in case there is a problem with the usecounting, and you
> accidentally hit core / per off even though the usecounting doesn't
> expect it (some autoidle mechanism is overlooked for example.)
>
> Maybe add some caching for the programmed next state, and only program
> the HW register once we get to the callbacks, and restore the next state
> to ON after leaving...? This should get rid of any unexpected hangs.ly

Thats exactly what I have been thinking too. The caching is turning out
to be a little tricky though. But something like that would certainly be
needed, and should also get rid of unwanted (multiple) target state
programming.

>
> -Tero
>
>>
>> regards,
>> Rajendra
>>
>> [1] http://www.mail-archive.com/linux-omap at vger.kernel.org/msg72163.html
>>
>> Rajendra Nayak (4):
>>    ARM: OMAP3: cpuidle: Remove unused MPU OSWR support code
>>    ARM: OMAP: PM: Get rid of Powerdomain book-keeping from cpuidle
>>    ARM: OMAP: powerdomain: Add .power_on/.power_down hooks for
>>      powerdomains
>>    ARM: OMAP3: PM: Use .power_on/.power_down to clean omap_sram_idle
>>
>>   arch/arm/mach-omap2/omap-mpuss-lowpower.c |    4 +-
>>   arch/arm/mach-omap2/pm34xx.c              |  158 ++++++++++++++---------------
>>   arch/arm/mach-omap2/powerdomain.c         |   40 ++++----
>>   arch/arm/mach-omap2/powerdomain.h         |    8 +-
>>   arch/arm/mach-omap2/sleep34xx.S           |    4 +-
>>   5 files changed, 104 insertions(+), 110 deletions(-)
>>
>
>

  reply	other threads:[~2012-07-20  9:03 UTC|newest]

Thread overview: 48+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2012-07-20  6:04 [RFC 0/4] OMAP Cpuidle/Suspend Cleanups Rajendra Nayak
2012-07-20  6:04 ` Rajendra Nayak
2012-07-20  6:04 ` [RFC 1/4] ARM: OMAP3: cpuidle: Remove unused MPU OSWR support code Rajendra Nayak
2012-07-20  6:04   ` Rajendra Nayak
2012-07-20  7:08   ` Shilimkar, Santosh
2012-07-20  7:08     ` Shilimkar, Santosh
2012-07-20 18:25   ` Paul Walmsley
2012-07-20 18:25     ` Paul Walmsley
2012-07-23  7:10     ` Rajendra Nayak
2012-07-23  7:10       ` Rajendra Nayak
2012-07-20  6:04 ` [RFC 2/4] ARM: OMAP: PM: Get rid of Powerdomain book-keeping from cpuidle Rajendra Nayak
2012-07-20  6:04   ` Rajendra Nayak
2012-07-20  7:25   ` Shilimkar, Santosh
2012-07-20  7:25     ` Shilimkar, Santosh
2012-07-20  8:08     ` Rajendra Nayak
2012-07-20  8:08       ` Rajendra Nayak
2012-07-20  8:51       ` Tero Kristo
2012-07-20  8:51         ` Tero Kristo
2012-07-20 11:54         ` Shilimkar, Santosh
2012-07-20 11:54           ` Shilimkar, Santosh
2012-07-25 22:43         ` Kevin Hilman
2012-07-25 22:43           ` Kevin Hilman
2012-07-26 11:43           ` Rajendra Nayak
2012-07-26 11:43             ` Rajendra Nayak
2012-07-26 12:42           ` Rajendra Nayak
2012-07-26 12:42             ` Rajendra Nayak
2012-07-26 17:44             ` Kevin Hilman
2012-07-26 17:44               ` Kevin Hilman
2012-07-26 18:27               ` Tero Kristo
2012-07-26 18:27                 ` Tero Kristo
2012-07-26 20:50                 ` Paul Walmsley
2012-07-26 20:50                   ` Paul Walmsley
2012-07-27  6:46                 ` Rajendra Nayak
2012-07-27  6:46                   ` Rajendra Nayak
2012-07-27  7:43                   ` Rajendra Nayak
2012-07-27  7:43                     ` Rajendra Nayak
2012-07-20  6:04 ` [RFC 3/4] ARM: OMAP: powerdomain: Add .power_on/.power_down hooks for powerdomains Rajendra Nayak
2012-07-20  6:04   ` Rajendra Nayak
2012-07-20  7:26   ` Shilimkar, Santosh
2012-07-20  7:26     ` Shilimkar, Santosh
2012-07-20  6:04 ` [RFC 4/4] ARM: OMAP3: PM: Use .power_on/.power_down to clean omap_sram_idle Rajendra Nayak
2012-07-20  6:04   ` Rajendra Nayak
2012-07-20  7:30   ` Shilimkar, Santosh
2012-07-20  7:30     ` Shilimkar, Santosh
2012-07-20  8:59 ` [RFC 0/4] OMAP Cpuidle/Suspend Cleanups Tero Kristo
2012-07-20  8:59   ` Tero Kristo
2012-07-20  9:03   ` Rajendra Nayak [this message]
2012-07-20  9:03     ` Rajendra Nayak

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=50091EE0.1020007@ti.com \
    --to=rnayak@ti.com \
    --cc=b-cousson@ti.com \
    --cc=khilman@ti.com \
    --cc=linux-arm-kernel@lists.infradead.org \
    --cc=linux-omap@vger.kernel.org \
    --cc=paul@pwsan.com \
    --cc=santosh.shilimkar@ti.com \
    --cc=t-kristo@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.