[PATCH] gpio: zynq: initialize clock even without CONFIG_PM

[PATCH] gpio: zynq: initialize clock even without CONFIG_PM

[Helmut Grohne]

When the PM initialization was moved in the commit referenced below, the
code enabling the clock was removed from the probe function. On
CONFIG_PM=y kernels, this is not a problem as the pm resume hook enables
the clock, but when power management is disabled, all those pm_*
functions are noops and the clock is never enabled resulting in a
dysfunctional gpio controller.

Put the clock initialization back to support CONFIG_PM=n.

Signed-off-by: Helmut Grohne <h.grohne@intenta.de>
Fixes: 3773c195d387 ("gpio: zynq: Do PM initialization earlier to support gpio hogs")
---
 drivers/gpio/gpio-zynq.c | 10 +++++++++-
 1 file changed, 9 insertions(+), 1 deletion(-)

I verified that after this patch both CONFIG_PM=y and CONFIG_PM=n
configurations work.

Should this patch be copied to stable@vger.kernel.org? It seems that
CONFIG_PM=n is not a commonly used configuration anymore.

Please Cc me in any replies.

Helmut

diff --git a/drivers/gpio/gpio-zynq.c b/drivers/gpio/gpio-zynq.c
index e29cf58..3cbe63c 100644
--- a/drivers/gpio/gpio-zynq.c
+++ b/drivers/gpio/gpio-zynq.c
@@ -714,11 +714,17 @@ static int zynq_gpio_probe(struct platform_device *pdev)
 		dev_err(&pdev->dev, "input clock not found.\n");
 		return PTR_ERR(gpio->clk);
 	}
+	ret = clk_prepare_enable(gpio->clk);
+	if (ret) {
+		dev_err(&pdev->dev, "Unable to enable clock.\n");
+		return ret;
+	}
 
+	pm_runtime_set_active(&pdev->dev);
 	pm_runtime_enable(&pdev->dev);
 	ret = pm_runtime_get_sync(&pdev->dev);
 	if (ret < 0)
-		return ret;
+		goto err_disable_unprepare_clk;
 
 	/* report a bug if gpio chip registration fails */
 	ret = gpiochip_add(chip);
@@ -750,6 +756,8 @@ err_rm_gpiochip:
 	gpiochip_remove(chip);
 err_pm_put:
 	pm_runtime_put(&pdev->dev);
+err_disable_unprepare_clk:
+	clk_disable_unprepare(gpio->clk);
 
 	return ret;
 }
-- 
2.1.4

Re: [PATCH] gpio: zynq: initialize clock even without CONFIG_PM

[Linus Walleij]

On Wed, Jun 1, 2016 at 1:03 PM, Helmut Grohne <h.grohne@intenta.de> wrote:

> When the PM initialization was moved in the commit referenced below, the
> code enabling the clock was removed from the probe function. On
> CONFIG_PM=y kernels, this is not a problem as the pm resume hook enables
> the clock, but when power management is disabled, all those pm_*
> functions are noops and the clock is never enabled resulting in a
> dysfunctional gpio controller.
>
> Put the clock initialization back to support CONFIG_PM=n.
>
> Signed-off-by: Helmut Grohne <h.grohne@intenta.de>
> Fixes: 3773c195d387 ("gpio: zynq: Do PM initialization earlier to support gpio hogs")

This does not apply to my kernel tree, can you rebase it on
v4.7-rc1?

Sould it be tagged for stable and sent to fixes?

Yours,
Linus Walleij

Re: [PATCH] gpio: zynq: initialize clock even without CONFIG_PM

[Helmut Buchsbaum]

On 06/02/2016 02:30 PM, Linus Walleij wrote:
> On Wed, Jun 1, 2016 at 1:03 PM, Helmut Grohne <h.grohne@intenta.de> wrote:
>
>> When the PM initialization was moved in the commit referenced below, the
>> code enabling the clock was removed from the probe function. On
>> CONFIG_PM=y kernels, this is not a problem as the pm resume hook enables
>> the clock, but when power management is disabled, all those pm_*
>> functions are noops and the clock is never enabled resulting in a
>> dysfunctional gpio controller.
>>
>> Put the clock initialization back to support CONFIG_PM=n.
>>
>> Signed-off-by: Helmut Grohne <h.grohne@intenta.de>
>> Fixes: 3773c195d387 ("gpio: zynq: Do PM initialization earlier to support gpio hogs")
>
> This does not apply to my kernel tree, can you rebase it on
> v4.7-rc1?
>
> Sould it be tagged for stable and sent to fixes?
>
> Yours,
> Linus Walleij
> --
> To unsubscribe from this list: send the line "unsubscribe linux-gpio" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
>

I just ran into that problem when using v4.7-rc1 for our Zynq-7015 based 
custom board running without CONFIG_PM. It relies on MIO based GPIO for 
hardware identification, which immediately ceased to work.

Rebasing Helmut's patch for v4.7-rc1 fixes this issue, so I can confirm 
it works!

Regards,
Helmut Buchsbaum