On 09/11/2012 05:59 AM, Prashant Gaikwad wrote: > On Monday 10 September 2012 10:47 PM, Stephen Warren wrote: >> On 09/09/2012 07:17 PM, Shawn Guo wrote: >>> On Fri, Sep 07, 2012 at 10:55:00AM -0600, Stephen Warren wrote: >>>> Yes, that does solve the problem (well, with >>>> s/late_init/late_initcall/). >>>> >>>> As you imply, that change wouldn't help if cpu-tegra.c was built as a >>>> module. >>> I doubt that. Have you confirmed it with testing? When you install >>> module cpu-tegra, the pcie initialization has been done, right? >> Never mind, the code can't be built as a module anyway. >> >> Aside from that, I misinterpreted your test patch, and thought that it >> was moving the Tegra cpufreq driver initialization earlier, but it's >> actually moving it later, and in fact by chance after PCIe >> initialization, which explains why it solves the issue. >> >> I think the root of the problem is that cpufreq is lowering the CPU >> frequency, yet the patch which converted Tegra to the common clock >> framework removed the code that actually changes the CPU clock rate. So, >> cpufreq thinks the CPU is running at e.g. 216MHz, but it's actually >> still running at 1.0GHz, and hence re-calculating the delay loops breaks >> things, since delays aren't as long as the system thinks they are. The >> variability is due to whether lowering the CPU frequency just happens to >> occur before or after the PCIe controller is initialized. >> >> Prashant, are you able to fix the clock driver deficiency within the >> next 2-3 days or so (so I can include the fix in the pull requests I >> send for 3.7, which need to be sent before the end of the week)? Or, do >> we need to disable cpufreq for Tegra because of this? > > Your fix looks good to me except the concern I have mentioned in reply > to that patch. Well, the cpufreq driver will need explicit knowledge of Tega20-vs-Tegra30 anyway, due to e.g. differing CPU clock names, probable different latencies, etc. -- To unsubscribe from this list: send the line "unsubscribe linux-tegra" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
