On Thu, Aug 8, 2013 at 9:37 AM, Viresh Kumar <viresh.kumar@xxxxxxxxxx> wrote: > On 8 August 2013 19:52, Lucas Stach <l.stach@xxxxxxxxxxxxxx> wrote: >> You can certainly define the mapping table in DT where a specialized >> Tegra cpufreq driver could read it in and then map frequency to voltage. >> But that's a runtime decision, as Speedo and process ID are fuse values >> and can not be represented in DT. > >> The problem with this is that the hardware description now associates >> voltages with certain frequencies and even if they are not used by the >> Linux driver they are plain wrong. > > Hmm. I understand. > Then we probably need mach-tegra/opp.c to call opp_add() for all such > OPPs.. Neither DT nor cpufreq driver are the right place for this. This is similar to what I suspected might be the case on other platforms (in addition to known iMx and OMAP). Could you see/comment on [1] to see if it meets your needs. We should like to avoid dealing custom SoC specific OPP, if we are able to generalize the need. ofcourse, I am yet to submit a official proposal, but more SoCs the current proposal can handle, the better it will be for all of us. [1] http://marc.info/?l=linux-pm&m=137589225305971&w=2 -- Regards, Nishanth Menon -- To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
