[PATCH v5 0/8] ARM: OMAP2+: PM: introduce the power domains functional states

[t-kristo@ti.com (Tero Kristo)]

On Thu, 2012-08-16 at 11:20 +0530, Shilimkar, Santosh wrote:
> Paul,
> 
> On Thu, Aug 16, 2012 at 6:18 AM, Paul Walmsley <paul@pwsan.com> wrote:
> >
> > Hi Santosh,
> >
> > On Wed, 15 Aug 2012, Shilimkar, Santosh wrote:
> >
> > > On Wed, Aug 15, 2012 at 3:32 PM, Jean Pihet <jean.pihet@newoldbits.com>
> > > wrote:
> > >
> > > I didn't find any mention here about why are we going in this path and
> > > not
> > > in the direction proposed in another RFC [1]
> > > I have already given my comments[2] against the introduction of another
> > > PD
> > > layer which can be avoided easily as demonstrated by the RFC[1]. The
> > > comments
> > > are still applicable for this series too.
> > >
> > > We really need to reduce OMAP specific framework overhead and
> > > move towards more generic PM frameworks. For me, this series is
> > > a step back-ward from that direction. Am really sorry for being critical
> > > again but I remain unconvinced about this series and the problem it
> > > is trying to solve.
> > >
> > > May be you have valid reasons not to follow the approach in [1] and in
> > > that case, it will be good to clarify that so that some of us get
> > > to know your rationale.
> >
> > I've asked Jean to handle the work of evaluating and/or integrating any
> > feedback from you and Rajendra into this series.  Jean, has this latest
> > series fully considered those issues?  Or are there still some areas of
> > misalignment / lack of clarity?
> >
> Thanks for the information. The main objection to this series was to
> not add un-necessary glue layer which still remains.
> 
> From our discussion in past on and off list, your main intention for such
> a series was -
> 
> 1. Need a way to support OSWR.
> - OSWR by definition is a RET with configurable logic and memory states.
> Its a true power state from PD point of view and its not a logical state.
> Now since we have agreed to make the OSWR as a static definition
> (in all products so far OSWR is used as a static definition with logic
> lost, memory retained kind of configuration.)
> 
> - The above requirement can be easily fixed by adding the OSWR
> as an additional basic power state as demonstrated in RFC.
> 
> - There is no need to add another glue layer for above.
> 
> 2. Locking so that the low level APIs don't race and henec abstracting the
> exported API to 1 or 2 and making rest as private functions.
> 
> -- Even before this series, except low level PM code, only one
> common API was used to set the PD low power state.
> int omap_set_pwrdm_state(struct powerdomain *pwrdm, u32 pwrst)
> 
> -- Once we make OSWR as basic power state, we also avoid usage of
> pwrdm_set_logic_retst() API.
> 
> -- We implement lock at this API and export only above API +
> may be omap_get_pwrdm_state() kind of API based on need.
> 
> -- This solves the second requirement too.
> 
> Even if we have more requirement, they can be addressed
> too without need of another layer.
> 
> If you look at the diffstat alone between two approaches, it is
> evident how small piece of code is needed to support above.
> Am not too much into the lines of code but basic objection we
> have is not to add another glue layer.
> 
> Thinking bit loud, for the logical layer for power domain
> we should move towards common device power domain
> APIs and if needed add/enhance them to support OMAP.
>    drivers/base/power/domain.c
> May be this though is bit premature but the intetion is
> to move towards generic linux framework.
> 
> > Anyway.  If there's a problem with this process, it sounds like you,
> > Rajendra, Jean, Beno?t and I should schedule some time to talk over the
> > same issues that you discussed with me on the phone.  Perhaps next week?
> >
> We can surely do a call if needed. But the comments given so far and the
> RFC makes things more or less clear the contention point against the
> $subject series.

What is the latest status with this set? This is kind of blocking the
omap4 core retention feature also as I am supposed to put the patches on
top of this set. Do we have a consensus which way this set should
evolve?

Or, should I just base the core retention patches on top of baseline and
forget about the functional power states for now?

-Tero