ARM: OMAP2+: PM: introduce the power domains functional states
Get series with b4
b4 am CAMQu2gyV6gX=KFjMZ1r_BwsJXmgjuLMAWHrrLCYLgKEBRne0Ow@mail.gmail.comVersions newest first · linked by author and title
- v5 Latest posting 2/20 of 8 patches 0 repliesNew
- v5 posting 1/20 of 8 patches 0 repliesSuperseded
- v13 of 6 patches 0 repliesSuperseded
Patches in v5 posting 2/2 No applies recorded yet
None of the 8 patches the cover letter announces are in this archive.
Reviews trailers per patch
No Reviewed-by, Acked-by or Tested-by trailers for v5 yet.
Cover letter [PATCH v5 0/8] ARM: OMAP2+: PM: introduce the power domains functional states
Paul,
Quoted 23 lines · Paul Walmsley
Hi Santosh,
Quoted 18 lines · Santosh
On Wed, Aug 15, 2012 at 3:32 PM, Jean Pihet <[email protected]> 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.
Quoted 9 lines
Quoted 3 lines
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.
Quoted 1 line
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.
Quoted 4 lines
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.
Regards
Santosh