  `Quoting Tejas Patel (2018-05-03 02:25:35)> divider_get_val() is used to find clock divisor which is> giving round up value. So even though actual divisor is closer to> round down integer value it will return round up integer value.> This can result into large variation between expected clock rate and> actual clock rate.> > See for example:> Parent rate is 1400MHz and desired child rate is 693MHz.> So if we calculate simple divisor for child clock it would be> 1400000000/693000000 = 2.02. But, because of roundup logic> (DIV_ROUND_UP_ULL(1400000000, 693000000)) divisor returned from> divider_get_val() will be 3.> > So actual child rate would be (1400000000/3) = 466666667 instead of> 693000000. Here, difference between expected child rate and actual child> rate is approx 226MHz. So there is almost 32% error between desired and> actual clock rate.> > Fix this by using round off value (DIV_ROUND_CLOSEST_ULL) instead of> round up/down.Is your divider using the CLK_DIVIDER_ROUND_CLOSEST flag? Whendivider_get_val() is called, the incoming rate should already be roundedto something that is what the actual frequency would be so the roundinghere hopefully doesn't matter.Maybe something is lost in translation though, because we doround_rate() to figure out some divider based on a requested rate, andthen we return that rate we calculated that we can achieve to theframework. In turn, that rate comes back into this divider_get_val()function to get the divider out of the rate again. It's sort of annoyinghow circular this is. Perhaps your example can show this call sequenceand the associated math gymnastics that go on and then I'll be convincedthat we need to update this part of the code.`   