Hi
On Mon, 2 Jul 2012, Rajendra Nayak wrote:
> As part of Common Clk Framework (CCF) the clk_enable() operation
> was split into a clk_prepare() which could sleep, and a clk_enable()
> which should never sleep. Similarly the clk_disable() was
> split into clk_disable() and clk_unprepare(). This was
> needed to handle complex cases where in a clk gate/ungate
> would require a slow and a fast part to be implemented.
> None of the clocks below seem to be in the 'complex' clocks
> category and are just simple clocks which are enabled/disabled
> through simple register writes.
> Most of the instances also seem to be called in non-atomic
> context which means its safe to move all of those from
> using a clk_enable() to clk_prepare_enable() and clk_disable() to
> clk_disable_unprepare().
> For a few others where there is a possibility they get called from
> an interrupt or atomic context, there is an additonal clk_prepare()
> done before a clk_enable() and a clk_unprepare()
> after a clk_disable().
> This is in preparation of OMAP moving to CCF.
>
> Based on initial changes from Mike turquette.
>
> Signed-off-by: Rajendra Nayak <rnayak@xxxxxx>
Looking at this one, it seems basically okay except for this part:
> diff --git a/arch/arm/mach-omap2/omap_hwmod.c b/arch/arm/mach-omap2/omap_hwmod.c
> index 7731936..f904993 100644
> --- a/arch/arm/mach-omap2/omap_hwmod.c
> +++ b/arch/arm/mach-omap2/omap_hwmod.c
> @@ -608,6 +608,7 @@ static int _init_main_clk(struct omap_hwmod *oh)
> oh->name, oh->main_clk);
> return -EINVAL;
> }
> + clk_prepare(oh->_clk);
>
> if (!oh->_clk->clkdm)
> pr_warning("omap_hwmod: %s: missing clockdomain for %s.\n",
> @@ -645,6 +646,7 @@ static int _init_interface_clks(struct omap_hwmod *oh)
> ret = -EINVAL;
> }
> os->_clk = c;
> + clk_prepare(os->_clk);
> }
>
> return ret;
> @@ -672,6 +674,7 @@ static int _init_opt_clks(struct omap_hwmod *oh)
> ret = -EINVAL;
> }
> oc->_clk = c;
> + clk_prepare(oc->_clk);
> }
>
> return ret;
Seems to me that the strategy here of calling clk_prepare() right after
the clk_get() is only going to work as long as clk_prepare() is a no-op.
Right now this code is called early in the boot before many subsystems are
available.
So if we make a change like this one, it seems like we would basically
expect it to break once we start doing anything meaningful with
clk_prepare(), like using clk_prepare() for voltage scaling or something
that requires I2C? We'd also probably want to mark this with some kind of
"HACK" comment.
- Paul
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
