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);
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
Regards,
Vikram
--
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
