From: Thierry Reding <thierry.reding@gmail.com>
To: Stephen Warren <swarren@wwwdotorg.org>
Cc: Prashant Gaikwad <pgaikwad@nvidia.com>,
Stephen Boyd <sboyd@kernel.org>,
Peter De Schrijver <pdeschrijver@nvidia.com>,
linux-clk@vger.kernel.org, Jonathan Hunter <jonathanh@nvidia.com>,
linux-tegra@vger.kernel.org,
Michael Turquette <mturquette@baylibre.com>,
linux-arm-kernel@lists.infradead.org
Subject: Re: [PATCH 1/4] clk: tegra: Enable fuse clock on Tegra124
Date: Fri, 4 Oct 2019 14:18:12 +0200 [thread overview]
Message-ID: <20191004121812.GB227112@ulmo> (raw)
In-Reply-To: <6a48d716-2312-4623-f47a-a53ac2ece83c@wwwdotorg.org>
[-- Attachment #1.1: Type: text/plain, Size: 3483 bytes --]
On Wed, Oct 02, 2019 at 02:59:03PM -0600, Stephen Warren wrote:
> On 10/2/19 5:04 AM, Thierry Reding wrote:
> > On Tue, Oct 01, 2019 at 03:13:43PM -0600, Stephen Warren wrote:
> > > From: Stephen Warren <swarren@nvidia.com>
> > >
> > > For a little over a year, U-Boot has configured the flow controller to
> > > perform automatic RAM re-repair on off->on power transitions of the CPU
> > > rail1]. This is mandatory for correct operation of Tegra124. However, RAM
> > > re-repair relies on certain clocks, which the kernel must enable and
> > > leave running. The fuse clock is one of those clocks. Enable this clock
> > > so that LP1 power mode (system suspend) operates correctly.
> > >
> > > [1] 3cc7942a4ae5 ARM: tegra: implement RAM repair
> > >
> > > Reported-by: Jonathan Hunter <jonathanh@nvidia.com>
> > > Cc: stable@vger.kernel.org
> > > Signed-off-by: Stephen Warren <swarren@nvidia.com>
> > > ---
> > > drivers/clk/tegra/clk-tegra124.c | 1 +
> > > 1 file changed, 1 insertion(+)
> > >
> > > diff --git a/drivers/clk/tegra/clk-tegra124.c b/drivers/clk/tegra/clk-tegra124.c
> > > index 0224fdc4766f..f53f6315c646 100644
> > > --- a/drivers/clk/tegra/clk-tegra124.c
> > > +++ b/drivers/clk/tegra/clk-tegra124.c
> > > @@ -1291,6 +1291,7 @@ static struct tegra_clk_init_table common_init_table[] __initdata = {
> > > };
> > > static struct tegra_clk_init_table tegra124_init_table[] __initdata = {
> > > + { TEGRA124_CLK_FUSE, -1, 0, 1 },
> >
> > I think the correct way to do this these days is to mark the clock as
> > CRITICAL. Not sure if there's an easy way to do that given that the
> > clock init table doesn't allow storing flags.
> >
> > Do you have any good ideas on how to achieve this with the critical flag
> > instead of forcing the refcount to 1?
> >
> > Perhaps something like the below would work?
> > ...
>
> The following works for me; does this seem like a reasonable approach? It
> does set the critical flag for all SoCs, including any that don't require
> RAM re-repair. I'm not sure which do; I know it's more than just Tegra124,
> but I'm not sure how far back/forward the requirement goes.
>
> > diff --git a/drivers/clk/tegra/clk-tegra-periph.c b/drivers/clk/tegra/clk-tegra-periph.c
> > index 1ed85f120a1b..76dd91eebd13 100644
> > --- a/drivers/clk/tegra/clk-tegra-periph.c
> > +++ b/drivers/clk/tegra/clk-tegra-periph.c
> > @@ -785,7 +785,7 @@ static struct tegra_periph_init_data gate_clks[] = {
> > GATE("ahbdma", "hclk", 33, 0, tegra_clk_ahbdma, 0),
> > GATE("apbdma", "pclk", 34, 0, tegra_clk_apbdma, 0),
> > GATE("kbc", "clk_32k", 36, TEGRA_PERIPH_ON_APB | TEGRA_PERIPH_NO_RESET, tegra_clk_kbc, 0),
> > - GATE("fuse", "clk_m", 39, TEGRA_PERIPH_ON_APB, tegra_clk_fuse, 0),
> > + GATE("fuse", "clk_m", 39, TEGRA_PERIPH_ON_APB, tegra_clk_fuse, CLK_IS_CRITICAL),
> > GATE("fuse_burn", "clk_m", 39, TEGRA_PERIPH_ON_APB, tegra_clk_fuse_burn, 0),
> > GATE("kfuse", "clk_m", 40, TEGRA_PERIPH_ON_APB, tegra_clk_kfuse, 0),
> > GATE("apbif", "clk_m", 107, TEGRA_PERIPH_ON_APB, tegra_clk_apbif, 0),
It's probably fine to do this. The patch I proposed would've restricted
the change to just Tegra124. But if we need this on other generations, I
don't think the extra complexity is justified, especially since I can't
imagine that the FUSE clock remaining always on would consume a lot of
extra power.
Thierry
[-- Attachment #1.2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]
[-- Attachment #2: Type: text/plain, Size: 176 bytes --]
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
next prev parent reply other threads:[~2019-10-04 12:18 UTC|newest]
Thread overview: 13+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-10-01 21:13 [PATCH 1/4] clk: tegra: Enable fuse clock on Tegra124 Stephen Warren
2019-10-01 21:13 ` [PATCH 2/4] ARM: tegra: Enable PLLP bypass during Tegra124 LP1 Stephen Warren
2019-10-03 11:27 ` Dmitry Osipenko
2019-10-03 16:34 ` Stephen Warren
2019-10-03 18:00 ` Dmitry Osipenko
2019-10-01 21:13 ` [PATCH 3/4] ARM: tegra: modify reshift divider during LP1 Stephen Warren
2019-10-01 21:13 ` PATCH 4/4] ARM: tegra: use clk_m CPU on Tegra124 LP1 resume Stephen Warren
2019-10-02 11:04 ` [PATCH 1/4] clk: tegra: Enable fuse clock on Tegra124 Thierry Reding
2019-10-02 20:59 ` Stephen Warren
2019-10-04 12:18 ` Thierry Reding [this message]
2019-10-04 16:07 ` Stephen Warren
2019-10-03 11:23 ` Dmitry Osipenko
2019-10-03 16:28 ` Stephen Warren
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=20191004121812.GB227112@ulmo \
--to=thierry.reding@gmail.com \
--cc=jonathanh@nvidia.com \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=linux-clk@vger.kernel.org \
--cc=linux-tegra@vger.kernel.org \
--cc=mturquette@baylibre.com \
--cc=pdeschrijver@nvidia.com \
--cc=pgaikwad@nvidia.com \
--cc=sboyd@kernel.org \
--cc=swarren@wwwdotorg.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).