On Wed, Sep 20, 2017 at 04:45:02AM +0000, Levin, Alexander (Sasha Levin) wrote: > From: Nicholas Mc Guire <[email protected]> > > [ Upstream commit ed784c532a3d0959db488f40a96c5127f63d42dc ] > > The delay here is not in atomic context and does not seem critical with > respect to precision, but usleep_range(min,max) with min==max results in > giving the timer subsystem no room to optimize uncritical delays. Fix > this by setting the range to 2000,3000 us. > > Fixes: commit f05259a6ffa4 ("clk: wm831x: Add initial WM831x clock driver") > Signed-off-by: Nicholas Mc Guire <[email protected]> > Acked-by: Charles Keepax <[email protected]> > Signed-off-by: Stephen Boyd <[email protected]> > Signed-off-by: Sasha Levin <[email protected]> > --- > drivers/clk/clk-wm831x.c | 3 ++- > 1 file changed, 2 insertions(+), 1 deletion(-) > > diff --git a/drivers/clk/clk-wm831x.c b/drivers/clk/clk-wm831x.c > index 763aed2de893..dfedcf5bc429 100644 > --- a/drivers/clk/clk-wm831x.c > +++ b/drivers/clk/clk-wm831x.c > @@ -101,7 +101,8 @@ static int wm831x_fll_prepare(struct clk_hw *hw) > if (ret != 0) > dev_crit(wm831x->dev, "Failed to enable FLL: %d\n", ret); > > - usleep_range(2000, 2000); > + /* wait 2-3 ms for new frequency taking effect */ > + usleep_range(2000, 3000);
Does this patch really make sense for stable, isn't this really just a small optimisation? The patch is pretty harmless so I can't see applying it causing any problems, just curious what problems not having it is causing. Thanks, Charles
