linux-arm-kernel.lists.infradead.org archive mirror
 help / color / mirror / Atom feed
From: haojian.zhuang@linaro.org (Haojian Zhuang)
To: linux-arm-kernel@lists.infradead.org
Subject: [PATCH v7 05/11] ARM: dts: enable hi4511 with device tree
Date: Sat, 24 Aug 2013 11:52:27 +0800	[thread overview]
Message-ID: <CAD6h2NTYNSFAQ0NWVwKXEr7BHUikmjROk-i+qYGo0otFPZKu0A@mail.gmail.com> (raw)
In-Reply-To: <52165D5E.7040500@wwwdotorg.org>

On 23 August 2013 02:50, Stephen Warren <swarren@wwwdotorg.org> wrote:
> On 08/22/2013 12:07 PM, Kevin Hilman wrote:
>> [+ DT maintainers]
>>
>> Haojian Zhuang <haojian.zhuang@linaro.org> writes:
>>
>>> Enable Hisilicon Hi4511 development platform with device tree support.
>>>
>>> Signed-off-by: Haojian Zhuang <haojian.zhuang@linaro.org>
> ...
>>> +/include/ "skeleton.dtsi"
>>> +
>>> +/ {
>>> +    aliases {
>>> +            serial0 = &uart0;
>>> +            serial1 = &uart1;
>>> +            serial2 = &uart2;
>>> +            serial3 = &uart3;
>>> +            serial4 = &uart4;
>>> +    };
>>> +
>>> +    cpus {
>>> +            #address-cells = <1>;
>>> +            #size-cells = <0>;
>>> +
>>> +            cpu0: cpu at 0 {
>>> +                    device_type = "cpu";
>>> +                    compatible = "arm,cortex-a9";
>>> +                    reg = <0x0>;
>>> +                    next-level-cache = <&L2>;
>>> +            };
>>> +    };
>>> +
>>> +    osc32k: osc32k {
>>> +            compatible = "fixed-clock";
>>> +            #clock-cells = <0>;
>>> +            clock-frequency = <32768>;
>>> +            clock-output-names = "osc32khz";
>>> +    };
>>
>> ...seems many of the recent users of clocks have grouped them into a
>> clocks {} grouping on a "simple-bus".
>>
>> DT folks: is there a rule of thumb on how whether these fixed clocks
>> should be grouped on a simple bus?
>
> I would expect all the clock node names to be just "clock", since the
> node names should describe the type of device not their identity (i.e.
> clock name).
>
> In turn, this means that each clock node name needs to use a unit
> address ("@nnn") to make them unique. In turn, this means they must have
> a reg property since the unit address must match the first entry in the
> reg property.

No, it's really bad on using a unit address. The register always contains
multiple mux or gate or divider. It would cause duplicated unit address.

I tried to use index number also. And it's also bad to append new clock nodes.
So I use the label name instead.

>
> Now I assume these clocks don't have any memory-mapped IO registers, so
> they would need an arbitrary reg value rather than a real one. So it
> doesn't make sense to place them directly under the root DT node, since
> their reg values would make no sense within the context of the
> CPU-visible MMIO space that the root node describes.
>
> In this case, it's typical to put all the clock nodes into e.g. a
> /clocks node, since that node can introduce a separate numbering-space
> for clocks. For example, I'd expect something like:
>
>         clocks {
>                 #address-cells = <1>;
>                 #size-cells = <0>;
>
>                 osc32k: clock at 0 {
>                         compatible = "fixed-clock";
>                         reg = <0>;
>                         #clock-cells = <0>;
>                         clock-frequency = <32768>;
>                         clock-output-names = "osc32khz";
>                 };
>
>                 osc26m: clock at 1 {
>                         compatible = "fixed-clock";
>                         reg = <1>;
>                         #clock-cells = <0>;
>                         clock-frequency = <26000000>;
>                         clock-output-names = "osc26mhz";
>                 };
>                 ...
>         };

Those fixed-clock doesn't contain reg property. Since it needs not to access
any clock register. It only provides the clock rate those child clock node.

>
> However, it also depends on what is actually providing those clocks. If
> every one of them is some standalone device on the board (e.g. a
> crystal), then just dumping them all in /clocks makes sense. However, if
> the clocks are provided by some on-SoC clock module, then I'd likely
> expect the clocks to be contained within the DT node that represents
> that clock module, which presumably does have some registers, and hence
> could be a direct child of the root node. For example, I wonder if the
> following is more accurate:
>
>         sctrl: sctrl at fc802000 {
>                 compatible = "hisilicon,sctrl";
>                 reg = <0xfc802000 0x1000>;
>                 #address-cells = <1>;
>                 #size-cells = <0>;
>
>                 osc32k: clock at 0 {
>                         compatible = "fixed-clock";
>                         reg = <0>;
>                         #clock-cells = <0>;
>                         clock-frequency = <32768>;
>                         clock-output-names = "osc32khz";
>                 };
>
>                 osc26m: clock at 1 {
>                         compatible = "fixed-clock";
>                         reg = <1>;
>                         #clock-cells = <0>;
>                         clock-frequency = <26000000>;
>                         clock-output-names = "osc26mhz";
>                 };
>                 ...
>         };
>
> ... since I see there are already quite a few clocks inside the sctrl node.

I can move all others clock nodes into clocks node, likes osc32k, osc26m.
Since they're not belong to sctrl register bank. And I also move all clock nodes
into a new dtsi file to make it more clearly.

  reply	other threads:[~2013-08-24  3:52 UTC|newest]

Thread overview: 35+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2013-08-20  2:31 [PATCH v7 00/11] Enable Hisilicon Hi3620 SoC Haojian Zhuang
2013-08-20  2:31 ` [PATCH v7 01/11] ARM: debug: support debug ll on hisilicon soc Haojian Zhuang
2013-08-20  2:31 ` [PATCH v7 02/11] clk: hi3xxx: add clock support Haojian Zhuang
2013-08-21 21:29   ` Mike Turquette
2013-08-24  4:13     ` Haojian Zhuang
2013-08-20  2:31 ` [PATCH v7 03/11] clk: gate: add CLK_GATE_SEPERATED_REG flag Haojian Zhuang
2013-08-21 21:18   ` Mike Turquette
2013-08-20  2:31 ` [PATCH v7 04/11] ARM: hi3xxx: add board support with device tree Haojian Zhuang
2013-08-20  2:31 ` [PATCH v7 05/11] ARM: dts: enable hi4511 " Haojian Zhuang
2013-08-22 18:07   ` Kevin Hilman
2013-08-22 18:50     ` Stephen Warren
2013-08-24  3:52       ` Haojian Zhuang [this message]
2013-08-26 16:48         ` Stephen Warren
2013-08-28  2:17           ` Haojian Zhuang
2013-08-28 14:20             ` Stephen Warren
2013-08-28 15:15               ` Haojian Zhuang
2013-08-28 15:45                 ` Stephen Warren
2013-08-24  3:59     ` Haojian Zhuang
2013-08-20  2:31 ` [PATCH v7 06/11] ARM: config: enable hi3xxx in multi_v7_defconfig Haojian Zhuang
2013-08-20  2:31 ` [PATCH v7 07/11] ARM: config: add defconfig for Hi3xxx Haojian Zhuang
2013-08-20  2:31 ` [PATCH v7 08/11] ARM: hi3xxx: add smp support Haojian Zhuang
2013-08-28  2:12   ` Olof Johansson
2013-08-28 11:53     ` zhangfei gao
2013-08-28 17:19       ` Olof Johansson
2013-08-29  1:54         ` zhangfei
2013-08-20  2:31 ` [PATCH v7 09/11] ARM: hi3xxx: add hotplug support Haojian Zhuang
2013-08-28  2:21   ` Olof Johansson
2013-08-28 11:45     ` zhangfei gao
2013-08-20  2:31 ` [PATCH v7 10/11] ARM: hi3xxx: add clk-hi3716 Haojian Zhuang
2013-08-21 21:43   ` Mike Turquette
2013-08-22  1:19     ` zhangfei gao
2013-08-22  5:59       ` Mike Turquette
2013-08-22  7:50         ` Haojian Zhuang
2013-08-22  8:16           ` Mike Turquette
2013-08-20  2:31 ` [PATCH v7 11/11] ARM: hi3xxx: support hi3716-dkb board Haojian Zhuang

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=CAD6h2NTYNSFAQ0NWVwKXEr7BHUikmjROk-i+qYGo0otFPZKu0A@mail.gmail.com \
    --to=haojian.zhuang@linaro.org \
    --cc=linux-arm-kernel@lists.infradead.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).