From: Prashant Gaikwad <pgaikwad-DDmLM1+adcrQT0dZR+AlfA@public.gmane.org>
To: Paul Walmsley <pwalmsley-DDmLM1+adcrQT0dZR+AlfA@public.gmane.org>
Cc: Stephen Warren <swarren-3lzwWm7+Weoh9ZMKESR00Q@public.gmane.org>,
"linux-tegra-u79uwXL29TY76Z2rM5mHXA@public.gmane.org"
<linux-tegra-u79uwXL29TY76Z2rM5mHXA@public.gmane.org>,
"mturquette-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org"
<mturquette-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org>,
Peter De Schrijver
<pdeschrijver-DDmLM1+adcrQT0dZR+AlfA@public.gmane.org>,
Aleksandr Frid <afrid-DDmLM1+adcrQT0dZR+AlfA@public.gmane.org>,
"linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org"
<linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org>,
"linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r@public.gmane.org"
<linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r@public.gmane.org>
Subject: Re: [PATCH 3/3] clk: tegra: T114: add DFLL DVCO reset control
Date: Tue, 11 Jun 2013 13:01:05 +0530 [thread overview]
Message-ID: <51B6D239.5030905@nvidia.com> (raw)
In-Reply-To: <alpine.DEB.2.02.1306071703050.7753-rwI8Ez+7Ko+d5PgPZx9QOdBPR1lH4CV8@public.gmane.org>
On Friday 07 June 2013 10:36 PM, Paul Walmsley wrote:
> Hi Stephen,
>
> On Fri, 7 Jun 2013, Stephen Warren wrote:
>
>> On 06/07/2013 06:19 AM, Paul Walmsley wrote:
>>> Add DFLL DVCO reset line control functions to the CAR IP block driver.
>>>
>>> The DVCO present in the DFLL IP block has a separate reset line,
>>> exposed via the CAR IP block. This reset line is asserted upon SoC
>>> reset. Unless something (such as the DFLL driver) deasserts this
>>> line, the DVCO will not oscillate, although reads and writes to the
>>> DFLL IP block will complete.
>>>
>>> Thanks to Aleksandr Frid <afrid-DDmLM1+adcrQT0dZR+AlfA@public.gmane.org> for identifying this and
>>> saving hours of debugging time.
>>> diff --git a/drivers/clk/tegra/clk.h b/drivers/clk/tegra/clk.h
>>> void tegra114_clock_tune_cpu_trimmers_high(void);
>>> void tegra114_clock_tune_cpu_trimmers_low(void);
>>> void tegra114_clock_tune_cpu_trimmers_init(void);
>>> +void tegra114_clock_assert_dfll_dvco_reset(void);
>>> +void tegra114_clock_deassert_dfll_dvco_reset(void);
>> Where/what is the code that will call these new APIs? If it's going to
>> be something in drivers/clk, that seems fine.
> That's correct - they'll be used by the DFLL clocksource code, which will
> live in drivers/clk/tegra. You've seen the patches already ;-)
Why not implement these APIs in DFLL clock driver itself and pass RST
address register to driver?
>> The reset assert/de-assert functions at least might be worth exposing
>> using the new generic module reset API. I believe Prashant Gaikwad is
>> working on converting the Tegra clock driver to be a module reset
>> provider, hence removing the existing custom
>> tegra_periph_reset_{de,}assert() APIs.
> OK, will take a look to see if this can be done without getting in the way
> of Prashant's work. I'd naïvely assume that it might be best to convert
> these as part of his series - that way we won't duplicate effort.
>
> Prashant, what stage are you at in the conversion? If you're close to
> completion, maybe we can just add this functionality in with your patches?
>
You can continue with this patch. I do not see any need to add this
reset control to generic reset module.
> - Paul
WARNING: multiple messages have this Message-ID (diff)
From: pgaikwad@nvidia.com (Prashant Gaikwad)
To: linux-arm-kernel@lists.infradead.org
Subject: [PATCH 3/3] clk: tegra: T114: add DFLL DVCO reset control
Date: Tue, 11 Jun 2013 13:01:05 +0530 [thread overview]
Message-ID: <51B6D239.5030905@nvidia.com> (raw)
In-Reply-To: <alpine.DEB.2.02.1306071703050.7753@utopia.booyaka.com>
On Friday 07 June 2013 10:36 PM, Paul Walmsley wrote:
> Hi Stephen,
>
> On Fri, 7 Jun 2013, Stephen Warren wrote:
>
>> On 06/07/2013 06:19 AM, Paul Walmsley wrote:
>>> Add DFLL DVCO reset line control functions to the CAR IP block driver.
>>>
>>> The DVCO present in the DFLL IP block has a separate reset line,
>>> exposed via the CAR IP block. This reset line is asserted upon SoC
>>> reset. Unless something (such as the DFLL driver) deasserts this
>>> line, the DVCO will not oscillate, although reads and writes to the
>>> DFLL IP block will complete.
>>>
>>> Thanks to Aleksandr Frid <afrid@nvidia.com> for identifying this and
>>> saving hours of debugging time.
>>> diff --git a/drivers/clk/tegra/clk.h b/drivers/clk/tegra/clk.h
>>> void tegra114_clock_tune_cpu_trimmers_high(void);
>>> void tegra114_clock_tune_cpu_trimmers_low(void);
>>> void tegra114_clock_tune_cpu_trimmers_init(void);
>>> +void tegra114_clock_assert_dfll_dvco_reset(void);
>>> +void tegra114_clock_deassert_dfll_dvco_reset(void);
>> Where/what is the code that will call these new APIs? If it's going to
>> be something in drivers/clk, that seems fine.
> That's correct - they'll be used by the DFLL clocksource code, which will
> live in drivers/clk/tegra. You've seen the patches already ;-)
Why not implement these APIs in DFLL clock driver itself and pass RST
address register to driver?
>> The reset assert/de-assert functions at least might be worth exposing
>> using the new generic module reset API. I believe Prashant Gaikwad is
>> working on converting the Tegra clock driver to be a module reset
>> provider, hence removing the existing custom
>> tegra_periph_reset_{de,}assert() APIs.
> OK, will take a look to see if this can be done without getting in the way
> of Prashant's work. I'd na?vely assume that it might be best to convert
> these as part of his series - that way we won't duplicate effort.
>
> Prashant, what stage are you at in the conversion? If you're close to
> completion, maybe we can just add this functionality in with your patches?
>
You can continue with this patch. I do not see any need to add this
reset control to generic reset module.
> - Paul
WARNING: multiple messages have this Message-ID (diff)
From: Prashant Gaikwad <pgaikwad@nvidia.com>
To: Paul Walmsley <pwalmsley@nvidia.com>
Cc: Stephen Warren <swarren@wwwdotorg.org>,
"linux-tegra@vger.kernel.org" <linux-tegra@vger.kernel.org>,
"mturquette@linaro.org" <mturquette@linaro.org>,
Peter De Schrijver <pdeschrijver@nvidia.com>,
Aleksandr Frid <afrid@nvidia.com>,
"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
"linux-arm-kernel@lists.infradead.org"
<linux-arm-kernel@lists.infradead.org>
Subject: Re: [PATCH 3/3] clk: tegra: T114: add DFLL DVCO reset control
Date: Tue, 11 Jun 2013 13:01:05 +0530 [thread overview]
Message-ID: <51B6D239.5030905@nvidia.com> (raw)
In-Reply-To: <alpine.DEB.2.02.1306071703050.7753@utopia.booyaka.com>
On Friday 07 June 2013 10:36 PM, Paul Walmsley wrote:
> Hi Stephen,
>
> On Fri, 7 Jun 2013, Stephen Warren wrote:
>
>> On 06/07/2013 06:19 AM, Paul Walmsley wrote:
>>> Add DFLL DVCO reset line control functions to the CAR IP block driver.
>>>
>>> The DVCO present in the DFLL IP block has a separate reset line,
>>> exposed via the CAR IP block. This reset line is asserted upon SoC
>>> reset. Unless something (such as the DFLL driver) deasserts this
>>> line, the DVCO will not oscillate, although reads and writes to the
>>> DFLL IP block will complete.
>>>
>>> Thanks to Aleksandr Frid <afrid@nvidia.com> for identifying this and
>>> saving hours of debugging time.
>>> diff --git a/drivers/clk/tegra/clk.h b/drivers/clk/tegra/clk.h
>>> void tegra114_clock_tune_cpu_trimmers_high(void);
>>> void tegra114_clock_tune_cpu_trimmers_low(void);
>>> void tegra114_clock_tune_cpu_trimmers_init(void);
>>> +void tegra114_clock_assert_dfll_dvco_reset(void);
>>> +void tegra114_clock_deassert_dfll_dvco_reset(void);
>> Where/what is the code that will call these new APIs? If it's going to
>> be something in drivers/clk, that seems fine.
> That's correct - they'll be used by the DFLL clocksource code, which will
> live in drivers/clk/tegra. You've seen the patches already ;-)
Why not implement these APIs in DFLL clock driver itself and pass RST
address register to driver?
>> The reset assert/de-assert functions at least might be worth exposing
>> using the new generic module reset API. I believe Prashant Gaikwad is
>> working on converting the Tegra clock driver to be a module reset
>> provider, hence removing the existing custom
>> tegra_periph_reset_{de,}assert() APIs.
> OK, will take a look to see if this can be done without getting in the way
> of Prashant's work. I'd naïvely assume that it might be best to convert
> these as part of his series - that way we won't duplicate effort.
>
> Prashant, what stage are you at in the conversion? If you're close to
> completion, maybe we can just add this functionality in with your patches?
>
You can continue with this patch. I do not see any need to add this
reset control to generic reset module.
> - Paul
next prev parent reply other threads:[~2013-06-11 7:31 UTC|newest]
Thread overview: 40+ messages / expand[flat|nested] mbox.gz Atom feed top
2013-06-07 12:18 [PATCH 0/3] clk: tegra: T114: add DFLL prerequisites Paul Walmsley
2013-06-07 12:18 ` Paul Walmsley
2013-06-07 12:18 ` Paul Walmsley
[not found] ` <20130607121505.21868.72360.stgit-orwA252wQtA@public.gmane.org>
2013-06-07 12:18 ` [PATCH 1/3] clk: tegra: T114: add FCPU clock shaper programming, needed by the DFLL Paul Walmsley
2013-06-07 12:18 ` Paul Walmsley
2013-06-07 12:18 ` Paul Walmsley
2013-06-07 12:19 ` [PATCH 2/3] clk: tegra: T114: add DFLL source clocks Paul Walmsley
2013-06-07 12:19 ` Paul Walmsley
2013-06-07 12:19 ` Paul Walmsley
[not found] ` <20130607121858.21868.73882.stgit-orwA252wQtA@public.gmane.org>
2013-06-07 16:53 ` Stephen Warren
2013-06-07 16:53 ` Stephen Warren
2013-06-07 16:53 ` Stephen Warren
2013-06-07 12:19 ` [PATCH 3/3] clk: tegra: T114: add DFLL DVCO reset control Paul Walmsley
2013-06-07 12:19 ` Paul Walmsley
[not found] ` <20130607121901.21868.65416.stgit-orwA252wQtA@public.gmane.org>
2013-06-07 16:57 ` Stephen Warren
2013-06-07 16:57 ` Stephen Warren
2013-06-07 16:57 ` Stephen Warren
[not found] ` <51B21105.1080301-3lzwWm7+Weoh9ZMKESR00Q@public.gmane.org>
2013-06-07 17:06 ` Paul Walmsley
2013-06-07 17:06 ` Paul Walmsley
2013-06-07 17:06 ` Paul Walmsley
[not found] ` <alpine.DEB.2.02.1306071703050.7753-rwI8Ez+7Ko+d5PgPZx9QOdBPR1lH4CV8@public.gmane.org>
2013-06-11 7:31 ` Prashant Gaikwad [this message]
2013-06-11 7:31 ` Prashant Gaikwad
2013-06-11 7:31 ` Prashant Gaikwad
2013-06-11 9:47 ` Paul Walmsley
2013-06-11 9:47 ` Paul Walmsley
[not found] ` <alpine.DEB.2.02.1306110944130.22645-rwI8Ez+7Ko+d5PgPZx9QOdBPR1lH4CV8@public.gmane.org>
2013-06-16 4:22 ` Mike Turquette
2013-06-16 4:22 ` Mike Turquette
2013-06-16 4:22 ` Mike Turquette
2013-06-17 20:22 ` Paul Walmsley
2013-06-17 20:22 ` Paul Walmsley
2013-06-17 20:22 ` Paul Walmsley
[not found] ` <alpine.DEB.2.02.1306172019270.17176-rwI8Ez+7Ko+d5PgPZx9QOdBPR1lH4CV8@public.gmane.org>
2013-06-18 18:28 ` Mike Turquette
2013-06-18 18:28 ` Mike Turquette
2013-06-18 18:28 ` Mike Turquette
2013-06-18 18:33 ` Paul Walmsley
2013-06-18 18:33 ` Paul Walmsley
2013-06-18 18:33 ` Paul Walmsley
2013-06-19 8:45 ` Peter De Schrijver
2013-06-19 8:45 ` Peter De Schrijver
2013-06-19 8:45 ` Peter De Schrijver
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=51B6D239.5030905@nvidia.com \
--to=pgaikwad-ddmlm1+adcrqt0dzr+alfa@public.gmane.org \
--cc=afrid-DDmLM1+adcrQT0dZR+AlfA@public.gmane.org \
--cc=linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r@public.gmane.org \
--cc=linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org \
--cc=linux-tegra-u79uwXL29TY76Z2rM5mHXA@public.gmane.org \
--cc=mturquette-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org \
--cc=pdeschrijver-DDmLM1+adcrQT0dZR+AlfA@public.gmane.org \
--cc=pwalmsley-DDmLM1+adcrQT0dZR+AlfA@public.gmane.org \
--cc=swarren-3lzwWm7+Weoh9ZMKESR00Q@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 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.