[U-Boot] Illegal use of FP ops in clock_ti814x.c

[Matt Porter]

On Tue, Oct 29, 2013 at 08:23:07AM -0400, Tom Rini wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
> 
> On 10/29/2013 06:48 AM, Wolfgang Denk wrote:
> > Dear Måns Rullgård,
> > 
> > In message <yw1x8uxc28y9.fsf at unicorn.mansr.com> you wrote:
> >> 
> >>>> Something like this should be equivalent.  That said, it
> >>>> looks suspiciously like it's meant to simply do a division
> >>>> and round up.  If that is the case, +225 should be +249.  It
> >>>> probably makes no difference for the values actually
> >>>> encountered.
> >>> 
> >>> Umm... this is the part which I do not understand.
> >>> 
> >>> The original code adds 90%; you add 90%, too.  However, to
> >>> round up, one usually adds only 50% ?
> >> 
> >> Adding 50% would round to nearest.  For integer division to round
> >> up, you must add one less than the divisor.
> > 
> > Agreed.  But do we want to round up?  The original code used +90%, 
> > which is something else, too...
> 
> And I imagine it's unlikely the original author of the code is around
> anymore, or recalls exactly why.  I'm pretty sure Matt just lifted the
> code from the vendor tree and since it wasn't throwing warnings didn't
> notice the floating point part.
> 
> >>> Where are these 90% coming from? Are they in any way
> >>> meaningful, or even critical?
> >> 
> >> My guess is that it was someone's approximation of 249 / 250.  I
> >> don't know the hardware, so it's conceivable that it really
> >> should be this way, although it seems unlikely.
> > 
> > Are you able to test such a modificationon actual hardware?
> 
> I suspect Matt can, after Linaro Connect.  I don't have one of these
> platforms handy but I think he still does.

Thankfully Tom reminded me of this because I lost some of the list
traffic due to some local mail issues.

Although not explicitly mentioned in the TRM or any application
notes I can find, the 90% appears to come from jitter compensation for
the delta sigma fractional divider. I see some comments that imply this
in various old vendor kernel tree clock implementations where they are
rounding various pll constants. I can't be 100% sure without some
insight from TI folks. Given that it's working for our known users, I'd
like to preserve that until we get somebody that can shed some light on
that.

As Tom guessed, I low-level cherry-picked a lot of pieces from long-lost
authors in this area. I obviously missed this floating point math in the
cleanup.

I tested this patch on my TI8148 EVM and it works as expected.

Acked-by: Matt Porter <mporter at linaro.org>

-Matt