All of lore.kernel.org
 help / color / mirror / Atom feed
From: Kevin Hilman <khilman@ti.com>
To: t-kristo@ti.com
Cc: linux-omap@vger.kernel.org, paul@pwsan.com,
	linux-arm-kernel@lists.infradead.org
Subject: Re: [PATCHv5 8/8] ARM: OMAP4: PM: Added option for enabling OSWR
Date: Wed, 16 May 2012 11:03:45 -0700	[thread overview]
Message-ID: <87d364f1fi.fsf@ti.com> (raw)
In-Reply-To: <1337159445.2149.355.camel@sokoban> (Tero Kristo's message of "Wed, 16 May 2012 12:10:45 +0300")

Tero Kristo <t-kristo@ti.com> writes:

> On Tue, 2012-05-15 at 15:41 -0700, Kevin Hilman wrote:
>> Tero Kristo <t-kristo@ti.com> writes:
>> 
>> > PM debug now contains a file that can be used to control OSWR support
>> > enable / disable on OMAP4. Also removed the off_mode_enable file for
>> > the same platform as it is unsupported.
>> >>
>> > Signed-off-by: Tero Kristo <t-kristo@ti.com>
>> 
>> I'll gladly take a patch that makes enable_off_mode OMAP3-only, but I am
>> not interested managing another new flag for OSWR.
>> 
>> For OMAP4, this should just be the default, and any drivers that are
>> broken just need to be fixed either by implementing context save/restore
>> or by using constraints.
>
> Well, it is not flag as such, as it is static variable internal to
> pm-debug.c. I could drop this, however it is extremely useful as a
> testing feature. Without this, it is difficult to test CSWR / OSWR. 

I understand its usefulness for testing (and I will use it to test this
series), but IMO it should live out of tree.  Having this in tree makes
it possible for drivers to be merged that don't support off-mode.  I
added this flag to OMAP3 as a short-term feature hoping that drivers
would eventually be converted, and I was wrong.  We still have drivers
that don't support off-mode upstream.  I don't want to make that mistake
again.

> If you have taken a look at the device-off set, I am actually adding
> the flag back for omap4 there for enabling device off. If this flag is
> also dropped, the device will always just go to device off, in which
> case testing CSWR / OSWR becomes an issue again, and I don't think
> this is ideal.
>
> Speaking of enable_off_mode, it might be possible to change it also be
> static and remove all the references to it from code. Currently it is
> only used from cpuidle34xx.c.

I would prefer to get rid of all of these flags, and use the new sysfs
controls[1] for CPUidle C-states to disable/enable certain C-states for
debugging/testing.

Kevin

[1] Example shell snippet using new sysfs interface:

# CPUidle: disable everything but C1
cd /sys/devices/system/cpu/cpu0/cpuidle
for state in state[1-6]*; do
  if [ -e ${state} ]; then
    echo 1 > ${state}/disable
  fi
done


WARNING: multiple messages have this Message-ID (diff)
From: khilman@ti.com (Kevin Hilman)
To: linux-arm-kernel@lists.infradead.org
Subject: [PATCHv5 8/8] ARM: OMAP4: PM: Added option for enabling OSWR
Date: Wed, 16 May 2012 11:03:45 -0700	[thread overview]
Message-ID: <87d364f1fi.fsf@ti.com> (raw)
In-Reply-To: <1337159445.2149.355.camel@sokoban> (Tero Kristo's message of "Wed, 16 May 2012 12:10:45 +0300")

Tero Kristo <t-kristo@ti.com> writes:

> On Tue, 2012-05-15 at 15:41 -0700, Kevin Hilman wrote:
>> Tero Kristo <t-kristo@ti.com> writes:
>> 
>> > PM debug now contains a file that can be used to control OSWR support
>> > enable / disable on OMAP4. Also removed the off_mode_enable file for
>> > the same platform as it is unsupported.
>> >>
>> > Signed-off-by: Tero Kristo <t-kristo@ti.com>
>> 
>> I'll gladly take a patch that makes enable_off_mode OMAP3-only, but I am
>> not interested managing another new flag for OSWR.
>> 
>> For OMAP4, this should just be the default, and any drivers that are
>> broken just need to be fixed either by implementing context save/restore
>> or by using constraints.
>
> Well, it is not flag as such, as it is static variable internal to
> pm-debug.c. I could drop this, however it is extremely useful as a
> testing feature. Without this, it is difficult to test CSWR / OSWR. 

I understand its usefulness for testing (and I will use it to test this
series), but IMO it should live out of tree.  Having this in tree makes
it possible for drivers to be merged that don't support off-mode.  I
added this flag to OMAP3 as a short-term feature hoping that drivers
would eventually be converted, and I was wrong.  We still have drivers
that don't support off-mode upstream.  I don't want to make that mistake
again.

> If you have taken a look at the device-off set, I am actually adding
> the flag back for omap4 there for enabling device off. If this flag is
> also dropped, the device will always just go to device off, in which
> case testing CSWR / OSWR becomes an issue again, and I don't think
> this is ideal.
>
> Speaking of enable_off_mode, it might be possible to change it also be
> static and remove all the references to it from code. Currently it is
> only used from cpuidle34xx.c.

I would prefer to get rid of all of these flags, and use the new sysfs
controls[1] for CPUidle C-states to disable/enable certain C-states for
debugging/testing.

Kevin

[1] Example shell snippet using new sysfs interface:

# CPUidle: disable everything but C1
cd /sys/devices/system/cpu/cpu0/cpuidle
for state in state[1-6]*; do
  if [ -e ${state} ]; then
    echo 1 > ${state}/disable
  fi
done

  reply	other threads:[~2012-05-16 18:03 UTC|newest]

Thread overview: 56+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2012-05-14 10:03 [PATCHv5 0/8] ARM: OMAP4: core retention support Tero Kristo
2012-05-14 10:03 ` Tero Kristo
2012-05-14 10:03 ` [PATCHv5 1/8] ARM: OMAP4: suspend: Program all domains to retention Tero Kristo
2012-05-14 10:03   ` Tero Kristo
2012-05-15 19:52   ` Kevin Hilman
2012-05-15 19:52     ` Kevin Hilman
2012-05-16  8:37     ` Tero Kristo
2012-05-16  8:37       ` Tero Kristo
2012-05-14 10:03 ` [PATCHv5 2/8] TEMP: ARM: OMAP4: hwmod_data: Do not get DSP out of reset at boot time Tero Kristo
2012-05-14 10:03   ` Tero Kristo
2012-05-14 10:03 ` [PATCHv5 3/8] ARM: OMAP4460: Workaround for ROM bug because of CA9 r2pX gic control register change Tero Kristo
2012-05-14 10:03   ` Tero Kristo
2012-05-15 21:44   ` Kevin Hilman
2012-05-15 21:44     ` Kevin Hilman
2012-05-16  8:54     ` Tero Kristo
2012-05-16  8:54       ` Tero Kristo
2012-05-16  9:16     ` Santosh Shilimkar
2012-05-16  9:16       ` Santosh Shilimkar
2012-05-16 12:23       ` Santosh Shilimkar
2012-05-16 12:23         ` Santosh Shilimkar
2012-05-16 16:51         ` Kevin Hilman
2012-05-16 16:51           ` Kevin Hilman
2012-05-17  6:46           ` Shilimkar, Santosh
2012-05-17  6:46             ` Shilimkar, Santosh
2012-05-17 17:15             ` Kevin Hilman
2012-05-17 17:15               ` Kevin Hilman
2012-05-18  6:05               ` Shilimkar, Santosh
2012-05-18  6:05                 ` Shilimkar, Santosh
2012-05-18 14:13                 ` Kevin Hilman
2012-05-18 14:13                   ` Kevin Hilman
2012-05-16 12:31   ` Santosh Shilimkar
2012-05-16 12:31     ` Santosh Shilimkar
2012-05-14 10:03 ` [PATCHv5 4/8] ARM: OMAP4: hwmod: flag hwmods/modules supporting module level context status Tero Kristo
2012-05-14 10:03   ` Tero Kristo
2012-05-14 10:03 ` [PATCHv5 5/8] ARM: OMAP: hwmod: Add support for per hwmod/module context lost count Tero Kristo
2012-05-14 10:03   ` Tero Kristo
2012-05-29 19:32   ` Menon, Nishanth
2012-05-29 19:32     ` Menon, Nishanth
2012-05-30  8:02     ` Tero Kristo
2012-05-30  8:02       ` Tero Kristo
2012-05-14 10:03 ` [PATCHv5 6/8] ARM: OMAP4: pwrdm: add support for reading prev logic and mem states Tero Kristo
2012-05-14 10:03   ` Tero Kristo
2012-05-15 22:36   ` Kevin Hilman
2012-05-15 22:36     ` Kevin Hilman
2012-05-16  8:55     ` Tero Kristo
2012-05-16  8:55       ` Tero Kristo
2012-05-14 10:03 ` [PATCHv5 7/8] ARM: OMAP4: PM: Add next_logic_state param to power_state Tero Kristo
2012-05-14 10:03   ` Tero Kristo
2012-05-14 10:03 ` [PATCHv5 8/8] ARM: OMAP4: PM: Added option for enabling OSWR Tero Kristo
2012-05-14 10:03   ` Tero Kristo
2012-05-15 22:41   ` Kevin Hilman
2012-05-15 22:41     ` Kevin Hilman
2012-05-16  9:10     ` Tero Kristo
2012-05-16  9:10       ` Tero Kristo
2012-05-16 18:03       ` Kevin Hilman [this message]
2012-05-16 18:03         ` Kevin Hilman

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=87d364f1fi.fsf@ti.com \
    --to=khilman@ti.com \
    --cc=linux-arm-kernel@lists.infradead.org \
    --cc=linux-omap@vger.kernel.org \
    --cc=paul@pwsan.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.