From: Alex Courbot <acourbot@nvidia.com>
To: Thierry Reding <thierry.reding@gmail.com>
Cc: Stephen Warren <swarren@wwwdotorg.org>,
Peter De Schrijver <pdeschrijver@nvidia.com>,
Prashant Gaikwad <pgaikwad@nvidia.com>,
"linux-tegra@vger.kernel.org" <linux-tegra@vger.kernel.org>,
"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
Mike Turquette <mturquette@linaro.org>
Subject: Re: [PATCH] ARM: tegra: properly use FUSE clock
Date: Tue, 19 Nov 2013 13:33:43 +0900 [thread overview]
Message-ID: <528AEA27.9090004@nvidia.com> (raw)
In-Reply-To: <20131118114330.GD8646@ulmo.nvidia.com>
On 11/18/2013 08:43 PM, Thierry Reding wrote:
> * PGP Signed by an unknown key
>
> On Mon, Nov 18, 2013 at 07:40:47PM +0900, Alexandre Courbot wrote:
>> FUSE clock is enabled by most bootloaders, but we cannot expect it to be
>> on in all contexts (e.g. kexec).
>>
>> This patch adds a FUSE clkdev to all Tegra platforms and makes sure
>> it is enabled before touching FUSE registers. tegra_init_fuse() is
>> invoked during very early boot and thus cannot rely on the clock
>> framework ; therefore the FUSE clock is forcibly enabled using a
>> register write in that function, and remains that way until the
>> clock framework can be used.
>>
>> Signed-off-by: Alexandre Courbot <acourbot@nvidia.com>
>> ---
>> arch/arm/mach-tegra/fuse.c | 41 +++++++++++++++++++++++++++++++++++++++-
>> drivers/clk/tegra/clk-tegra114.c | 1 +
>> drivers/clk/tegra/clk-tegra124.c | 1 +
>> drivers/clk/tegra/clk-tegra20.c | 1 +
>
> Isn't this missing the clock driver changes for Tegra30? Ah... Tegra30
> already has this clock defined. I wonder why only Tegra30 has it. grep
> says that fuse-tegra isn't used by any drivers, which also indicates
> that perhaps we don't need the .dev_id in the first place. We should be
> able to get by with just the .con_id = "fuse".
Will fix that.
> Also are there any reasons to keep this in one single patch? Since none
> of the fuse clocks are used yet, I think the clock changes could be a
> separate patch that can go in through the clock tree. And there isn't
> even a hard runtime dependency, since if the Tegra changes were to go in
> without the clock changes, then the fallback code in this patch should
> still turn the clock on properly. It just might not be turned off again,
> but isn't that something we can live with for a short period of time? I
> think perhaps that could even be improved, see further below.
>
> I've added Mike on Cc, he'll need to either take the patch in through
> his tree or Ack this one, so he needs to see it eventually.
I will split the change into two patches - at first I thought it would
not be worth the trouble, but I overlooked the fact this needed to go
through the clock source tree.
>
>> 4 files changed, 43 insertions(+), 1 deletion(-)
>>
>> diff --git a/arch/arm/mach-tegra/fuse.c b/arch/arm/mach-tegra/fuse.c
>> index 9a4e910c3796..3b9191b930b5 100644
>> --- a/arch/arm/mach-tegra/fuse.c
>> +++ b/arch/arm/mach-tegra/fuse.c
>> @@ -22,6 +22,7 @@
>> #include <linux/io.h>
>> #include <linux/export.h>
>> #include <linux/random.h>
>> +#include <linux/clk.h>
>> #include <linux/tegra-soc.h>
>>
>> #include "fuse.h"
>> @@ -54,6 +55,7 @@ int tegra_cpu_speedo_id; /* only exist in Tegra30 and later */
>> int tegra_soc_speedo_id;
>> enum tegra_revision tegra_revision;
>>
>> +static struct clk *fuse_clk;
>> static int tegra_fuse_spare_bit;
>> static void (*tegra_init_speedo_data)(void);
>>
>> @@ -77,6 +79,22 @@ static const char *tegra_revision_name[TEGRA_REVISION_MAX] = {
>> [TEGRA_REVISION_A04] = "A04",
>> };
>>
>> +static void tegra_fuse_enable_clk(void)
>> +{
>> + if (IS_ERR(fuse_clk))
>> + fuse_clk = clk_get_sys("fuse-tegra", "fuse");
>> + if (IS_ERR(fuse_clk))
>> + return;
>
> Perhaps instead of just returning here, this should actually be where
> the code to enable the clock should go.
>
>> + clk_prepare_enable(fuse_clk);
>> +}
>> +
>> +static void tegra_fuse_disable_clk(void)
>> +{
>> + if (IS_ERR(fuse_clk))
>> + return;
>
> And this is where we could disable it again. That way we should get
> equal functionality in both cases.
What Stephen said, basically - but let me address that in the other mail.
Thanks for the review!
Alex.
prev parent reply other threads:[~2013-11-19 4:33 UTC|newest]
Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top
2013-11-18 10:40 [PATCH] ARM: tegra: properly use FUSE clock Alexandre Courbot
2013-11-18 10:40 ` Alexandre Courbot
[not found] ` <1384771247-16547-1-git-send-email-acourbot-DDmLM1+adcrQT0dZR+AlfA@public.gmane.org>
2013-11-18 11:43 ` Thierry Reding
2013-11-18 11:43 ` Thierry Reding
2013-11-18 23:48 ` Stephen Warren
[not found] ` <528AA750.3080201-3lzwWm7+Weoh9ZMKESR00Q@public.gmane.org>
2013-11-19 4:53 ` Alex Courbot
2013-11-19 4:53 ` Alex Courbot
[not found] ` <528AEEB6.4070107-DDmLM1+adcrQT0dZR+AlfA@public.gmane.org>
2013-11-19 17:09 ` Stephen Warren
2013-11-19 17:09 ` Stephen Warren
2013-11-19 4:33 ` Alex Courbot [this message]
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=528AEA27.9090004@nvidia.com \
--to=acourbot@nvidia.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-tegra@vger.kernel.org \
--cc=mturquette@linaro.org \
--cc=pdeschrijver@nvidia.com \
--cc=pgaikwad@nvidia.com \
--cc=swarren@wwwdotorg.org \
--cc=thierry.reding@gmail.com \
/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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.