On Mon, Mar 30, 2015 at 4:59 PM, Stephen Boyd <[email protected]> wrote: > On 02/24/15 19:56, Andrew Bresticker wrote: >> + >> +void pistachio_clk_force_enable(struct pistachio_clk_provider *p, >> + unsigned int *clk_ids, unsigned int num) >> +{ >> + unsigned int i; >> + int err; >> + >> + for (i = 0; i < num; i++) { >> + struct clk *clk = p->clk_data.clks[clk_ids[i]]; >> + >> + if (IS_ERR(clk)) >> + continue; >> + >> + err = clk_prepare_enable(clk); >> + if (err) >> + pr_err("Failed to enable clock %s: %d\n", >> + __clk_get_name(clk), err); >> + } >> +} >> > > Is this to workaround some problems in the framework where clocks are > turned off? Or is it that these clocks are already on before we boot > Linux and we need to make sure the framework knows that?
It's the former. These clocks are enabled at POR and may only be gated as the final step to entering suspend, so they must remain on at runtime. The issue we were running into was that consumers of these critical clocks or their descendants would enable/disable their clocks during boot or runtime PM and cause these clocks to get disabled. Bumping up the prepare/enable count of these critical clocks seemed like the best way to handle this - is there a more preferred way? FWIW, this is also how the Tegra and Rockchip drivers handled this problem. -- To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to [email protected] More majordomo info at http://vger.kernel.org/majordomo-info.html
