From: Nishanth Menon <nm@ti.com>
To: Tero Kristo <t-kristo@ti.com>, Rob Herring <robh@kernel.org>
Cc: linux-clk@vger.kernel.org, mturquette@baylibre.com,
sboyd@codeaurora.org, ssantosh@kernel.org,
linux-arm-kernel@lists.infradead.org, devicetree@vger.kernel.org
Subject: Re: [PATCH 1/3] Documentation: dt: Add TI SCI clock driver
Date: Mon, 31 Oct 2016 15:34:04 -0500 [thread overview]
Message-ID: <bce2ef84-491b-070a-dda4-77729567341c@ti.com> (raw)
In-Reply-To: <41c58712-bc00-ed05-9d1d-42e31397a70c@ti.com>
On 10/31/2016 07:50 AM, Tero Kristo wrote:
[...]
>>> +pmmc: pmmc {
>>> + compatible = "ti,k2g-sci";
>>> +
>>> + k2g_clks: k2g_clks {
>>
>> Use "clocks" for node name instead.
>>
>>> + compatible = "ti,k2g-sci-clk";
>>
>> I'm starting to think all these child nodes for SCI are pointless. Is
>> there any reason why the parent node can't be the clock provider (along
>> with all the other providers it acks as)?
>
> I believe the only reason to keep them separate is to have kernel side
> of things modular. If we have separate nodes, the drivers can be probed
> separately.
>
> If not, we need to build one huge blob with all the features in it, so
> the main driver can probe everything in one go, with annoying
> back-and-forth callbacks in place (assuming we still want to keep stuff
> somehow modular.)
Documentation/devicetree/bindings/arm/arm,scpi.txt follows the same
solution as well, right? There is indeed additional nodes coming in -
such as reset, pd etc.. I cant see why it is different for sci clk..
not to mention the driver mess it results in.
--
Regards,
Nishanth Menon
WARNING: multiple messages have this Message-ID (diff)
From: Nishanth Menon <nm@ti.com>
To: Tero Kristo <t-kristo@ti.com>, Rob Herring <robh@kernel.org>
Cc: <linux-clk@vger.kernel.org>, <mturquette@baylibre.com>,
<sboyd@codeaurora.org>, <ssantosh@kernel.org>,
<linux-arm-kernel@lists.infradead.org>,
<devicetree@vger.kernel.org>
Subject: Re: [PATCH 1/3] Documentation: dt: Add TI SCI clock driver
Date: Mon, 31 Oct 2016 15:34:04 -0500 [thread overview]
Message-ID: <bce2ef84-491b-070a-dda4-77729567341c@ti.com> (raw)
In-Reply-To: <41c58712-bc00-ed05-9d1d-42e31397a70c@ti.com>
On 10/31/2016 07:50 AM, Tero Kristo wrote:
[...]
>>> +pmmc: pmmc {
>>> + compatible = "ti,k2g-sci";
>>> +
>>> + k2g_clks: k2g_clks {
>>
>> Use "clocks" for node name instead.
>>
>>> + compatible = "ti,k2g-sci-clk";
>>
>> I'm starting to think all these child nodes for SCI are pointless. Is
>> there any reason why the parent node can't be the clock provider (along
>> with all the other providers it acks as)?
>
> I believe the only reason to keep them separate is to have kernel side
> of things modular. If we have separate nodes, the drivers can be probed
> separately.
>
> If not, we need to build one huge blob with all the features in it, so
> the main driver can probe everything in one go, with annoying
> back-and-forth callbacks in place (assuming we still want to keep stuff
> somehow modular.)
Documentation/devicetree/bindings/arm/arm,scpi.txt follows the same
solution as well, right? There is indeed additional nodes coming in -
such as reset, pd etc.. I cant see why it is different for sci clk..
not to mention the driver mess it results in.
--
Regards,
Nishanth Menon
WARNING: multiple messages have this Message-ID (diff)
From: nm@ti.com (Nishanth Menon)
To: linux-arm-kernel@lists.infradead.org
Subject: [PATCH 1/3] Documentation: dt: Add TI SCI clock driver
Date: Mon, 31 Oct 2016 15:34:04 -0500 [thread overview]
Message-ID: <bce2ef84-491b-070a-dda4-77729567341c@ti.com> (raw)
In-Reply-To: <41c58712-bc00-ed05-9d1d-42e31397a70c@ti.com>
On 10/31/2016 07:50 AM, Tero Kristo wrote:
[...]
>>> +pmmc: pmmc {
>>> + compatible = "ti,k2g-sci";
>>> +
>>> + k2g_clks: k2g_clks {
>>
>> Use "clocks" for node name instead.
>>
>>> + compatible = "ti,k2g-sci-clk";
>>
>> I'm starting to think all these child nodes for SCI are pointless. Is
>> there any reason why the parent node can't be the clock provider (along
>> with all the other providers it acks as)?
>
> I believe the only reason to keep them separate is to have kernel side
> of things modular. If we have separate nodes, the drivers can be probed
> separately.
>
> If not, we need to build one huge blob with all the features in it, so
> the main driver can probe everything in one go, with annoying
> back-and-forth callbacks in place (assuming we still want to keep stuff
> somehow modular.)
Documentation/devicetree/bindings/arm/arm,scpi.txt follows the same
solution as well, right? There is indeed additional nodes coming in -
such as reset, pd etc.. I cant see why it is different for sci clk..
not to mention the driver mess it results in.
--
Regards,
Nishanth Menon
next prev parent reply other threads:[~2016-10-31 20:34 UTC|newest]
Thread overview: 54+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-10-21 12:45 [PATCH 0/3] clk: keystone: add sci clock support Tero Kristo
2016-10-21 12:45 ` Tero Kristo
2016-10-21 12:45 ` Tero Kristo
2016-10-21 12:45 ` [PATCH 1/3] Documentation: dt: Add TI SCI clock driver Tero Kristo
2016-10-21 12:45 ` Tero Kristo
2016-10-21 12:45 ` Tero Kristo
2016-10-30 20:41 ` Rob Herring
2016-10-30 20:41 ` Rob Herring
2016-10-31 12:50 ` Tero Kristo
2016-10-31 12:50 ` Tero Kristo
2016-10-31 12:50 ` Tero Kristo
2016-10-31 20:34 ` Nishanth Menon [this message]
2016-10-31 20:34 ` Nishanth Menon
2016-10-31 20:34 ` Nishanth Menon
2016-11-18 17:20 ` Rob Herring
2016-11-18 17:20 ` Rob Herring
[not found] ` <CAL_JsqLtSs6ifnMdEOsfXpGoWnmXuGAx83+ziB9yU+zurvob+A-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
2016-11-21 8:14 ` Tero Kristo
2016-11-21 8:14 ` Tero Kristo
2016-11-21 8:14 ` Tero Kristo
2016-12-02 8:19 ` Tero Kristo
2016-12-02 8:19 ` Tero Kristo
2016-12-02 18:45 ` Rob Herring
2016-12-02 18:45 ` Rob Herring
2016-12-02 18:58 ` Stephen Boyd
2016-12-02 18:58 ` Stephen Boyd
[not found] ` <5f146fb6-ec88-b7ee-ef5b-a5ad32c54a74-sgV2jX0FEOL9JmXXK+q4OQ@public.gmane.org>
2016-12-02 21:07 ` Tero Kristo
2016-12-02 21:07 ` Tero Kristo
2016-12-02 21:07 ` Tero Kristo
2016-10-21 12:46 ` [PATCH 2/3] dt-binding: clock: Add k2g clock definitions Tero Kristo
2016-10-21 12:46 ` Tero Kristo
2016-10-21 12:46 ` Tero Kristo
2017-05-16 15:03 ` Tero Kristo
2017-05-16 15:03 ` Tero Kristo
2016-10-21 12:46 ` [PATCH 3/3] clk: keystone: Add sci-clk driver support Tero Kristo
2016-10-21 12:46 ` Tero Kristo
2016-10-21 12:46 ` Tero Kristo
2016-12-08 0:13 ` Stephen Boyd
2016-12-08 0:13 ` Stephen Boyd
2016-12-08 10:45 ` Tero Kristo
2016-12-08 10:45 ` Tero Kristo
2016-12-08 10:45 ` Tero Kristo
2016-12-08 21:10 ` Stephen Boyd
2016-12-08 21:10 ` Stephen Boyd
[not found] ` <20161208211044.GI5423-sgV2jX0FEOL9JmXXK+q4OQ@public.gmane.org>
2016-12-09 8:05 ` Tero Kristo
2016-12-09 8:05 ` Tero Kristo
2016-12-09 8:05 ` Tero Kristo
2016-12-12 19:38 ` Stephen Boyd
2016-12-12 19:38 ` Stephen Boyd
[not found] ` <20161212193800.GL5423-sgV2jX0FEOL9JmXXK+q4OQ@public.gmane.org>
2016-12-13 9:01 ` Tero Kristo
2016-12-13 9:01 ` Tero Kristo
2016-12-13 9:01 ` Tero Kristo
-- strict thread matches above, loose matches on Subject: below --
2016-08-20 0:33 [PATCH 0/3] ARM: K2G: Add support for TI-SCI Clocks Nishanth Menon
2016-08-20 0:33 ` [PATCH 1/3] Documentation: dt: Add TI SCI clock driver Nishanth Menon
2016-08-20 0:33 ` Nishanth Menon
2016-08-20 0:33 ` Nishanth Menon
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=bce2ef84-491b-070a-dda4-77729567341c@ti.com \
--to=nm@ti.com \
--cc=devicetree@vger.kernel.org \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=linux-clk@vger.kernel.org \
--cc=mturquette@baylibre.com \
--cc=robh@kernel.org \
--cc=sboyd@codeaurora.org \
--cc=ssantosh@kernel.org \
--cc=t-kristo@ti.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.