From: Krzysztof Kozlowski <krzysztof.kozlowski@canonical.com>
To: "Hawkins, Nick" <nick.hawkins@hpe.com>,
"Verdun, Jean-Marie" <verdun@hpe.com>
Cc: Arnd Bergmann <arnd@arndb.de>, Olof Johansson <olof@lixom.net>,
"soc@kernel.org" <soc@kernel.org>,
Rob Herring <robh+dt@kernel.org>,
"linux-arm-kernel@lists.infradead.org"
<linux-arm-kernel@lists.infradead.org>,
"devicetree@vger.kernel.org" <devicetree@vger.kernel.org>,
"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>
Subject: Re: [PATCH v3 09/10] arch: arm: boot: dts: Introduce HPE GXP Device tree
Date: Wed, 16 Mar 2022 16:50:52 +0100 [thread overview]
Message-ID: <b1cc2566-cd78-7cb4-f8a5-d6fc8065fe6e@canonical.com> (raw)
In-Reply-To: <PH0PR84MB1718C31DB71AA2A67FEC5F6E88119@PH0PR84MB1718.NAMPRD84.PROD.OUTLOOK.COM>
On 16/03/2022 16:41, Hawkins, Nick wrote:
> -----Original Message-----
> From: Krzysztof Kozlowski [mailto:krzysztof.kozlowski@canonical.com]
> Sent: Friday, March 11, 2022 4:30 AM
> To: Hawkins, Nick <nick.hawkins@hpe.com>>; Verdun, Jean-Marie <verdun@hpe.com>>
> Cc: Arnd Bergmann <arnd@arndb.de>>; Olof Johansson <olof@lixom.net>>; soc@kernel.org; Rob Herring <robh+dt@kernel.org>>; linux-arm-kernel@lists.infradead.org; devicetree@vger.kernel.org; linux-kernel@vger.kernel.org
> Subject: Re: [PATCH v3 09/10] arch: arm: boot: dts: Introduce HPE GXP Device tree
>
> On 10/03/2022 20:52, nick.hawkins@hpe.com wrote:
>>> From: Nick Hawkins <nick.hawkins@hpe.com>>
>>>
>>> The HPE SoC is new to linux. This patch creates the basic device tree
>>> layout with minimum required for linux to boot. This includes timer
>>> and watchdog support.
>>>
>>> Signed-off-by: Nick Hawkins <nick.hawkins@hpe.com>>
>>> ---
>>> arch/arm/boot/dts/Makefile | 2 +
>>> arch/arm/boot/dts/hpe-bmc-dl360gen10.dts | 27 +++++
>>> arch/arm/boot/dts/hpe-gxp.dtsi | 148 +++++++++++++++++++++++
>>> 3 files changed, 177 insertions(+)
>>> create mode 100644 arch/arm/boot/dts/hpe-bmc-dl360gen10.dts
>>> create mode 100644 arch/arm/boot/dts/hpe-gxp.dtsi
>>>
>>> diff --git a/arch/arm/boot/dts/Makefile b/arch/arm/boot/dts/Makefile
>>> index e41eca79c950..2823b359d373 100644
>>> --- a/arch/arm/boot/dts/Makefile
>>> +++ b/arch/arm/boot/dts/Makefile
>>> @@ -1550,3 +1550,5 @@ dtb-$(CONFIG_ARCH_ASPEED) += \
>>> aspeed-bmc-vegman-n110.dtb \
>>> aspeed-bmc-vegman-rx20.dtb \
>>> aspeed-bmc-vegman-sx20.dtb
>>> +dtb-$(CONFIG_ARCH_HPE_GXP) += \
>>> + hpe-bmc-dl360gen10.dtb
>
>> Alphabetically, also in respect to other architectures, so before CONFIG_ARCH_INTEGRATOR.
>
> Done
>
>>> diff --git a/arch/arm/boot/dts/hpe-bmc-dl360gen10.dts
>>> b/arch/arm/boot/dts/hpe-bmc-dl360gen10.dts
>>> new file mode 100644
>>> index 000000000000..da5eac1213a8
>>> --- /dev/null
>>> +++ b/arch/arm/boot/dts/hpe-bmc-dl360gen10.dts
>>> @@ -0,0 +1,27 @@
>>> +// SPDX-License-Identifier: GPL-2.0
>>> +/*
>>> + * Device Tree file for HPE DL360Gen10 */
>>> +
>>> +/include/ "hpe-gxp.dtsi"
>>> +
>>> +/ {
>>> + #address-cells = <1>>;
>>> + #size-cells = <1>>;
>>> + compatible = "hpe,gxp";
>
>> Missing board compatible.
>
> Will become compatible = "hpe,gxp","hpe,bmc-dl360gen10"; If that seems okay to you.
Yes, except hpe,gxp goes at the end.
>
>>> + model = "Hewlett Packard Enterprise ProLiant dl360 Gen10";
>>> +
(...)
>>> +
>>> + usb0: usb@cefe0000 {
>>> + compatible = "generic-ehci";
>
>> I think one of previous comments was that you cannot have "generic-ehci"
>> only, right?
>
> Yes there was, I removed the usb0: ehci@cefe0000. I see now that this is in reference to the compatible. This is our ehci controller. What would be a more appropriate compatible? Do we need hpe,gxp-ehci perhaps?
Yes,, see other cases in generic-ehci.yaml bindings. Your current choice
would be pointed out by dtbs_check, that it's invalid according to
current bindings.
>
>>> + reg = <0xcefe0000 0x100>>;
>>> + interrupts = <7>>;
>>> + interrupt-parent = <&vic0>>;
>>> + };
>>> +
>>> + usb1: usb@cefe0100 {
>>> + compatible = "generic-ohci";
>>> + reg = <0xcefe0100 0x110>>;
>>> + interrupts = <6>>;
>>> + interrupt-parent = <&vic0>>;
>>> + };
>>> +
>>> + vrom@58000000 {
>>> + compatible = "mtd-ram";
>>> + bank-width = <4>>;
>>> + reg = <0x58000000 0x4000000>>;
>>> + #address-cells = <1>>;
>>> + #size-cells = <1>>;
>>> + partition@0 {
>>> + label = "vrom-prime";
>>> + reg = <0x0 0x2000000>>;
>>> + };
>>> + partition@2000000 {
>>> + label = "vrom-second";
>>> + reg = <0x2000000 0x2000000>>;
>>> + };
>>> + };
>>> +
>>> + i2cg: syscon@c00000f8 {
>
>
>>> + compatible = "simple-mfd", "syscon";
>>> + reg = <0xc00000f8 0x08>>;
>>> + };
>>> + };
>>> +
>>> + clocks {
>>> + osc: osc {
>
>> Keep node naming consistent, so just "clk"... but it's also very generic comparing to others, so I wonder what is this clock?
>
> We are in the process of redoing the clocks. This was the oscillator but no longer needed for the minimum boot config.
>
>>> + compatible = "fixed-clock";
>>> + #clock-cells = <0>>;
>>> + clock-output-names = "osc";
>>> + clock-frequency = <33333333>>;
>>> + };
>>> +
>>> + iopclk: iopclk {
>>> + compatible = "fixed-clock";
>>> + #clock-cells = <0>>;
>>> + clock-output-names = "iopclk";
>>> + clock-frequency = <400000000>>;
>>> + };
>>> +
>>> + memclk: memclk {
>>> + compatible = "fixed-clock";
>>> + #clock-cells = <0>>;
>>> + clock-output-names = "memclk";
>>> + clock-frequency = <800000000>>;
>>> + };
>
>> What are these clocks? If external to the SoC, then where are they? On the board?
>
> This was the internal iopclk and memclk they were both internal to the chip.
> For now I am removing osc and memclk and will just have an iopclk that Gxp-timer will refer to.
You should rather have a clock controller driver which defines this (and
many others). They can stay as a temporary work-around, if you really
need them for some other nodes.
Best regards,
Krzysztof
next prev parent reply other threads:[~2022-03-16 15:51 UTC|newest]
Thread overview: 50+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-03-10 19:52 [PATCH v3 01/10] arch: arm: mach-hpe: Introduce the HPE GXP architecture nick.hawkins
2022-03-10 19:52 ` [PATCH v3 02/10] arch: arm: configs: multi_v7_defconfig nick.hawkins
2022-03-10 19:52 ` [PATCH v3 03/10] drivers: wdt: Introduce HPE GXP SoC Watchdog nick.hawkins
2022-04-04 14:28 ` Guenter Roeck
2022-04-04 16:25 ` Hawkins, Nick
2022-04-04 16:41 ` Guenter Roeck
2022-03-10 19:52 ` [PATCH v3 04/10] clocksource/drivers: Add HPE GXP timer nick.hawkins
2022-04-06 11:13 ` Daniel Lezcano
2022-04-06 22:02 ` Hawkins, Nick
2022-03-10 19:52 ` [PATCH v3 05/10] dt-bindings: timer: Add HPE GXP Timer Binding nick.hawkins
2022-03-11 9:32 ` Krzysztof Kozlowski
2022-03-11 15:40 ` Rob Herring
2022-03-11 16:22 ` Hawkins, Nick
2022-03-11 17:13 ` Krzysztof Kozlowski
2022-03-10 19:52 ` [PATCH v3 06/10] dt-bindings: watchdog: Add HPE GXP Watchdog timer binding nick.hawkins
2022-03-11 9:34 ` Krzysztof Kozlowski
2022-03-10 19:52 ` [PATCH v3 07/10] dt-bindings: arm: Add HPE GXP Binding nick.hawkins
2022-03-11 10:20 ` Krzysztof Kozlowski
2022-03-10 19:52 ` [PATCH v3 08/10] dt-bindings: arm: Add HPE GXP CPU Init nick.hawkins
2022-03-11 10:22 ` Krzysztof Kozlowski
2022-03-16 21:33 ` Hawkins, Nick
2022-03-10 19:52 ` [PATCH v3 09/10] arch: arm: boot: dts: Introduce HPE GXP Device tree nick.hawkins
2022-03-11 8:17 ` Arnd Bergmann
2022-03-11 10:29 ` Krzysztof Kozlowski
2022-03-16 15:41 ` Hawkins, Nick
2022-03-16 15:50 ` Krzysztof Kozlowski [this message]
2022-03-16 20:10 ` Hawkins, Nick
2022-03-17 8:36 ` Krzysztof Kozlowski
2022-03-29 19:38 ` Hawkins, Nick
2022-03-29 21:13 ` Arnd Bergmann
2022-03-29 21:45 ` Hawkins, Nick
2022-03-30 22:27 ` Hawkins, Nick
2022-03-31 9:30 ` Arnd Bergmann
2022-03-31 21:09 ` Hawkins, Nick
2022-03-31 21:52 ` Arnd Bergmann
2022-04-01 16:05 ` Hawkins, Nick
2022-04-01 16:30 ` Arnd Bergmann
2022-04-04 20:22 ` Hawkins, Nick
2022-04-04 22:02 ` Arnd Bergmann
2022-04-05 21:21 ` Hawkins, Nick
2022-04-06 7:24 ` Arnd Bergmann
2022-04-13 16:48 ` Hawkins, Nick
2022-04-13 17:42 ` Arnd Bergmann
2022-03-10 19:52 ` [PATCH v3 10/10] maintainers: Introduce HPE GXP Architecture nick.hawkins
2022-03-11 10:33 ` Joe Perches
2022-03-11 7:21 ` [PATCH v3 01/10] arch: arm: mach-hpe: Introduce the HPE GXP architecture kernel test robot
2022-03-11 8:06 ` Arnd Bergmann
2022-03-11 12:40 ` kernel test robot
2022-03-12 13:27 ` kernel test robot
2022-03-12 15:14 ` Arnd Bergmann
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=b1cc2566-cd78-7cb4-f8a5-d6fc8065fe6e@canonical.com \
--to=krzysztof.kozlowski@canonical.com \
--cc=arnd@arndb.de \
--cc=devicetree@vger.kernel.org \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=linux-kernel@vger.kernel.org \
--cc=nick.hawkins@hpe.com \
--cc=olof@lixom.net \
--cc=robh+dt@kernel.org \
--cc=soc@kernel.org \
--cc=verdun@hpe.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox
all inboxes | Powered by JetHome®