On Mon, Mar 30, 2015 at 4:59 PM, Stephen Boyd <sboyd@xxxxxxxxxxxxxx> 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 majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
