RE: Discussion: OMAP: PM: opp table handling
> From: linux-omap-ow...@vger.kernel.org [mailto:linux-omap- > ow...@vger.kernel.org] On Behalf Of Menon, Nishanth > Sent: Wednesday, October 14, 2009 11:12 AM > > 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... > NAK for two reasons: I wouldn't NAK too quickly. What does the load predictor use? Does it want to know about a million combinations? Not really. It is interesting to see if I'm on a 3GHz machine vs. a 1GHz one. But the predictor shouldn't care. What the predictor may care about is percentages and possible spacing between performance points. A well written user space program hopefully doesn't care in general either. I can recall the days when old apple games were ported and they were unusable for a bit because of all kinds of hardcoded timing loops. They were certainly not portable. Some drivers may practically care about frequency if they need to calculate some kind of QOS parameter but that is not the MPU. I do agree the hardware definition does at times change based on characterization data. We know that not every new OPP is even generally useful if its spacing is bad. A typical system might skip over some OPPs in actual use if spacing is not good. > a) h/w changes language of OPP definitions every other silicons -> OPP100 is > not more informative than OPP1 or OPPX for that matter - with proper comments, > even something like > /* OPP25 - 25% of nominal performance */ > #define VDD1_OPP_RELLLY_SLOW_OPP 1 > Makes sense. > b) if you look at discussion - we really DON'T want to use OPP definitions > anymore - we would like folks to use frequency for precisely that reason - it > is frequency that matters in the system. > c) the field for OPP idx is probably redundant once we have proper APIs in > place. At the lower level I do practically like some use of validated sets. Validation of every possible combination doesn't happen. There are 10 ways to program your DPLL for a similar output range. We should stick with what has been validated not create very big generalized functions. This functions get complex and many times miss out on obscure DPLL errata. At the high level use of percentage might be ideal then comes frequency. These values then are translated into discrete units which can be well tested. I'm not say ack or nak. Just that its not such a black & white choice. Regards, Richard W. -- 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
RE: Discussion: OMAP: PM: opp table handling
>-Original Message- >From: Menon, Nishanth > >> -Original Message- >> From: Cousson, Benoit >> Sent: Wednesday, October 14, 2009 11:06 AM >> To: Pandita, Vikram; linux-omap@vger.kernel.org >> >> >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... >NAK for two reasons: >a) h/w changes language of OPP definitions every other silicons -> OPP100 >is not more informative than OPP1 or OPPX for that matter - with proper >comments, even something like >/* OPP25 - 25% of nominal performance */ >#define VDD1_OPP_RELLLY_SLOW_OPP 1 >Makes sense. Well, this is your point of view, but having a define named OPP100 is a little bit more informative, for my point of view, than OPP3 especially when the same OPP was named OPP1 in previous ES. Nevermind, it was just a quick and non intrusive fix to do but the next point will make it useless. >b) if you look at discussion - we really DON'T want to use OPP definitions >anymore - we would like folks to use frequency for precisely that reason - >it is frequency that matters in the system. I agree it is even better. FYI, and if you look at the discussion, that direction is not obvious at all... There is even a get_opp(VDD1_OPP1) in the email... What part of the email is explaining that? Maybe I missed it. >c) the field for OPP idx is probably redundant once we have proper APIs in >place. Agree. 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 >> >> > > >Regards, >Nishanth Menon -- 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
RE: Discussion: OMAP: PM: opp table handling
> -Original Message- > From: Cousson, Benoit > Sent: Wednesday, October 14, 2009 11:06 AM > To: Pandita, Vikram; linux-omap@vger.kernel.org > > >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... NAK for two reasons: a) h/w changes language of OPP definitions every other silicons -> OPP100 is not more informative than OPP1 or OPPX for that matter - with proper comments, even something like /* OPP25 - 25% of nominal performance */ #define VDD1_OPP_RELLLY_SLOW_OPP 1 Makes sense. b) if you look at discussion - we really DON'T want to use OPP definitions anymore - we would like folks to use frequency for precisely that reason - it is frequency that matters in the system. c) the field for OPP idx is probably redundant once we have proper APIs in place. > > 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 > > Regards, Nishanth Menon -- 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
RE: Discussion: OMAP: PM: opp table handling
>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
RE: Discussion: OMAP: PM: opp table handling
> -Original Message- > From: Pandita, Vikram > Sent: Wednesday, October 14, 2009 1:53 AM > To: linux-omap@vger.kernel.org > 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 majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
