Hi Paul,
On Fri, Jan 25, 2013 at 17:48:22, Mohammed, Afzal wrote:
On Fri, Jan 25, 2013 at 13:48:11, Paul Walmsley wrote:
like MPU CPUFreq. I'd suggest reverting
241d3a8dca239610d3d991bf58d4fe38c2d86fd5 or using a similar approach.
As you prefer reverting the above commit, I will proceed
Hi Mike,
On Sat, Jan 26, 2013 at 03:50:32, Mike Turquette wrote:
Is MULT_ROUND_UP doing the right thing for you in the clk_divider code?
What is the clock rate requested of the parent PLL? I just want to make
sure that we're doing the right thing in the basic divider code.
Actually
Hi
On Fri, 25 Jan 2013, Mohammed, Afzal wrote:
On Fri, Jan 25, 2013 at 13:48:11, Paul Walmsley wrote:
On Wed, 23 Jan 2013, Afzal Mohammed wrote:
Currently round rate function would return proper rate iff requested
rate exactly matches the PLL lockable rate. This causes set_rate to
Hi
On Wed, 23 Jan 2013, Afzal Mohammed wrote:
Currently round rate function would return proper rate iff requested
rate exactly matches the PLL lockable rate. This causes set_rate to
fail if exact rate could not be set. Instead round rate may return
closest rate possible (less than the
Hi Paul,
On Fri, Jan 25, 2013 at 13:48:11, Paul Walmsley wrote:
On Wed, 23 Jan 2013, Afzal Mohammed wrote:
Currently round rate function would return proper rate iff requested
rate exactly matches the PLL lockable rate. This causes set_rate to
fail if exact rate could not be set. Instead
Quoting Mohammed, Afzal (2013-01-25 04:18:22)
Hi Paul,
On Fri, Jan 25, 2013 at 13:48:11, Paul Walmsley wrote:
On Wed, 23 Jan 2013, Afzal Mohammed wrote:
Currently round rate function would return proper rate iff requested
rate exactly matches the PLL lockable rate. This causes
Currently round rate function would return proper rate iff requested
rate exactly matches the PLL lockable rate. This causes set_rate to
fail if exact rate could not be set. Instead round rate may return
closest rate possible (less than the requested). And if any user is
badly in need of exact
