All of lore.kernel.org
 help / color / mirror / Atom feed
From: Tomasz Figa <tomasz.figa@gmail.com>
To: Sylwester Nawrocki <s.nawrocki@samsung.com>
Cc: "Alim Akhtar" <alim.akhtar@samsung.com>,
	linux-arm-kernel <linux-arm-kernel@lists.infradead.org>,
	"Thomas Abraham" <thomas.ab@samsung.com>,
	"Krzysztof Kozłowski" <k.kozlowski@samsung.com>,
	linux-kernel <linux-kernel@vger.kernel.org>,
	"linux-samsung-soc@vger.kernel.org"
	<linux-samsung-soc@vger.kernel.org>,
	linux-clk@vger.kernel.org, "Stephen Boyd" <sboyd@codeaurora.org>,
	"Michael Turquette" <mturquette@baylibre.com>
Subject: Re: [PATCH] clk: samsung: exynos7: Enable clocks for CMU_CCORE and CMU_FSYS0 blocks
Date: Wed, 13 Apr 2016 14:31:31 +0300	[thread overview]
Message-ID: <CA+Ln22Gf+aXnOzj-qYeNq5-MO8b+tjxrp0KPtG7Q2ceStk4ERA@mail.gmail.com> (raw)
In-Reply-To: <570E2123.1000107@samsung.com>

2016-04-13 13:36 GMT+03:00 Sylwester Nawrocki <s.nawrocki@samsung.com>:
> On 04/13/2016 08:26 AM, Tomasz Figa wrote:
>>> > @@ -205,7 +206,11 @@ static struct samsung_cmu_info topc_cmu_info __initdata = {
>>> >
>>> >  static void __init exynos7_clk_topc_init(struct device_node *np)
>>> >  {
>>> > +       struct clk *clk;
>>> > +
>>> >         samsung_cmu_register_one(np, &topc_cmu_info);
>>> > +       clk = __clk_lookup("aclk_ccore_133");
>>> > +       clk_prepare_enable(clk);
>>
>> Shouldn't this be rather done before calling
>> samsung_cmu_register_one()? I don't remember exactly, but wouldn't
>> clock registration trigger reading back current (mux, div) values from
>> registers?
>>
>> Also, do we have any guarantees on order of initialization of
>> particular CMUs? I believe this will happen in order of DT nodes and
>> so would be not any kind of guarantee at all.
>
> If these clocks need to be kept enabled perhaps it's better to just set
> CLK_IS_CRITICAL flag for them? Patches adding this flag are already in
> clk-next branch in the clk git tree. This way the clocks would get
> enabled within the clk_register() call.
>

Oh, I didn't know about this. Sounds like a good idea. :)

> The CMU registration order is enforced by listing input clocks to each
> CMU in DT.

Ah, right, I recall now, I even reviewed relevant patch. Thanks for
refreshing my memory.

> However, I wouldn't be concerned much about it in context
> of this patch. We are enabling here clocks which belong to same CMU.
> samsung_cmu_register_one() needs to be called first for subsequent
> __clk_lookup() calls to work.

I thought a clock from another CMU has to be enabled for the CPU to be
able to access the CMU being registered.

>
> Perhaps related bits need to be set manually in CMU registers before
> registering a clock provider for the CMU, to fulfil the requirements.
>
> Anyway, summary of the $subject patch seems not precise enough:
>
> "This patch enables clocks for CMU_CCORE and CMU_FSYS0 blocks. This is
> required before accessing registers of these blocks."
>
> We need to enable selected clocks (i.e. access the CMU's registers)
> before accessing this CMU's registers?

Yeah, maybe the explanation could be a bit more precise.

Best regards,
Tomasz

WARNING: multiple messages have this Message-ID (diff)
From: tomasz.figa@gmail.com (Tomasz Figa)
To: linux-arm-kernel@lists.infradead.org
Subject: [PATCH] clk: samsung: exynos7: Enable clocks for CMU_CCORE and CMU_FSYS0 blocks
Date: Wed, 13 Apr 2016 14:31:31 +0300	[thread overview]
Message-ID: <CA+Ln22Gf+aXnOzj-qYeNq5-MO8b+tjxrp0KPtG7Q2ceStk4ERA@mail.gmail.com> (raw)
In-Reply-To: <570E2123.1000107@samsung.com>

2016-04-13 13:36 GMT+03:00 Sylwester Nawrocki <s.nawrocki@samsung.com>:
> On 04/13/2016 08:26 AM, Tomasz Figa wrote:
>>> > @@ -205,7 +206,11 @@ static struct samsung_cmu_info topc_cmu_info __initdata = {
>>> >
>>> >  static void __init exynos7_clk_topc_init(struct device_node *np)
>>> >  {
>>> > +       struct clk *clk;
>>> > +
>>> >         samsung_cmu_register_one(np, &topc_cmu_info);
>>> > +       clk = __clk_lookup("aclk_ccore_133");
>>> > +       clk_prepare_enable(clk);
>>
>> Shouldn't this be rather done before calling
>> samsung_cmu_register_one()? I don't remember exactly, but wouldn't
>> clock registration trigger reading back current (mux, div) values from
>> registers?
>>
>> Also, do we have any guarantees on order of initialization of
>> particular CMUs? I believe this will happen in order of DT nodes and
>> so would be not any kind of guarantee at all.
>
> If these clocks need to be kept enabled perhaps it's better to just set
> CLK_IS_CRITICAL flag for them? Patches adding this flag are already in
> clk-next branch in the clk git tree. This way the clocks would get
> enabled within the clk_register() call.
>

Oh, I didn't know about this. Sounds like a good idea. :)

> The CMU registration order is enforced by listing input clocks to each
> CMU in DT.

Ah, right, I recall now, I even reviewed relevant patch. Thanks for
refreshing my memory.

> However, I wouldn't be concerned much about it in context
> of this patch. We are enabling here clocks which belong to same CMU.
> samsung_cmu_register_one() needs to be called first for subsequent
> __clk_lookup() calls to work.

I thought a clock from another CMU has to be enabled for the CPU to be
able to access the CMU being registered.

>
> Perhaps related bits need to be set manually in CMU registers before
> registering a clock provider for the CMU, to fulfil the requirements.
>
> Anyway, summary of the $subject patch seems not precise enough:
>
> "This patch enables clocks for CMU_CCORE and CMU_FSYS0 blocks. This is
> required before accessing registers of these blocks."
>
> We need to enable selected clocks (i.e. access the CMU's registers)
> before accessing this CMU's registers?

Yeah, maybe the explanation could be a bit more precise.

Best regards,
Tomasz

  reply	other threads:[~2016-04-13 11:31 UTC|newest]

Thread overview: 12+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2016-04-12 11:07 [PATCH] clk: samsung: exynos7: Enable clocks for CMU_CCORE and CMU_FSYS0 blocks Alim Akhtar
2016-04-12 11:07 ` Alim Akhtar
2016-04-12 11:37 ` Sylwester Nawrocki
2016-04-12 11:37   ` Sylwester Nawrocki
2016-04-13  6:26 ` Tomasz Figa
2016-04-13  6:26   ` Tomasz Figa
2016-04-13 10:36   ` Sylwester Nawrocki
2016-04-13 10:36     ` Sylwester Nawrocki
2016-04-13 11:31     ` Tomasz Figa [this message]
2016-04-13 11:31       ` Tomasz Figa
2016-04-13 11:54       ` Alim Akhtar
2016-04-13 11:54         ` Alim Akhtar

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=CA+Ln22Gf+aXnOzj-qYeNq5-MO8b+tjxrp0KPtG7Q2ceStk4ERA@mail.gmail.com \
    --to=tomasz.figa@gmail.com \
    --cc=alim.akhtar@samsung.com \
    --cc=k.kozlowski@samsung.com \
    --cc=linux-arm-kernel@lists.infradead.org \
    --cc=linux-clk@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-samsung-soc@vger.kernel.org \
    --cc=mturquette@baylibre.com \
    --cc=s.nawrocki@samsung.com \
    --cc=sboyd@codeaurora.org \
    --cc=thomas.ab@samsung.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.