Re: [PATCH 00/10 v3] omap3: pm: introduce support for 3630 OPPs

[Kevin Hilman <khilman@deeprootsystems.com>]

Nishanth Menon <nm@ti.com> writes:

> Hi,
> Here is V3 of the patch series.  What changed in V3:
> * Major rewrite of OPP APIs. This includes changes from offline
>   discussions with lots of folks and taking in l-o comments - all
>   patches have changed as a result.
> * rebased to latest lo-pm
>
> V2: http://marc.info/?l=linux-omap&m=125809232732700&w=2
> V1: http://marc.info/?l=linux-omap&m=125800488923479&w=2
>
> NOTE: After a bunch of frustrating efforts, current OPP accessor
> implementation is constrained by two files:
> smartreflex.c and resource34xx.c. I agree that the current opp
> accessor implementation leaves lot to be desired, but the nature of
> struct omap_opp cannot change unless we essentially rewrite the
> implementation of the mentioned files.
>
> Ref: http://elinux.org/OMAP_Power_Management#Future_directions
>
> I propose we could take this in in three stages:
> Stage 1: Introduce this series in as starters if there are no major
>  issues
> Stage 2: We cleanup/replace resource34xx and smartreflex.c
> Stage 3: Go through a second round of optimization/cleanup of opp
>  accessors implementation (this time for good hopefully)

I'm open to this 3-step approach assuming that stage 2 and 3 remain a
priority.  This "stage 1" series will not go upstream.  I will only
push upstream after getting to stage 3. 

After some review and discussion, I can pull Stage 1 into the PM
branch for broader testing and as a base for more people to help on
stage 2 and stage 3.

Review comments on individual patches to follow.

Kevin