Re: [PATCH v5 0/8] ARM: OMAP2+: PM: introduce the power domains functional states - Pihet-XID, Jean

From: "Pihet-XID, Jean" <j-pihet@ti.com>
To: t-kristo@ti.com, Paul Walmsley <paul@pwsan.com>
Cc: khilman@ti.com, Nishanth Menon <nm@ti.com>,
	Rajendra Nayak <rnayak@ti.com>,
	Jean Pihet <jean.pihet@newoldbits.com>,
	"Shilimkar, Santosh" <santosh.shilimkar@ti.com>,
	linux-omap@vger.kernel.org, linux-arm-kernel@lists.infradead.org
Subject: Re: [PATCH v5 0/8] ARM: OMAP2+: PM: introduce the power domains functional states
Date: Tue, 11 Sep 2012 09:50:04 +0200	[thread overview]
Message-ID: <CAN5iSWp4WhfhLd6K=qfyjvZOhp6K3hhOFJjey_0+00KZTa-+pQ@mail.gmail.com> (raw)
In-Reply-To: <1347289778.10702.128.camel@sokoban>

Hi Tero, Paul,

After discussion with Paul at LPC I produced a new version that we are
now internally reviewing.

Paul, what is your plan?

Regards,
Jean

On Mon, Sep 10, 2012 at 5:09 PM, Tero Kristo <t-kristo@ti.com> wrote:
> 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
>