public inbox for linux-omap@vger.kernel.org
 help / color / mirror / Atom feed
From: "Mark A. Greer" <mgreer@animalcreek.com>
To: Paul Walmsley <paul@pwsan.com>
Cc: linux-omap@vger.kernel.org, linux-arm-kernel@lists.infradead.org,
	khilman@ti.com
Subject: Re: [PATCH 07/12] arm: omap3: am35x: Set proper powerdomain states
Date: Wed, 11 Apr 2012 15:40:31 -0700	[thread overview]
Message-ID: <20120411224031.GD31197@animalcreek.com> (raw)
In-Reply-To: <alpine.DEB.2.00.1204111546110.29473@utopia.booyaka.com>

On Wed, Apr 11, 2012 at 03:53:30PM -0600, Paul Walmsley wrote:
> Hi
> 
> On Wed, 11 Apr 2012, Mark A. Greer wrote:
> 
> > From: "Mark A. Greer" <mgreer@animalcreek.com>
> > 
> > The am35x family of SoCs only support PWRSTS_ON
> > and PWRSTS_INACTIVE states so create a new set
> > of powerdomain structures that ensure that only
> > the ON and INACTIVE states are entered.
> 
> I'm still unsure what we should do about this INACTIVE state.  As far as I 
> can tell, it does not actually represent a distinct powerdomain state on 
> OMAP3.  We can't write it to the PM_PWSTCTRL_*.POWERSTATE bits, since that 
> value is marked as "reserved".  And SPRUGR0B, the AM3517/3505 TRM, 
> explicitly states "This register should not be programmed with reserved 
> values of bit fields for proper functioning of power state control."
> Of course SPRUGR0B also claims that AM3517/3505 supports RETENTION, so 
> that is relatively confusing.

Yep.  You read one section which tells you the device doesn't support
such-and-such then it goes on for pages describing how it works.  I play
with the hardware and the registers are there so it seems like it should
work.  Its been an "adventure". :)

> OMAP4 PRCM actually does seem to support powerdomain INACTIVE state, 
> although it does not actually seem to represent a separate state.  As I 
> understand it, it simply allows the clockdomains in the powerdomain to 
> transitioning from the ACTIVE state into the INACTIVE state.  In other 
> words, it doesn't affect the powerdomain power state at all.  And on OMAP4 
> it's referred to as the ON-INACTIVE state, to clarify that it is simply a 
> variant of the ON state.  I wish they had just added a separate bit for 
> this; it would have avoided some frustration...
> 
> Anyway, my question is this: is there any point at all to defining the 
> INACTIVE state for 3517/3505, given that it apparently cannot be read 
> from, nor written to the PRCM hardware?

Great question and I really don't know the answer--its too hard to know
what's for real and what isn't in the TRM.  Maybe it is best to get rid
of INACTIVE and just leave everything ON.

Mark
--

  reply	other threads:[~2012-04-11 23:36 UTC|newest]

Thread overview: 63+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2012-04-11 19:05 arm: omap3: am35x: Powerdomain, EMIF4, etc. fixups Mark A. Greer
2012-04-11 19:05 ` [PATCH 01/12] arm: omap3: Only access IVA if one exists Mark A. Greer
2012-04-11 19:05 ` [PATCH 02/12] arm: omap3: Only sleep during cpu_idle if I/O wake-ups work Mark A. Greer
2012-04-11 21:38   ` Paul Walmsley
2012-04-11 23:42   ` Jon Hunter
2012-04-13  0:13     ` Mark A. Greer
2012-04-11 19:05 ` [PATCH 03/12] arm: omap3: Only sleep in cpuidle driver " Mark A. Greer
2012-04-11 21:37   ` Paul Walmsley
2012-04-11 22:23     ` Mark A. Greer
2012-04-11 22:47       ` Paul Walmsley
2012-04-11 23:08         ` Mark A. Greer
2012-04-24 20:51     ` Mark A. Greer
2012-04-24 23:25       ` Mark A. Greer
2012-04-27 21:12         ` Kevin Hilman
2012-04-27 21:55           ` Mark A. Greer
2012-04-30 21:34           ` Mark A. Greer
2012-04-30 22:00             ` Kevin Hilman
2012-04-30 22:18               ` Mark A. Greer
2012-04-11 19:05 ` [PATCH 04/12] arm: omap3: am35x: Don't mark missing features as present Mark A. Greer
2012-04-11 19:05 ` [PATCH 05/12] arm: omap3: am35x: Add PWROFF feature Mark A. Greer
2012-04-11 22:46   ` Kevin Hilman
2012-04-11 23:11     ` Mark A. Greer
2012-04-24  4:36     ` Mark A. Greer
2012-04-27 21:07       ` Kevin Hilman
2012-04-30 22:08         ` Mark A. Greer
2012-04-11 19:05 ` [PATCH 06/12] arm: omap3: am35x: Add full PWRDM_POWER_INACTIVE support Mark A. Greer
2012-04-11 20:56   ` Jean Pihet
2012-04-11 21:08     ` Paul Walmsley
2012-04-11 21:14       ` Mark A. Greer
2012-04-11 21:15         ` Jean Pihet
2012-04-11 21:12     ` Mark A. Greer
2012-04-11 22:17   ` Paul Walmsley
2012-04-11 19:05 ` [PATCH 07/12] arm: omap3: am35x: Set proper powerdomain states Mark A. Greer
2012-04-11 21:53   ` Paul Walmsley
2012-04-11 22:40     ` Mark A. Greer [this message]
2012-04-12  0:24       ` Jon Hunter
2012-04-12  2:19         ` Mark A. Greer
2012-04-11 19:05 ` [PATCH 08/12] arm: omap3: am35x: Fix clockdomain dependencies Mark A. Greer
2012-04-11 21:44   ` Paul Walmsley
2012-04-11 21:55     ` Mark A. Greer
2012-04-11 22:04       ` Paul Walmsley
2012-04-11 22:49         ` Mark A. Greer
2012-04-11 23:49           ` Paul Walmsley
2012-04-12  2:23             ` Mark A. Greer
2012-04-12  2:29               ` Paul Walmsley
2012-04-12 23:00                 ` Mark A. Greer
2012-04-11 19:05 ` [PATCH 09/12] arm: omap3: am35x: Add SDRC EMIF4 feature Mark A. Greer
2012-04-11 21:29   ` Paul Walmsley
2012-04-11 22:50     ` Mark A. Greer
2012-04-11 22:56   ` Paul Walmsley
2012-04-11 23:23     ` Mark A. Greer
2012-04-11 19:05 ` [PATCH 10/12] arm: omap3: am35x: Add minimal EMIF4 support Mark A. Greer
2012-04-11 21:31   ` Paul Walmsley
2012-04-11 23:22     ` Mark A. Greer
2012-04-11 19:05 ` [PATCH 11/12] arm: omap3: am35x: Add do_wfi routine for EMIF4 submodules Mark A. Greer
2012-04-11 22:35   ` Kevin Hilman
2012-04-11 23:26     ` Mark A. Greer
2012-04-11 22:36   ` Paul Walmsley
2012-04-13  0:12     ` Mark A. Greer
2012-04-11 22:54   ` Paul Walmsley
2012-04-11 19:05 ` [PATCH 12/12] arm: omap3: am35x: Register davinci_mdio before davinci_emac Mark A. Greer
2012-04-11 21:24   ` Paul Walmsley
2012-04-11 22:00     ` Mark A. Greer

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=20120411224031.GD31197@animalcreek.com \
    --to=mgreer@animalcreek.com \
    --cc=khilman@ti.com \
    --cc=linux-arm-kernel@lists.infradead.org \
    --cc=linux-omap@vger.kernel.org \
    --cc=paul@pwsan.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox