[lkml]   [2011]   [Dec]   [2]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
SubjectRe: [PATCH 0/2 v2] ARM: OMAP1: Fix dpll1 reprogramming related issues
On Friday 02 of December 2011 at 03:09:37, Tony Lindgren wrote:
> * Janusz Krzysztofik <> [111201 11:38]:
> > After dpll1 reprogramming has been moved from setup_arch() to
> > kernel_init(), I've been observing several issues, resulting in
> > undesired system behaviour on my Amstrad Delta. This series fixes
> > those most important (2/5 and 5/5 v2 previously), with a "stuck at 60MHz
> > rate" issue going to be fixed with Tony's proposed solution instead of
> > my previous 3/5.
> >
> > Janusz Krzysztofik (2):
> > ARM: OMAP1: Fix ckctl value used for dpll1 defualt rate
> > ARM: OMAP1: recalculate loops per jiffy after dpll1 reprogram
> >
> > arch/arm/mach-omap1/clock_data.c | 9 +++++++--
> > 1 files changed, 7 insertions(+), 2 deletions(-)
> Thanks, got these three patches now applied into fixes on top of -rc4.
> Can you please try it out to make sure it's all working for you now?

Yes, it works as expected, re-tested with a custom 150 MHz rate only
.config to the extent possible without removing all rates form .config
/ omap1_rate_table[], i.e., without triggering the issue addressed by
fc92dd3a77bfc59822f869627ba81a6418eed987 "ARM: OMAP1: Fix ckctl value
used for dpll1 defualt rate". Can re-test other cases (omap1_defconfig,
no rates selected at all) if required.

My only concern left, which I don't feel capable to justify myself, is
if 6% inaccuracy in BogoMIPS recalculation, compared to the BogoMIPS
value got either with 3.1 or as a result of recalibration, does matter
and should still be addressed somehow for next merge window, or can be

Russell, can you please share your opinion?


 \ /
  Last update: 2011-12-02 18:07    [W:0.067 / U:2.476 seconds]
©2003-2018 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site