Received: by 2002:a6b:500f:0:0:0:0:0 with SMTP id e15csp5906895iob; Tue, 10 May 2022 06:29:16 -0700 (PDT) X-Google-Smtp-Source: ABdhPJwiAFsAsZNGavZ62wxk1OHCkedx7A4Ij3dpqQkCAxuvLTM17O1V8Kcj0ueps9yINAejLryc X-Received: by 2002:a05:6402:1c93:b0:428:1818:4fe7 with SMTP id cy19-20020a0564021c9300b0042818184fe7mr22834609edb.129.1652189356723; Tue, 10 May 2022 06:29:16 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1652189356; cv=none; d=google.com; s=arc-20160816; b=C82vY6AfO5VYNOaW7hxXhOWG2f2h8+4+W/igmmKpy7mqjYs4myD3OTcB/QWcDqmdvp kdcoim0WLmHeUOCXm+Ii4rOGzfGMSAfYVmN/AyM6PwEscTJvWNvKdd0GMjNFitSxe9Pk z2jZdwPlmag7Q48csAXgGyr/qKQNjCjvn2gW3lpmyH0p3dplQHsRmeHenh1Yk0wLiHG2 kRJFm6uvzK97kSZrdQMwxOhLC0RWkeOe3t1gP211qUBf2oprCTHt1iTGepfPskLo8BQq fA1H+EZv5PPu/Oxq/oPER4EW/UxsRC/r+MtU79sW+x2zxTNQhm4jqE1394rNafywJFhq 8oqA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:cc:to:subject:message-id:date:from:in-reply-to :references:mime-version:dkim-signature; bh=5NSLtMW8lsWjf+NFgBL7FnQgrCqrvvIapyadPxLxjY8=; b=Vtg0R75MN/VKUq27HaGh9bey8+dgiXGt3s01afLFBPTVa4XTKKzD+nnyPgytBuq8Ag g7aXpEQi7oclBcAxx3f3enItdNfmRIMozuQdEDwZFLjkWcWIb8e2Ve1RK0x6ZCCEfjgo /jQIO8U2d8Sn0/hs7KvBhHw6yAtvdWZqryc003QJI9JVLBotb8yWK8JaB+4YXtj79QyI Hy3idNmpJLy8oq35nmY6Ka+rhH0BI8v2iu1EXz7PeXFqy/P7YATcbuAGL03y9/r+Gvit I5vp4aau7nbcyd2zIont8dEOVlkRyfo1SQkGEvHGbWiFnFRLZbgK1VxeDq/J5flNu4Rh sMsA== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@sartura-hr.20210112.gappssmtp.com header.s=20210112 header.b=ND3nIJ8v; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Return-Path: Received: from out1.vger.email (out1.vger.email. [2620:137:e000::1:20]) by mx.google.com with ESMTP id a4-20020a1709062b0400b006f379f93701si15635469ejg.843.2022.05.10.06.28.47; Tue, 10 May 2022 06:29:16 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20; Authentication-Results: mx.google.com; dkim=pass header.i=@sartura-hr.20210112.gappssmtp.com header.s=20210112 header.b=ND3nIJ8v; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S241159AbiEJLpf (ORCPT + 99 others); Tue, 10 May 2022 07:45:35 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:36224 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S238614AbiEJLpb (ORCPT ); Tue, 10 May 2022 07:45:31 -0400 Received: from mail-io1-xd35.google.com (mail-io1-xd35.google.com [IPv6:2607:f8b0:4864:20::d35]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 96DCA86AE5 for ; Tue, 10 May 2022 04:41:33 -0700 (PDT) Received: by mail-io1-xd35.google.com with SMTP id a10so725835ioe.9 for ; Tue, 10 May 2022 04:41:33 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=sartura-hr.20210112.gappssmtp.com; s=20210112; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=5NSLtMW8lsWjf+NFgBL7FnQgrCqrvvIapyadPxLxjY8=; b=ND3nIJ8vevB929VRK9EErWSYeXoXHet8LCfs2gSBv6Sy7DTnHCuwM9Rz3xKayezbwI 6HMVR7k8CaUCXw4rZVBf2WB7D0M9GDHFAumYPKMOGr+LQ+bE97nTNA7X3VmXPiO3yS3F c3cZG9APXpVlEBavoZ8EG2MYcJD1219+Ddu1Q1lkMYPoh0nNBd+T3EvPDprnzBIiqR+y UJUO5dS/ZoBFUY9ghvIK9ZDh7ACpQQ0INKlyMLcgJNTPaeMXmo454lFN3Cn8A5ekpm/f TJdQzyigoryX9lEcNkG0hbjm3tX9URwDvaFL7VWFjMS5b5Yry4R1/AkCHUopyp9eLo1n U8QA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=5NSLtMW8lsWjf+NFgBL7FnQgrCqrvvIapyadPxLxjY8=; b=WdTbvRy7Reg5NBfsYyNpXsg31bmef8s381oNe3najVRebGWe4JdO6ACWtrvAgZ7nuH MGlBxzF00utsD1WvbYLwegrXTfNgS42V23h02NwjF1/BO3ZH7AxakKaP+P2rPb58uDl3 3rn6ce6V9LkhI7nkT4Xmr7eSCMHo56NeCyZfGsjp/Kp3odptfH/MtZiHMNz/yA9ghZ96 hQ4+VNjq8m6tgT+h/xsqhau6ozC/fDtDB+2P5BsFAWu5FIgsf1tJhYkY72AtpVBBN3g5 h5Y/pdZdN1oFXqj33ahfp9t3NlKC3gDbpsrYc3c17bYIPmHqg2znE/8wrKP3kbNyykvC Da6g== X-Gm-Message-State: AOAM5302OuEJ2mVyVRe2zcKTHpw2uiuxX0aRQajajWs3qqlliq6h7ea7 AwL+p3Zp/iwGOHeKQoiz0b9rIr2i34fcZq9mgR67cw== X-Received: by 2002:a5e:c24c:0:b0:657:a86a:d1b0 with SMTP id w12-20020a5ec24c000000b00657a86ad1b0mr8667800iop.43.1652182892991; Tue, 10 May 2022 04:41:32 -0700 (PDT) MIME-Version: 1.0 References: <20220509110028.144226-1-robert.marko@sartura.hr> <20220509110028.144226-2-robert.marko@sartura.hr> <8e22cbf7-eee1-0ec7-10f9-3839ec80dfbf@linaro.org> In-Reply-To: <8e22cbf7-eee1-0ec7-10f9-3839ec80dfbf@linaro.org> From: Robert Marko Date: Tue, 10 May 2022 13:41:22 +0200 Message-ID: Subject: Re: [PATCH 2/2] arm64: dts: marvell: add support for Methode eDPU To: Krzysztof Kozlowski Cc: Rob Herring , krzysztof.kozlowski+dt@linaro.org, Andrew Lunn , gregory.clement@bootlin.com, sebastian.hesselbarth@gmail.com, shawnguo@kernel.org, Linus Walleij , kostap@marvell.com, devicetree , Linux Kernel Mailing List , Linux ARM , =?UTF-8?Q?Pali_Roh=C3=A1r?= , =?UTF-8?B?TWFyZWsgQmVow7pu?= Content-Type: text/plain; charset="UTF-8" X-Spam-Status: No, score=-1.9 required=5.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,RCVD_IN_DNSWL_NONE,SPF_HELO_NONE,SPF_PASS, T_SCC_BODY_TEXT_LINE,URIBL_BLOCKED autolearn=ham autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on lindbergh.monkeyblade.net Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Tue, May 10, 2022 at 12:20 PM Krzysztof Kozlowski wrote: > > On 09/05/2022 13:00, Robert Marko wrote: > > Methode eDPU is an Armada 3720 powered board based on the Methode uDPU. > > > > They feature the same CPU, RAM, and storage as well as the form factor. > > > > However, eDPU only has one SFP slot plus a copper G.hn port. > > > > In order to reduce duplication, split the uDPU DTS into a common one. > > > > Signed-off-by: Robert Marko > > --- > > arch/arm64/boot/dts/marvell/Makefile | 1 + > > .../boot/dts/marvell/armada-3720-eDPU.dts | 14 ++ > > .../boot/dts/marvell/armada-3720-uDPU.dts | 148 +--------------- > > .../boot/dts/marvell/armada-3720-uDPU.dtsi | 163 ++++++++++++++++++ > > 4 files changed, 179 insertions(+), 147 deletions(-) > > create mode 100644 arch/arm64/boot/dts/marvell/armada-3720-eDPU.dts > > create mode 100644 arch/arm64/boot/dts/marvell/armada-3720-uDPU.dtsi > > > > diff --git a/arch/arm64/boot/dts/marvell/Makefile b/arch/arm64/boot/dts/marvell/Makefile > > index 1c794cdcb8e6..104d7d7e8215 100644 > > --- a/arch/arm64/boot/dts/marvell/Makefile > > +++ b/arch/arm64/boot/dts/marvell/Makefile > > @@ -1,6 +1,7 @@ > > # SPDX-License-Identifier: GPL-2.0 > > # Mvebu SoC Family > > dtb-$(CONFIG_ARCH_MVEBU) += armada-3720-db.dtb > > +dtb-$(CONFIG_ARCH_MVEBU) += armada-3720-eDPU.dtb > > dtb-$(CONFIG_ARCH_MVEBU) += armada-3720-espressobin.dtb > > dtb-$(CONFIG_ARCH_MVEBU) += armada-3720-espressobin-emmc.dtb > > dtb-$(CONFIG_ARCH_MVEBU) += armada-3720-espressobin-ultra.dtb > > diff --git a/arch/arm64/boot/dts/marvell/armada-3720-eDPU.dts b/arch/arm64/boot/dts/marvell/armada-3720-eDPU.dts > > new file mode 100644 > > index 000000000000..6b573a6854cc > > --- /dev/null > > +++ b/arch/arm64/boot/dts/marvell/armada-3720-eDPU.dts > > @@ -0,0 +1,14 @@ > > +// SPDX-License-Identifier: (GPL-2.0+ OR MIT) > > + > > +/dts-v1/; > > + > > +#include "armada-3720-uDPU.dtsi" > > + > > +/ { > > + model = "Methode eDPU Board"; > > + compatible = "methode,edpu", "marvell,armada3720"; > > You need also bindings for the board compatible. Someone should convert > the Documentation/devicetree/bindings/arm/marvell/armada-37xx.txt to YAML. Ok, I can convert the SoC compatibles at least for now. Any advice you can give me on how the handle the Espressobin boards having multiple board-specific compatibles? For example, Espressobin V7 has: "globalscale,espressobin-v7", "globalscale,espressobin" > > > +}; > > +> + sfp_eth1: sfp-eth1 { > > Generic node names, please. Can you give me an example of what would be appropriate here because the SFP bindings example utilizes the same naming scheme as used here? > > > + compatible = "sff,sfp"; > > + i2c-bus = <&i2c1>; > > + los-gpio = <&gpiosb 7 GPIO_ACTIVE_HIGH>; > > + mod-def0-gpio = <&gpiosb 8 GPIO_ACTIVE_LOW>; > > + tx-disable-gpio = <&gpiosb 9 GPIO_ACTIVE_HIGH>; > > + tx-fault-gpio = <&gpiosb 10 GPIO_ACTIVE_HIGH>; > > + maximum-power-milliwatt = <3000>; > > + }; > > +}; > > + > > +&sdhci0 { > > + status = "okay"; > > + bus-width = <8>; > > + mmc-ddr-1_8v; > > + mmc-hs400-1_8v; > > + marvell,pad-type = "fixed-1-8v"; > > + non-removable; > > + no-sd; > > + no-sdio; > > +}; > > + > > +&spi0 { > > + status = "okay"; > > + pinctrl-names = "default"; > > + pinctrl-0 = <&spi_quad_pins>; > > + > > + spi-flash@0 { > > Run dtbs_check and fix the errors. Ok, will split the DTSI and eDPU commits and fixup nodes in between. > > > + compatible = "jedec,spi-nor"; > > + reg = <0>; > > + spi-max-frequency = <54000000>; > > + > > + partitions { > > + compatible = "fixed-partitions"; > > + #address-cells = <1>; > > + #size-cells = <1>; > > + /* only bootloader is located on the SPI */ > > + partition@0 { > > + label = "firmware"; > > + reg = <0x0 0x180000>; > > + }; > > + > > + partition@180000 { > > + label = "u-boot-env"; > > + reg = <0x180000 0x10000>; > > + }; > > + }; > > + }; > > +}; > > + > > +&pinctrl_nb { > > + i2c2_recovery_pins: i2c2-recovery-pins { > > + groups = "i2c2"; > > + function = "gpio"; > > + }; > > +}; > > + > > +&i2c1 { > > + status = "okay"; > > + pinctrl-names = "default", "recovery"; > > + pinctrl-0 = <&i2c2_pins>; > > + pinctrl-1 = <&i2c2_recovery_pins>; > > + /delete-property/mrvl,i2c-fast-mode; > > + scl-gpios = <&gpionb 2 (GPIO_ACTIVE_HIGH | GPIO_OPEN_DRAIN)>; > > + sda-gpios = <&gpionb 3 (GPIO_ACTIVE_HIGH | GPIO_OPEN_DRAIN)>; > > + > > + nct375@48 { > > Generic node names, representing class of a device. Ok, will rename in v2. > > > + status = "okay"; > > OK status is by default, why do you need it? Also, it goes as last property. It's not needed, I have not changed any nodes, they are just copy/paste during the DTS split. Will drop it in v2. Regards, Robert > > > + compatible = "ti,tmp75c"; > > + reg = <0x48>; > > + }; > > + > > + nct375@49 { > > + status = "okay"; > > + compatible = "ti,tmp75c"; > > + reg = <0x49>; > > + }; > > +}; > > + > > +ð0 { > > + status = "okay"; > > + managed = "in-band-status"; > > + phys = <&comphy1 0>; > > +}; > > + > > +ð1 { > > + phy-mode = "sgmii"; > > + status = "okay"; > > + managed = "in-band-status"; > > + phys = <&comphy0 1>; > > + sfp = <&sfp_eth1>; > > +}; > > + > > +&usb3 { > > + status = "okay"; > > + phys = <&usb2_utmi_otg_phy>; > > + phy-names = "usb2-utmi-otg-phy"; > > +}; > > + > > +&uart0 { > > + status = "okay"; > > +}; > > > Best regards, > Krzysztof -- Robert Marko Staff Embedded Linux Engineer Sartura Ltd. Lendavska ulica 16a 10000 Zagreb, Croatia Email: robert.marko@sartura.hr Web: www.sartura.hr