| Message ID | BANLkTik0TVpfax1Fe8c_6A9SFUNzfDbxyw@mail.gmail.com |
|---|---|
| State | New |
| Headers | show |
Linus, On 6/3/2011 3:31 AM, Linus Walleij wrote: > Hi Russell, > > please consider pulling this for the -rc series since I see this as a > horrible bug that Thomas just fixed the infrastructure to properly > counter the week before the merge window. > > You probably know the story but basically there is one clockline > into the ARM-supplied MPCore thing, and it inevitably also clocks > the TWD. Sadly that includes the localtimer, which will make all > clockevents scale in both directions, firing too late or too early > as compared to desired wall-clock time (or system clocksource) as > the clock speed of the core is changed. Right now there is no > compensation whatsoever for this so to run the system reliably > on v3.0-rc1, cpufreq has to be disabled. > > Thomas and Colin did the grunt work, I added a scaling smp_twd > clock reflecting the Ux500 cpufreq changes, and now it is rock solid > as far as I can tell. > Hope the pull is already not done. If not I would like to submit the OMAP clock change as well along with this series and may be Colin might want to do the same for Tegra. Regards Santosh
On Thu, Jun 2, 2011 at 10:26 PM, Santosh Shilimkar <santosh.shilimkar@ti.com> wrote: > Linus, > > On 6/3/2011 3:31 AM, Linus Walleij wrote: >> >> Hi Russell, >> >> please consider pulling this for the -rc series since I see this as a >> horrible bug that Thomas just fixed the infrastructure to properly >> counter the week before the merge window. >> >> You probably know the story but basically there is one clockline >> into the ARM-supplied MPCore thing, and it inevitably also clocks >> the TWD. Sadly that includes the localtimer, which will make all >> clockevents scale in both directions, firing too late or too early >> as compared to desired wall-clock time (or system clocksource) as >> the clock speed of the core is changed. Right now there is no >> compensation whatsoever for this so to run the system reliably >> on v3.0-rc1, cpufreq has to be disabled. >> >> Thomas and Colin did the grunt work, I added a scaling smp_twd >> clock reflecting the Ux500 cpufreq changes, and now it is rock solid >> as far as I can tell. >> > Hope the pull is already not done. If not I would like to submit the > OMAP clock change as well along with this series and may be Colin might > want to do the same for Tegra. > > Regards > Santosh > > I will submit the Tegra clock change along with a separate series. This change should not change any functionality on platforms where the clock has not been defined, so there is no need to sequence it with clock patches.
On 6/3/2011 11:46 AM, Colin Cross wrote: > On Thu, Jun 2, 2011 at 10:26 PM, Santosh Shilimkar > <santosh.shilimkar@ti.com> wrote: >> Linus, >> [...] > > I will submit the Tegra clock change along with a separate series. > This change should not change any functionality on platforms where the > clock has not been defined, so there is no need to sequence it with > clock patches. Agree. My intention was same bug get fixed on all platforms together in one series. Ofcourse the platform non supporting CPUFreq in mainline shouldn't care too much either. Sorry for noise. Regards Santosh
Hi Russell, please consider pulling this for the -rc series since I see this as a horrible bug that Thomas just fixed the infrastructure to properly counter the week before the merge window. You probably know the story but basically there is one clockline into the ARM-supplied MPCore thing, and it inevitably also clocks the TWD. Sadly that includes the localtimer, which will make all clockevents scale in both directions, firing too late or too early as compared to desired wall-clock time (or system clocksource) as the clock speed of the core is changed. Right now there is no compensation whatsoever for this so to run the system reliably on v3.0-rc1, cpufreq has to be disabled. Thomas and Colin did the grunt work, I added a scaling smp_twd clock reflecting the Ux500 cpufreq changes, and now it is rock solid as far as I can tell. I couldn't test this in next since it messes around in your tree, if you don't think this is -rc material please consider pulling into the devel branch so we get early testing of it in -next as an alternative route to mainline. The following changes since commit 55922c9d1b84b89cb946c777fddccb3247e7df2c: Linux 3.0-rc1 (2011-05-29 17:43:36 -0700) are available in the git repository at: git://git.kernel.org/pub/scm/linux/kernel/git/linusw/linux-stericsson.git twd-clockevents Colin Cross (1): ARM: smp_twd: Reconfigure clockevents after cpufreq change Linus Walleij (1): mach-ux500: register a clock for the SMP TWD arch/arm/kernel/smp_twd.c | 90 ++++++++++++++++++++++++++++++++++++++++--- arch/arm/mach-ux500/clock.c | 48 +++++++++++++++++++++++ 2 files changed, 132 insertions(+), 6 deletions(-)