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-omapm=125512448216071w=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: 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-omapm=125512448216071w=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
-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-omapm=125512448216071w=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
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
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 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-omapm=125512448216071w=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
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-omapm=125512448216071w=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
