> -----Original Message----- > From: Pandita, Vikram > Sent: Wednesday, October 14, 2009 1:53 AM > To: linux-omap@xxxxxxxxxxxxxxx > Cc: Kevin Hilman; Menon, Nishanth; Nataraju, Kiran; Premi, > Sanjeev; Shilimkar, Santosh; Chikkature Rajashekar, > Madhusudhan; Tony Lindgren; Sawant, Anand; Joshi, Rhishi; > Giles, Rick; Sripathy, Vishwanath; Paul Walmsley; Cousson, > Benoit; Nayak, Rajendra > Subject: Discussion: OMAP: PM: opp table handling > > > 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 [sp] Adding myself to attendees ~sanjeev > > 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
