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? -- To unsubscribe from this list: send the line "unsubscribe cpufreq" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
