Message ID | 1492624001-3758-12-git-send-email-ykaneko0929@gmail.com (mailing list archive) |
---|---|
State | Changes Requested, archived |
Headers | show |
Hi > From: Gaku Inami <gaku.inami.xw@bp.renesas.com> > > In the resume process, there is the case that other drivers call > cs2000_enable before cs2000_resume is called. Since the order of > resume process is not guaranteed, it is needed to reset the clk > rate in any cases before cs2000 is used. > > Also, the current cs2000 driver is using resume_early function. > The using .resume_early is bad idea because the dependency with > other drivers is to be complicated. > > This patch adds to reset the clk rate in cs2000_enable and > changes to use from .resume_early to .resume. > > Signed-off-by: Gaku Inami <gaku.inami.xw@bp.renesas.com> > Signed-off-by: Hiroyuki Yokoyama <hiroyuki.yokoyama.vx@renesas.com> > Signed-off-by: Yoshihiro Kaneko <ykaneko0929@gmail.com> > --- Acked-by: Kuninori Morimoto <kuninori.morimoto.gx@renesas.com> -- To unsubscribe from this list: send the line "unsubscribe linux-clk" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
On 04/20, Yoshihiro Kaneko wrote: > From: Gaku Inami <gaku.inami.xw@bp.renesas.com> > > In the resume process, there is the case that other drivers call > cs2000_enable before cs2000_resume is called. Since the order of > resume process is not guaranteed, it is needed to reset the clk > rate in any cases before cs2000 is used. > > Also, the current cs2000 driver is using resume_early function. > The using .resume_early is bad idea because the dependency with > other drivers is to be complicated. > > This patch adds to reset the clk rate in cs2000_enable and > changes to use from .resume_early to .resume. > > Signed-off-by: Gaku Inami <gaku.inami.xw@bp.renesas.com> > Signed-off-by: Hiroyuki Yokoyama <hiroyuki.yokoyama.vx@renesas.com> > Signed-off-by: Yoshihiro Kaneko <ykaneko0929@gmail.com> > --- Was this supposed to be sent as a series? This is the second patch in the series? In what situation does a driver call clk_prepare() on the clocks in here before the device's resume callback is called? I would think that any devices that use the clks provided by this driver would be probe defered until the clks are registered, so they would be later in the suspend/resume list than this clk driver?
Hi Stephen, On Sat, Apr 22, 2017 at 4:10 AM, Stephen Boyd <sboyd@codeaurora.org> wrote: > On 04/20, Yoshihiro Kaneko wrote: >> From: Gaku Inami <gaku.inami.xw@bp.renesas.com> >> >> In the resume process, there is the case that other drivers call >> cs2000_enable before cs2000_resume is called. Since the order of >> resume process is not guaranteed, it is needed to reset the clk >> rate in any cases before cs2000 is used. >> >> Also, the current cs2000 driver is using resume_early function. >> The using .resume_early is bad idea because the dependency with >> other drivers is to be complicated. >> >> This patch adds to reset the clk rate in cs2000_enable and >> changes to use from .resume_early to .resume. >> >> Signed-off-by: Gaku Inami <gaku.inami.xw@bp.renesas.com> >> Signed-off-by: Hiroyuki Yokoyama <hiroyuki.yokoyama.vx@renesas.com> >> Signed-off-by: Yoshihiro Kaneko <ykaneko0929@gmail.com> >> --- > > Was this supposed to be sent as a series? This is the second > patch in the series? > > In what situation does a driver call clk_prepare() on the clocks > in here before the device's resume callback is called? I would > think that any devices that use the clks provided by this driver > would be probe defered until the clks are registered, so they > would be later in the suspend/resume list than this clk driver? Deferred probing is used during driver initialization only. This patch is about clock users calling into the clock API during the resume procedure, before the clock provider has been resumed. Gr{oetje,eeting}s, Geert -- Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org In personal conversations with technical people, I call myself a hacker. But when I'm talking to journalists I just say "programmer" or something like that. -- Linus Torvalds -- To unsubscribe from this list: send the line "unsubscribe linux-clk" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
On 04/23, Geert Uytterhoeven wrote: > Hi Stephen, > > On Sat, Apr 22, 2017 at 4:10 AM, Stephen Boyd <sboyd@codeaurora.org> wrote: > > On 04/20, Yoshihiro Kaneko wrote: > >> From: Gaku Inami <gaku.inami.xw@bp.renesas.com> > >> > >> In the resume process, there is the case that other drivers call > >> cs2000_enable before cs2000_resume is called. Since the order of > >> resume process is not guaranteed, it is needed to reset the clk > >> rate in any cases before cs2000 is used. > >> > >> Also, the current cs2000 driver is using resume_early function. > >> The using .resume_early is bad idea because the dependency with > >> other drivers is to be complicated. > >> > >> This patch adds to reset the clk rate in cs2000_enable and > >> changes to use from .resume_early to .resume. > >> > >> Signed-off-by: Gaku Inami <gaku.inami.xw@bp.renesas.com> > >> Signed-off-by: Hiroyuki Yokoyama <hiroyuki.yokoyama.vx@renesas.com> > >> Signed-off-by: Yoshihiro Kaneko <ykaneko0929@gmail.com> > >> --- > > > > Was this supposed to be sent as a series? This is the second > > patch in the series? > > > > In what situation does a driver call clk_prepare() on the clocks > > in here before the device's resume callback is called? I would > > think that any devices that use the clks provided by this driver > > would be probe defered until the clks are registered, so they > > would be later in the suspend/resume list than this clk driver? > > Deferred probing is used during driver initialization only. > This patch is about clock users calling into the clock API during the resume > procedure, before the clock provider has been resumed. > Right, and which driver is calling into the clk API in their resume function before the clk provider is resume? Presumably the clk provider had probed "first", or at least was ordered in the dpm_list before the consumer drivers so that this problem wouldn't happen.
diff --git a/drivers/clk/clk-cs2000-cp.c b/drivers/clk/clk-cs2000-cp.c index 5b3516d..de6e8c6 100644 --- a/drivers/clk/clk-cs2000-cp.c +++ b/drivers/clk/clk-cs2000-cp.c @@ -338,6 +338,10 @@ static int cs2000_enable(struct clk_hw *hw) struct cs2000_priv *priv = hw_to_priv(hw); int ret; + ret = cs2000_set_saved_rate(priv); + if (ret < 0) + return ret; + ret = cs2000_enable_dev_config(priv, true); if (ret < 0) return ret; @@ -530,7 +534,7 @@ static int cs2000_resume(struct device *dev) } static const struct dev_pm_ops cs2000_pm_ops = { - .resume_early = cs2000_resume, + .resume = cs2000_resume, }; static struct i2c_driver cs2000_driver = {