>From: Pandita, Vikram
>
>
>Proposals for OPP table handling for OMAP34xx/35xx/36xx/44xx
>
>Thanks to all the community members for taking time for this discussion.
>This will aid upsteaming of 35xx/36xx/44xx in coming future.
>
>Attendees: Kevin Hilman, Paul, Nishant M, Santosh, Madhu, Benoit, Rajendra,
>Benoit, Vikram
>
>Problem Statement:
>       OMAP34xx has certain opp requirements (3420/3430/3440)
>       OMAP35xx reuses the opp's from 34xx
>       OMAP36xx has a totally new set of opps
>       OMAP44xx has a totally new set of opps
>
>Solution:
>       Align on a common approach to take for the Opp table definitions.
>
>Define Separate Tables for each family as follows:
>Step 1: Go with this approach:
>       3420(65nm)              : new arrays [defer for now]
>       3430/35xx(65nm)         : new arrays **
>       3440(65nm)              : new arrays [defer for now]
>       3630(45nm)              : new arrays
>       Omap4(45nm)             : new arrays
>
>       * new arrays = (mpu, dsp, l3)
>       ** Check this valid flag. Kevin can take this base on comments
>               http://marc.info/?l=linux-omap&m=125512448216071&w=2
>               between 3430/35xx, opp's can be managed with a flag and same
>table re-used
>               35xx has requirement for 720Mhz opp
>
>Step 2:
>Kevin suggestion:
>Define accessor APIs get the OPPs
>Check Users of accessor API
>       DVFS
>       constraints
>       sysfs debug
>       Define accessor api's eg:
>               index = get_opp(VDD1_OPP1);
>               num = get_max_opp(VDD1);
>               set_opp(index);

I think we should as well change the naming and use the less confusing naming 
we are using on OMAP3630/4430. 
OPPs are now named using the performance delta from the nominal frequency.
OPP25, OPP50, OPP80, OPP100, OPP120... 

Regards,
Benoit

>Step 3:
>       Paul suggestion:
>       VSEL values in opp table should be in terms of voltage
>       Non TWL IC's need this
>
>Step4:
>       Paul suggestion:
>       VDD1 VDD2 dependencies for different chips
>       Inter-connect load predictor is absent on omap3 and hence VDD1-vdd2
>dependency
>       OMAP4
>               interconnect loading can be measured from registers
>               Multi-cores dependency
>
>Step 5:
>       Paul suggestion:
>       Board files adding OPPs, Modifying OPPs
>       Eg: Pendora passing its own opp



--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Reply via email to