From: Michael Turquette <mturquette-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org>
To: Tomeu Vizoso
<tomeu.vizoso-ZGY8ohtN/8qB+jHODAdFcQ@public.gmane.org>,
Mikko Perttunen <mikko.perttunen-/1wQRMveznE@public.gmane.org>
Cc: Stephen Warren <swarren-3lzwWm7+Weoh9ZMKESR00Q@public.gmane.org>,
Thierry Reding
<thierry.reding-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>,
Alexandre Courbot
<gnurou-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>,
Peter De Schrijver
<pdeschrijver-DDmLM1+adcrQT0dZR+AlfA@public.gmane.org>,
"Rafael J. Wysocki" <rjw-LthD3rsA81gm4RdzfppkhA@public.gmane.org>,
Viresh Kumar
<viresh.kumar-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org>,
pwalmsley-DDmLM1+adcrQT0dZR+AlfA@public.gmane.org,
Vince Hsu <vinceh-DDmLM1+adcrQT0dZR+AlfA@public.gmane.org>,
Prashant Gaikwad
<pgaikwad-DDmLM1+adcrQT0dZR+AlfA@public.gmane.org>,
"linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org"
<linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org>,
"linux-pm-u79uwXL29TY76Z2rM5mHXA@public.gmane.org"
<linux-pm-u79uwXL29TY76Z2rM5mHXA@public.gmane.org>,
"linux-tegra-u79uwXL29TY76Z2rM5mHXA@public.gmane.org"
<linux-tegra-u79uwXL29TY76Z2rM5mHXA@public.gmane.org>,
"linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r@public.gmane.org"
<linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r@public.gmane.org>,
tuomas.tynkkynen-X3B1VOXEql0@public.gmane.org
Subject: Re: [PATCH v8 10/18] clk: tegra: Initialize PLL_X before CCLK_G to ensure it has a parent
Date: Mon, 13 Apr 2015 12:31:08 -0700 [thread overview]
Message-ID: <20150413193108.19585.29183@quantum> (raw)
In-Reply-To: <CAAObsKCHUG7Auwu29My5xfynsQ1Jm6KB0bGxf1e3uUO6dvsBRA-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
Quoting Tomeu Vizoso (2015-04-13 05:17:01)
> On 11 April 2015 at 13:00, Mikko Perttunen <mikko.perttunen-/1wQRMveznE@public.gmane.org> wrote:
> > On 04/11/2015 12:08 AM, Michael Turquette wrote:
> >>
> >> Quoting Mikko Perttunen (2015-03-01 04:44:33)
> >>>
> >>> This patch moves the initialization of PLL_X to be slightly before
> >>> that of CCLK_G. This ensures that at boot, CCLK_G will immediately
> >>> have a parent and the common clock framework can determine its
> >>> clock rate correctly.
> >>>
> >>> Without this patch, calling clk_put on CCLK_G could cause the CCF
> >>> to set its rate to zero, hanging the system.
> >>
> >>
> >> Hi Mikko,
> >>
> >> Patch looks fine to me but I wanted to get more info on the behavior you
> >> mentioned above about clk_put. Is there some special circumstance that
> >> causes this for you? Why does calling clk_put adjust the rate of your
> >> clock?
> >>
> >> Thanks,
> >> Mike
> >
> >
> > Hi Mike,
> >
> > this is the chain of events:
> > - CCLK_G is registered. CCF stores its current rate, but since it doesn't
> > have a parent at this point, the rate is assumed zero.
> > - tegra cpufreq driver tries to probe, and clk_gets CCLK_G
> > - tegra dfll driver tries to probe, but fails
> > - tegra cpufreq driver's probe fails, and during unwinding clk_puts CCLK_G
> > - CCF attempts to restore CCLK_G's rate to what it was prior to the clk_get
> > (to revert possible changes due to clock constraints)
>
> The CCF will currently only do so if any constraints were set in the
> per-user clk that was destroyed, so this particular problem shouldn't
> happen any more: ec02ace clk: Only recalculate the rate if needed
Precisely. clk_put shouldn't be setting rates unless we're releasing a
constraint. Can this re-ordering patch be dropped?
>
> > - the stored rate was zero, so CCLK_G is set to zero.
> >
> > We did discuss it a bit on IRC with Tomeu and Peter and agreed that some fix
> > in CCF should be done, but we didn't get much further than that.
>
> Wonder if we could somehow make sure that the rate in the CCF matches
> the current state of the HW.
If there is no constraint expressed by Linux software then we
should not care.
Probably we need to track a few more things in the framework. Stephen
and I were discussing struct clk.hw_en which tracks the enable/disable
state of the hardware independently of the enable_count (e.g. gate clock
is enabled by bootloader but not enabled by Linux ccf).
Tracking something like "is_clk_initialized" would be helpful. It is an
abstract concept but knowing that clock has been successfully hooked up
to its parent and that its rate has been properly calculated would be
very helpful for some corner cases.
Regards,
Mike
>
> Regards,
>
> Tomeu
>
> > Mikko
> >
> >
> >>
> >>>
> >>> Signed-off-by: Mikko Perttunen <mikko.perttunen-/1wQRMveznE@public.gmane.org>
> >>> ---
> >>> v8:
> >>> - Added
> >>>
> >>> drivers/clk/tegra/clk-tegra-super-gen4.c | 46
> >>> ++++++++++++++++++--------------
> >>> 1 file changed, 26 insertions(+), 20 deletions(-)
> >>>
> >>> diff --git a/drivers/clk/tegra/clk-tegra-super-gen4.c
> >>> b/drivers/clk/tegra/clk-tegra-super-gen4.c
> >>> index f1f4410..c5ea9ee 100644
> >>> --- a/drivers/clk/tegra/clk-tegra-super-gen4.c
> >>> +++ b/drivers/clk/tegra/clk-tegra-super-gen4.c
> >>> @@ -104,6 +104,32 @@ void __init tegra_super_clk_gen4_init(void __iomem
> >>> *clk_base,
> >>> struct clk *clk;
> >>> struct clk **dt_clk;
> >>>
> >>> + /*
> >>> + * Register PLL_X first so that CCLK_G has a parent at
> >>> registration
> >>> + * time. This ensures that the common clock framework knows
> >>> CCLK_G's
> >>> + * rate.
> >>> + */
> >>> +
> >>> +#if defined(CONFIG_ARCH_TEGRA_114_SOC) ||
> >>> defined(CONFIG_ARCH_TEGRA_124_SOC)
> >>> + /* PLLX */
> >>> + dt_clk = tegra_lookup_dt_id(tegra_clk_pll_x, tegra_clks);
> >>> + if (!dt_clk)
> >>> + return;
> >>> +
> >>> + clk = tegra_clk_register_pllxc("pll_x", "pll_ref", clk_base,
> >>> + pmc_base, CLK_IGNORE_UNUSED, params, NULL);
> >>> + *dt_clk = clk;
> >>> +
> >>> + /* PLLX_OUT0 */
> >>> +
> >>> + dt_clk = tegra_lookup_dt_id(tegra_clk_pll_x_out0, tegra_clks);
> >>> + if (!dt_clk)
> >>> + return;
> >>> + clk = clk_register_fixed_factor(NULL, "pll_x_out0", "pll_x",
> >>> + CLK_SET_RATE_PARENT, 1, 2);
> >>> + *dt_clk = clk;
> >>> +#endif
> >>> +
> >>> /* CCLKG */
> >>> dt_clk = tegra_lookup_dt_id(tegra_clk_cclk_g, tegra_clks);
> >>> if (dt_clk) {
> >>> @@ -127,25 +153,5 @@ void __init tegra_super_clk_gen4_init(void __iomem
> >>> *clk_base,
> >>> }
> >>>
> >>> tegra_sclk_init(clk_base, tegra_clks);
> >>> -
> >>> -#if defined(CONFIG_ARCH_TEGRA_114_SOC) ||
> >>> defined(CONFIG_ARCH_TEGRA_124_SOC)
> >>> - /* PLLX */
> >>> - dt_clk = tegra_lookup_dt_id(tegra_clk_pll_x, tegra_clks);
> >>> - if (!dt_clk)
> >>> - return;
> >>> -
> >>> - clk = tegra_clk_register_pllxc("pll_x", "pll_ref", clk_base,
> >>> - pmc_base, CLK_IGNORE_UNUSED, params, NULL);
> >>> - *dt_clk = clk;
> >>> -
> >>> - /* PLLX_OUT0 */
> >>> -
> >>> - dt_clk = tegra_lookup_dt_id(tegra_clk_pll_x_out0, tegra_clks);
> >>> - if (!dt_clk)
> >>> - return;
> >>> - clk = clk_register_fixed_factor(NULL, "pll_x_out0", "pll_x",
> >>> - CLK_SET_RATE_PARENT, 1, 2);
> >>> - *dt_clk = clk;
> >>> -#endif
> >>> }
> >>>
> >>> --
> >>> 2.3.0
> >>>
> >
> > --
> > To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> > the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
> > More majordomo info at http://vger.kernel.org/majordomo-info.html
> > Please read the FAQ at http://www.tux.org/lkml/
next prev parent reply other threads:[~2015-04-13 19:31 UTC|newest]
Thread overview: 37+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-03-01 12:44 [PATCH v8 00/18] Tegra124 CL-DVFS / DFLL clocksource + cpufreq Mikko Perttunen
2015-03-01 12:44 ` [PATCH v8 02/18] clk: tegra: Add library for the DFLL clock source (open-loop mode) Mikko Perttunen
2015-03-01 12:44 ` [PATCH v8 04/18] clk: tegra: Add functions for parsing CVB tables Mikko Perttunen
2015-03-01 12:44 ` [PATCH v8 06/18] clk: tegra: Add DFLL DVCO reset control for Tegra124 Mikko Perttunen
2015-03-01 12:44 ` [PATCH v8 08/18] clk: tegra: Save/restore CCLKG_BURST_POLICY on suspend Mikko Perttunen
2015-03-01 12:44 ` [PATCH v8 09/18] clk: tegra: Add the DFLL as a possible parent of the cclk_g clock Mikko Perttunen
2015-03-01 12:44 ` [PATCH v8 10/18] clk: tegra: Initialize PLL_X before CCLK_G to ensure it has a parent Mikko Perttunen
2015-04-10 21:08 ` Michael Turquette
2015-04-11 11:00 ` Mikko Perttunen
2015-04-13 12:17 ` Tomeu Vizoso
[not found] ` <CAAObsKCHUG7Auwu29My5xfynsQ1Jm6KB0bGxf1e3uUO6dvsBRA-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
2015-04-13 19:31 ` Michael Turquette [this message]
2015-04-13 19:35 ` Mikko Perttunen
2015-03-01 12:44 ` [PATCH v8 12/18] ARM: tegra: Enable the DFLL on the Jetson TK1 Mikko Perttunen
2015-03-01 12:44 ` [PATCH v8 13/18] cpufreq: tegra124: Add device tree bindings Mikko Perttunen
2015-03-01 12:44 ` [PATCH v8 14/18] cpufreq: tegra: Rename tegra-cpufreq to tegra20-cpufreq Mikko Perttunen
2015-03-01 12:44 ` [PATCH v8 15/18] cpufreq: Add cpufreq driver for Tegra124 Mikko Perttunen
2015-03-02 8:49 ` Paul Bolle
2015-03-03 11:33 ` Mikko Perttunen
2015-03-04 7:11 ` Tuomas Tynkkynen
2015-03-05 10:15 ` Mikko Perttunen
[not found] ` <1425213881-5262-1-git-send-email-mikko.perttunen-/1wQRMveznE@public.gmane.org>
2015-03-01 12:44 ` [PATCH v8 01/18] clk: tegra: Add binding for the Tegra124 DFLL clocksource Mikko Perttunen
2015-03-01 12:44 ` [PATCH v8 03/18] clk: tegra: Add closed loop support for the DFLL Mikko Perttunen
2015-03-01 12:44 ` [PATCH v8 05/18] clk: tegra: Introduce ability for SoC-specific reset control callbacks Mikko Perttunen
2015-03-01 12:44 ` [PATCH v8 07/18] clk: tegra: Add Tegra124 DFLL clocksource platform driver Mikko Perttunen
2015-03-01 12:44 ` [PATCH v8 11/18] ARM: tegra: Add the DFLL to Tegra124 device tree Mikko Perttunen
2015-03-01 12:44 ` [PATCH v8 16/18] ARM: tegra: Add entries for cpufreq on Tegra124 Mikko Perttunen
2015-03-01 12:44 ` [PATCH v8 17/18] ARM: tegra: Add CPU regulator to the Jetson TK1 device tree Mikko Perttunen
2015-03-01 12:44 ` [PATCH v8 18/18] ARM: tegra: enable Tegra124 cpufreq driver by default Mikko Perttunen
2015-03-11 10:07 ` [PATCH v8 00/18] Tegra124 CL-DVFS / DFLL clocksource + cpufreq Thierry Reding
2015-04-10 21:11 ` Michael Turquette
2015-04-14 11:25 ` Mikko Perttunen
2015-04-14 17:21 ` Boris Brezillon
2015-04-14 19:40 ` Mikko Perttunen
2015-04-14 21:06 ` Michael Turquette
2015-04-14 21:10 ` Mikko Perttunen
2015-04-14 14:43 ` Thierry Reding
2015-04-14 21:09 ` Michael Turquette
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20150413193108.19585.29183@quantum \
--to=mturquette-qsej5fyqhm4dnm+yrofe0a@public.gmane.org \
--cc=gnurou-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org \
--cc=linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r@public.gmane.org \
--cc=linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org \
--cc=linux-pm-u79uwXL29TY76Z2rM5mHXA@public.gmane.org \
--cc=linux-tegra-u79uwXL29TY76Z2rM5mHXA@public.gmane.org \
--cc=mikko.perttunen-/1wQRMveznE@public.gmane.org \
--cc=pdeschrijver-DDmLM1+adcrQT0dZR+AlfA@public.gmane.org \
--cc=pgaikwad-DDmLM1+adcrQT0dZR+AlfA@public.gmane.org \
--cc=pwalmsley-DDmLM1+adcrQT0dZR+AlfA@public.gmane.org \
--cc=rjw-LthD3rsA81gm4RdzfppkhA@public.gmane.org \
--cc=swarren-3lzwWm7+Weoh9ZMKESR00Q@public.gmane.org \
--cc=thierry.reding-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org \
--cc=tomeu.vizoso-ZGY8ohtN/8qB+jHODAdFcQ@public.gmane.org \
--cc=tuomas.tynkkynen-X3B1VOXEql0@public.gmane.org \
--cc=vinceh-DDmLM1+adcrQT0dZR+AlfA@public.gmane.org \
--cc=viresh.kumar-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
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).