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 pr
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 MULT_R
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_ra
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 ca
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. In
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 re
6 matches
Mail list logo
