On Mon, Jan 13, 2014 at 09:57:08AM +0100, Geert Uytterhoeven wrote:

Hi Morimoto-san,

On Wed, Jan 8, 2014 at 11:23 AM, Geert Uytterhoeven
[off-list ref] wrote:

quoted

On Wed, Jan 8, 2014 at 2:08 AM, Kuninori Morimoto
[off-list ref] wrote:

quoted

quoted

+     common->clk = devm_clk_get(&pdev->dev, NULL);
+     if (IS_ERR(common->clk)) {
+             dev_err(&pdev->dev, "cannot get clock\n");
+             return PTR_ERR(common->clk);
+     }
+
+     ret = clk_prepare(common->clk);
+     if (ret < 0) {
+             dev_err(&pdev->dev, "unable to prepare clock\n");
+             return ret;
+     }
+
+     clk_enable(common->clk);
+
      pm_runtime_enable(dev);
      pm_runtime_get_sync(dev);

And this patch seems strange for me.
pm_runtime_xxx() is doing same things.
If it didn't work, wrong place is not driver, clock side ?

That's an interesting observation...

You were right. After applying both of "ARM: shmobile: compile drivers/sh
for CONFIG_ARCH_SHMOBILE_MULTI" and "power: clock_ops.c: fixup clk
prepare/unprepare count" from Ben Dooks the issue went away.

There seems to be some lively discussion around Ben's patch.

So my patch can be dropped.

I have marked this patch as Rejected accordingly.