Quoting Tomi Valkeinen (2014-03-17 05:53:03)
> On 27/02/14 04:25, Mike Turquette wrote:
> > Quoting Tero Kristo (2014-02-14 05:45:22)
> >> On 02/13/2014 12:03 PM, Tomi Valkeinen wrote:
> >>> clk-divider.c does not calculate the rates consistently at the moment.
> >>>
> >>> As an example, on OMAP3 w
On 27/02/14 04:25, Mike Turquette wrote:
> Quoting Tero Kristo (2014-02-14 05:45:22)
>> On 02/13/2014 12:03 PM, Tomi Valkeinen wrote:
>>> clk-divider.c does not calculate the rates consistently at the moment.
>>>
>>> As an example, on OMAP3 we have a clock divider with a source clock of
>>> 864
On 27/02/14 04:25, Mike Turquette wrote:
>> Basically the patch looks good to me, but it might be good to have a
>> testing round of sort with this. It can potentially cause regressions on
>> multiple boards if the drivers happen to rely on the "broken" clock
>> rates. Same for patch #2 which i
Quoting Tero Kristo (2014-02-14 05:45:22)
> On 02/13/2014 12:03 PM, Tomi Valkeinen wrote:
> > clk-divider.c does not calculate the rates consistently at the moment.
> >
> > As an example, on OMAP3 we have a clock divider with a source clock of
> > 86400 Hz. With dividers 6, 7 and 8 the theoreti
On 02/13/2014 12:03 PM, Tomi Valkeinen wrote:
clk-divider.c does not calculate the rates consistently at the moment.
As an example, on OMAP3 we have a clock divider with a source clock of
86400 Hz. With dividers 6, 7 and 8 the theoretical rates are:
6: 14400
7: 123428571.428571...
8: 10
clk-divider.c does not calculate the rates consistently at the moment.
As an example, on OMAP3 we have a clock divider with a source clock of
86400 Hz. With dividers 6, 7 and 8 the theoretical rates are:
6: 14400
7: 123428571.428571...
8: 10800
Calling clk_round_rate() with the rate
