> > + for (val = 0; val <= 7; val++) {
> > + period1 = div_s64(val * 1000000000, ppb);
> > + period1 -= 8;
> > + period1 >>= 4;
> > + if (period1 < 1)
> > + period1 = 1;
> > + if (period1 > 0xFFFFFFE)
> > + period1 = 0xFFFFFFE;
> > + period2 = period1 + 1;
> > +
> > + temp = div_s64(val * 1000000000, (period1 * 16 + 8));
> > + dif1 = ppb - temp;
> > + if (dif1 < 0)
> > + dif1 = -dif1;
> > +
> > + temp = div_s64(val * 1000000000, (period2 * 16 + 8));
>
> Forgetting the useless val=0 case, this still takes 21 64-bit divisions on
> every
> adjustment. There must be a better way.
>
> @tglx - Do you have a hint for Sudarsana?
Maybe we can improve it a bit by making it even uglier
and save one of the divisions here; But that would still leave a 2-digit
number of divisions. I don't have an alternative algorithm that would
solve that.
I have to say I still don't see the importance of this -
I thought we've previously agree that the 'reasonable' scenario
wouldn't use this more than 16 times a second, so it's clearly
not datapath.
Optimizing stuff is great, but optimizing less critical paths
is partially wasted effort. As such - I don't think this should
be a 'blocking' criteria for the submission.
Having written all of that, If someone raises to the challenge
and can efficiently improve the logic, we'd obviously
be delighted to take whatever solution is given.
Thanks,
Yuval
