On Wed, May 02, 2012 at 14:50:21, Kristo, Tero wrote:
> On Wed, 2012-05-02 at 10:45 +0200, Bedia, Vaibhav wrote:
> > Hi Tero,
> >
> > On Fri, Apr 20, 2012 at 14:49:49, Kristo, Tero wrote:
> > > From: Axel Haslam <axelhaslam@xxxxxxxxx>
> > >
> > > On OMAP4, there is no support to read previous logic state
> > > or previous memory state achieved when a power domain transitions
> > > to RET. Instead there are module level context registers.
> > >
> > > In order to support the powerdomain level logic/mem_off_counters
> > > on OMAP4, instead use the previous power state achieved (RET) and
> > > the *programmed* logic/mem RET state to derive if a powerdomain lost
> > > logic or did not.
> > >
> > > If the powerdomain is programmed to enter RET state and lose logic
> > > in RET state, knowing that the powerdomain entered RET is good enough
> > > to derive that the logic was lost as well, in such cases.
> > >
> >
> > Unfortunately this won't scale for AM33xx devices :(
> > It neither has module level context registers nor previous logic/memory state
> > registers in PRCM.
> >
> > At a top level, there's a Cortex-M3 (CM3) to assist the low power state transitions
> > and the indication of successful transition to a low power states is handled as part
> > of the IPC mechanism between the MPU (A8) and CM3 which is s/w defined.
> >
> > Since the various APIs like omap_hwmod_get_context_loss_context() and friends are
> > necessary to have correct context saves and restores in drivers we'll need
> > to add another API for AM33xx which basically builds on the IPC mechanism
> > and updates the counters.
> >
> > So, instead of the fallback mechanism that is currently in place, can the
> > implementation for updating the logic/mem counters be converted to make use of
> > function pointers. When AM33xx PM support comes in, we can just define
> > a custom function and not pollute the code with cpu_is_* checks.
>
> I think that should be fine. We can add arch_hwmod struct or such
> (similar to arch_clkdm / arch_pwrdm) if need be. However, I think we
> should just expand the support towards that way once we can implement
> the am33xx support properly with a separate patch. I guess this doesn't
> break anything on am33xx currently, right?
>
It doesn't break anything right now but since we know this doesn't scale
that would be save some additional round of validation on OMAP3/4
later on.
-Vaibhav
��.n��������+%������w��{.n�����{�������ܨ}���Ơz�j:+v�����w����ޙ��&�)ߡ�a����z�ޗ���ݢj��w�f
