Re: [PATCH 07/12] arm: omap3: am35x: Set proper powerdomain states

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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@xxxxxxxxxxxxxxx>
> > 
> > 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
--
--
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


[Index of Archives]     [Linux Arm (vger)]     [ARM Kernel]     [ARM MSM]     [Linux Tegra]     [Linux WPAN Networking]     [Linux Wireless Networking]     [Maemo Users]     [Linux USB Devel]     [Video for Linux]     [Linux Audio Users]     [Yosemite Trails]     [Linux Kernel]     [Linux SCSI]

  Powered by Linux