LKML Archive on lore.kernel.org
help / color / mirror / Atom feed
* [PATCH] clk: zynq: Force CPU_2X clock to be ungated
@ 2015-01-23 23:44 Soren Brinkmann
  2015-01-26  3:22 ` Sören Brinkmann
  0 siblings, 1 reply; 3+ messages in thread
From: Soren Brinkmann @ 2015-01-23 23:44 UTC (permalink / raw)
  To: Michal Simek, Mike Turquette, Stephen Boyd
  Cc: linux-kernel, linux-arm-kernel, Soren Brinkmann

The CPU_2X clock does not have a classical in kernel user, but is,
amongst other things, required for OCM and debug access. Make sure this
clock does not mistakenly disabled during boot up by enabling it in the
platforms clock driver.

Signed-off-by: Soren Brinkmann <soren.brinkmann@xilinx.com>
---
I just noticed this on Linus' latest tip. I can't remember having had issues
connecting the debugger before, but it might be a candidate for stable in case
people report something like that.

	Sören

 drivers/clk/zynq/clkc.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/drivers/clk/zynq/clkc.c b/drivers/clk/zynq/clkc.c
index c363106ed726..f8469315161d 100644
--- a/drivers/clk/zynq/clkc.c
+++ b/drivers/clk/zynq/clkc.c
@@ -346,6 +346,7 @@ static void __init zynq_clk_setup(struct device_node *np)
 	clks[cpu_2x] = clk_register_gate(NULL, clk_output_name[cpu_2x],
 			"cpu_2x_div", CLK_IGNORE_UNUSED, SLCR_ARM_CLK_CTRL,
 			26, 0, &armclk_lock);
+	clk_prepare_enable(clks[cpu_2x]);
 
 	clk = clk_register_fixed_factor(NULL, "cpu_1x_div", "cpu_div", 0, 1,
 			4 + 2 * tmp);
-- 
2.2.2.1.g63c5777


^ permalink raw reply	[flat|nested] 3+ messages in thread

* Re: [PATCH] clk: zynq: Force CPU_2X clock to be ungated
  2015-01-23 23:44 [PATCH] clk: zynq: Force CPU_2X clock to be ungated Soren Brinkmann
@ 2015-01-26  3:22 ` Sören Brinkmann
  2015-01-26 16:29   ` Sören Brinkmann
  0 siblings, 1 reply; 3+ messages in thread
From: Sören Brinkmann @ 2015-01-26  3:22 UTC (permalink / raw)
  To: Michal Simek, Mike Turquette, Stephen Boyd; +Cc: linux-kernel, linux-arm-kernel

On Fri, 2015-01-23 at 03:44PM -0800, Soren Brinkmann wrote:
> The CPU_2X clock does not have a classical in kernel user, but is,
> amongst other things, required for OCM and debug access. Make sure this
> clock does not mistakenly disabled during boot up by enabling it in the
> platforms clock driver.
> 
> Signed-off-by: Soren Brinkmann <soren.brinkmann@xilinx.com>
> ---
> I just noticed this on Linus' latest tip. I can't remember having had issues
> connecting the debugger before, but it might be a candidate for stable in case
> people report something like that.

I bisected this down to commit:

ae43b3289186480f81c78bb63d788a85a3631f47 is the first bad commit
commit ae43b3289186480f81c78bb63d788a85a3631f47
Author: Krzysztof Kozlowski <k.kozlowski@samsung.com>
Date:   Fri Nov 14 09:48:57 2014 +0100

    ARM: 8202/1: dmaengine: pl330: Add runtime Power Management support v12
    
    This patch adds runtime PM support to pl330 DMA engine driver.
    
    The runtime power management for pl330 DMA driver allows gating of AMBA
    clock (PDMA) in FSYS clock domain, when the device is not processing any
    requests. This is necessary to enter low power modes on Exynos SoCs
    (e.g. LPA on Exynos4x12 or W-AFTR on Exynos3250).
    
    Runtime PM resuming of the device may happen in atomic context (during
    call device_issue_pending()) so pm_runtime_irq_safe() is used. This will
    lead only to disabling/enabling of the clock but this is sufficient for
    gating the clock and for reducing energy usage.
    
    Driver uses runtime PM callbacks from amba/bus.c driver only.
    
    Suggested-by: Bartlomiej Zolnierkiewicz <b.zolnierkie@samsung.com>
    Signed-off-by: Krzysztof Kozlowski <k.kozlowski@samsung.com>
    Reviewed-by: Ulf Hansson <ulf.hansson@linaro.org>
    Acked-by: Vinod Koul <vinod.koul@intel.com>
    Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>

:040000 040000 16e0cb02587254ea396e9d913d7997ac63bd3d49 97c1ee366f0790e65df00e85d06b2bcd07aa9f58 M      drivers

which makes sense, since the PL330 clock in Zynq is the mentioned
CPU_2X_CLK. I guess the additional runtime_pm in the driver causes the
clock to be gated which causes the issues for the mentioned other users
of this clock.
Looks like this patch got introduced in the 3.19 merge window. Hence,
stable should be off the table.

	Sören

^ permalink raw reply	[flat|nested] 3+ messages in thread

* Re: [PATCH] clk: zynq: Force CPU_2X clock to be ungated
  2015-01-26  3:22 ` Sören Brinkmann
@ 2015-01-26 16:29   ` Sören Brinkmann
  0 siblings, 0 replies; 3+ messages in thread
From: Sören Brinkmann @ 2015-01-26 16:29 UTC (permalink / raw)
  To: Michal Simek, Mike Turquette, Stephen Boyd; +Cc: linux-kernel, linux-arm-kernel

On Sun, 2015-01-25 at 07:22PM -0800, Sören Brinkmann wrote:
> On Fri, 2015-01-23 at 03:44PM -0800, Soren Brinkmann wrote:
> > The CPU_2X clock does not have a classical in kernel user, but is,
> > amongst other things, required for OCM and debug access. Make sure this
> > clock does not mistakenly disabled during boot up by enabling it in the
> > platforms clock driver.
> > 
> > Signed-off-by: Soren Brinkmann <soren.brinkmann@xilinx.com>
> > ---
> > I just noticed this on Linus' latest tip. I can't remember having had issues
> > connecting the debugger before, but it might be a candidate for stable in case
> > people report something like that.
> 
> I bisected this down to commit:
> 
> ae43b3289186480f81c78bb63d788a85a3631f47 is the first bad commit
> commit ae43b3289186480f81c78bb63d788a85a3631f47
> Author: Krzysztof Kozlowski <k.kozlowski@samsung.com>
> Date:   Fri Nov 14 09:48:57 2014 +0100
> 
>     ARM: 8202/1: dmaengine: pl330: Add runtime Power Management support v12
>     
>     This patch adds runtime PM support to pl330 DMA engine driver.
>     
>     The runtime power management for pl330 DMA driver allows gating of AMBA
>     clock (PDMA) in FSYS clock domain, when the device is not processing any
>     requests. This is necessary to enter low power modes on Exynos SoCs
>     (e.g. LPA on Exynos4x12 or W-AFTR on Exynos3250).
>     
>     Runtime PM resuming of the device may happen in atomic context (during
>     call device_issue_pending()) so pm_runtime_irq_safe() is used. This will
>     lead only to disabling/enabling of the clock but this is sufficient for
>     gating the clock and for reducing energy usage.
>     
>     Driver uses runtime PM callbacks from amba/bus.c driver only.
>     
>     Suggested-by: Bartlomiej Zolnierkiewicz <b.zolnierkie@samsung.com>
>     Signed-off-by: Krzysztof Kozlowski <k.kozlowski@samsung.com>
>     Reviewed-by: Ulf Hansson <ulf.hansson@linaro.org>
>     Acked-by: Vinod Koul <vinod.koul@intel.com>
>     Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
> 
> :040000 040000 16e0cb02587254ea396e9d913d7997ac63bd3d49 97c1ee366f0790e65df00e85d06b2bcd07aa9f58 M      drivers
> 
> which makes sense, since the PL330 clock in Zynq is the mentioned
> CPU_2X_CLK. I guess the additional runtime_pm in the driver causes the
> clock to be gated which causes the issues for the mentioned other users
> of this clock.
> Looks like this patch got introduced in the 3.19 merge window. Hence,
> stable should be off the table.

That statement may have been a little premature. Turns out, it actually
is the PL330 driver that is responsible for activating the CPU2X clock
on Zynq. Things work as expected when that driver is in the kernel, but
break as seen on 3.19 when that driver is not part of the kernel. Hence,
this should probably go into stable, all the way back to when we merged
Zynq's CCF code, which seems to have happened in 3.11.

	Soren

^ permalink raw reply	[flat|nested] 3+ messages in thread

end of thread, other threads:[~2015-01-26 16:29 UTC | newest]

Thread overview: 3+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2015-01-23 23:44 [PATCH] clk: zynq: Force CPU_2X clock to be ungated Soren Brinkmann
2015-01-26  3:22 ` Sören Brinkmann
2015-01-26 16:29   ` Sören Brinkmann

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).