On 04/23, Geert Uytterhoeven wrote: > Hi Stephen, > > On Sat, Apr 22, 2017 at 4:10 AM, Stephen Boyd <sb...@codeaurora.org> wrote: > > On 04/20, Yoshihiro Kaneko wrote: > >> From: Gaku Inami <gaku.inami...@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...@bp.renesas.com> > >> Signed-off-by: Hiroyuki Yokoyama <hiroyuki.yokoyama...@renesas.com> > >> Signed-off-by: Yoshihiro Kaneko <ykaneko0...@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. -- Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, a Linux Foundation Collaborative Project
