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 majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
