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@xxxxxxxxx> wrote: > > > > Hi Santosh, > > > > On Wed, 15 Aug 2012, Shilimkar, Santosh wrote: > > > > > On Wed, Aug 15, 2012 at 3:32 PM, Jean Pihet <jean.pihet@xxxxxxxxxxxxxx> > > > 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 -- 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
