From: Mauro Carvalho Chehab <mchehab+huawei@kernel.org> To: Rob Herring <robh@kernel.org> Cc: Vinod Koul <vkoul@kernel.org>, Bjorn Helgaas <bhelgaas@google.com>, Linuxarm <linuxarm@huawei.com>, mauro.chehab@huawei.com, Kishon Vijay Abraham I <kishon@ti.com>, devicetree@vger.kernel.org, "linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>, linux-phy@lists.infradead.org Subject: Re: [PATCH v7 06/10] dt-bindings: phy: Add bindings for HiKey 970 PCIe PHY Date: Tue, 27 Jul 2021 08:52:05 +0200 [thread overview] Message-ID: <20210727085205.5aafb5c9@coco.lan> (raw) In-Reply-To: <20210727015020.403bbf73@coco.lan> Em Tue, 27 Jul 2021 01:50:20 +0200 Mauro Carvalho Chehab <mchehab+huawei@kernel.org> escreveu: > Em Mon, 26 Jul 2021 15:37:28 -0600 > Rob Herring <robh@kernel.org> escreveu: > > > > > > + reset-gpios: > > > > > + description: PCI PERST reset GPIOs > > > > > + maxItems: 4 > > > > > + > > > > > + clkreq-gpios: > > > > > + description: Clock request GPIOs > > > > > + maxItems: 3 > > > > > > > > Again, this will not work. > > > > > > Just to be sure: you're talking about the PERST# gpios (e. g. reset-gpios) > > > here, right? > > > > Both that and CLKREQ. The original DT from the downstream version (found at Linaro's tree) has: pcie@f4000000 { compatible = "hisilicon,hikey970"; ... switch,reset-gpios = <&gpio7 0 0 >; eth,reset-gpios = <&gpio25 2 0 >; m_2,reset-gpios = <&gpio3 1 0 >; mini1,reset-gpios = <&gpio27 4 0 >; eth,clkreq-gpios = <&gpio20 6 0 >; m_2,clkreq-gpios = <&gpio27 3 0 >; mini1,clkreq-gpios = <&gpio17 0 0 >; }; So, if we're willing to have a single reset-gpios for the PCIe interface, in order to follow the current pci-bus.yaml schema, this would probably be: reset-gpios = <&gpio7 0 0 >; which maps to the PEX8606 PCIe bridge chip. With that, DT still need to point a per-slot clkreq and reset-gpio. One alternative would be to map it as either 3 PCI or PHY child nodes. E. g. something like this: pcie@f4000000 { compatible = "hisilicon,kirin970-pcie"; ... reset-gpios = <&gpio7 0 0 >; slot { eth { reset-gpios = <&gpio25 2 0>; clkreq-gpios = <&gpio20 6 0>; }; m2 { reset-gpios = <&gpio3 1 0>; clkreq-gpios = <&gpio27 3 0>; }; mini1 { reset-gpios = <&gpio27 4 0>; clkreq-gpios = <&gpio17 0 0>; }; }; }; Placing the child nodes ("slot"?) at the pci bus properties makes more sense to me, but placing them at the PHY node has the advantage of only affecting Kirin 970. In either case, if each child would need a different power supply, it won't be hard to add a "slot-supply" property later on. Would something like that be acceptable for you? > > > If you have a better idea, I'm all ears. > > > > There's already a spec for populating PCI devices in DT. It's existed > > for over 20 years with OpenFirmware[1]. It's not widely used on FDT > > systems because most cases to date are just a single device attached > > and they don't have extra things needing to be described in DT. There > > are a few, but not many examples in the tree of PCI devices with DT > > nodes. That's the only way to generically describe the topology you > > have. > > > > [1] https://www.devicetree.org/open-firmware/home.html#OFDbussupps I was unable to find anything useful there at the two PCI documents. This one: https://www.devicetree.org/open-firmware/bindings/pci/pci-express.txt has just one property that might be useful: physical-slot# The main one: https://www.devicetree.org/open-firmware/bindings/pci/pci2_1.pdf mentions a few child properties, but it doesn't show how those were supposed to be mapped, and none of the properties mentioned there specify clocks, gpios, or reset pins. Thanks, Mauro
WARNING: multiple messages have this Message-ID (diff)
From: Mauro Carvalho Chehab <mchehab+huawei@kernel.org> To: Rob Herring <robh@kernel.org> Cc: Vinod Koul <vkoul@kernel.org>, Bjorn Helgaas <bhelgaas@google.com>, Linuxarm <linuxarm@huawei.com>, mauro.chehab@huawei.com, Kishon Vijay Abraham I <kishon@ti.com>, devicetree@vger.kernel.org, "linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>, linux-phy@lists.infradead.org Subject: Re: [PATCH v7 06/10] dt-bindings: phy: Add bindings for HiKey 970 PCIe PHY Date: Tue, 27 Jul 2021 08:52:05 +0200 [thread overview] Message-ID: <20210727085205.5aafb5c9@coco.lan> (raw) In-Reply-To: <20210727015020.403bbf73@coco.lan> Em Tue, 27 Jul 2021 01:50:20 +0200 Mauro Carvalho Chehab <mchehab+huawei@kernel.org> escreveu: > Em Mon, 26 Jul 2021 15:37:28 -0600 > Rob Herring <robh@kernel.org> escreveu: > > > > > > + reset-gpios: > > > > > + description: PCI PERST reset GPIOs > > > > > + maxItems: 4 > > > > > + > > > > > + clkreq-gpios: > > > > > + description: Clock request GPIOs > > > > > + maxItems: 3 > > > > > > > > Again, this will not work. > > > > > > Just to be sure: you're talking about the PERST# gpios (e. g. reset-gpios) > > > here, right? > > > > Both that and CLKREQ. The original DT from the downstream version (found at Linaro's tree) has: pcie@f4000000 { compatible = "hisilicon,hikey970"; ... switch,reset-gpios = <&gpio7 0 0 >; eth,reset-gpios = <&gpio25 2 0 >; m_2,reset-gpios = <&gpio3 1 0 >; mini1,reset-gpios = <&gpio27 4 0 >; eth,clkreq-gpios = <&gpio20 6 0 >; m_2,clkreq-gpios = <&gpio27 3 0 >; mini1,clkreq-gpios = <&gpio17 0 0 >; }; So, if we're willing to have a single reset-gpios for the PCIe interface, in order to follow the current pci-bus.yaml schema, this would probably be: reset-gpios = <&gpio7 0 0 >; which maps to the PEX8606 PCIe bridge chip. With that, DT still need to point a per-slot clkreq and reset-gpio. One alternative would be to map it as either 3 PCI or PHY child nodes. E. g. something like this: pcie@f4000000 { compatible = "hisilicon,kirin970-pcie"; ... reset-gpios = <&gpio7 0 0 >; slot { eth { reset-gpios = <&gpio25 2 0>; clkreq-gpios = <&gpio20 6 0>; }; m2 { reset-gpios = <&gpio3 1 0>; clkreq-gpios = <&gpio27 3 0>; }; mini1 { reset-gpios = <&gpio27 4 0>; clkreq-gpios = <&gpio17 0 0>; }; }; }; Placing the child nodes ("slot"?) at the pci bus properties makes more sense to me, but placing them at the PHY node has the advantage of only affecting Kirin 970. In either case, if each child would need a different power supply, it won't be hard to add a "slot-supply" property later on. Would something like that be acceptable for you? > > > If you have a better idea, I'm all ears. > > > > There's already a spec for populating PCI devices in DT. It's existed > > for over 20 years with OpenFirmware[1]. It's not widely used on FDT > > systems because most cases to date are just a single device attached > > and they don't have extra things needing to be described in DT. There > > are a few, but not many examples in the tree of PCI devices with DT > > nodes. That's the only way to generically describe the topology you > > have. > > > > [1] https://www.devicetree.org/open-firmware/home.html#OFDbussupps I was unable to find anything useful there at the two PCI documents. This one: https://www.devicetree.org/open-firmware/bindings/pci/pci-express.txt has just one property that might be useful: physical-slot# The main one: https://www.devicetree.org/open-firmware/bindings/pci/pci2_1.pdf mentions a few child properties, but it doesn't show how those were supposed to be mapped, and none of the properties mentioned there specify clocks, gpios, or reset pins. Thanks, Mauro -- linux-phy mailing list linux-phy@lists.infradead.org https://lists.infradead.org/mailman/listinfo/linux-phy
next prev parent reply other threads:[~2021-07-27 6:52 UTC|newest] Thread overview: 50+ messages / expand[flat|nested] mbox.gz Atom feed top 2021-07-21 8:39 [PATCH v7 00/10] Add support for Hikey 970 PCIe Mauro Carvalho Chehab 2021-07-21 8:39 ` Mauro Carvalho Chehab 2021-07-21 8:39 ` Mauro Carvalho Chehab 2021-07-21 8:39 ` [PATCH v7 01/10] PCI: kirin: Reorganize the PHY logic inside the driver Mauro Carvalho Chehab 2021-07-21 8:39 ` [PATCH v7 02/10] PCI: kirin: Add support for a PHY layer Mauro Carvalho Chehab 2021-07-21 8:39 ` [PATCH v7 03/10] PCI: kirin: Use regmap for APB registers Mauro Carvalho Chehab 2021-07-21 8:39 ` [PATCH v7 04/10] PCI: kirin: Add MODULE_* macros Mauro Carvalho Chehab 2021-07-21 8:39 ` [PATCH v7 05/10] dt-bindings: PCI: kirin: Fix compatible string Mauro Carvalho Chehab 2021-07-21 8:39 ` [PATCH v7 06/10] dt-bindings: phy: Add bindings for HiKey 970 PCIe PHY Mauro Carvalho Chehab 2021-07-21 8:39 ` Mauro Carvalho Chehab 2021-07-23 22:50 ` Rob Herring 2021-07-23 22:50 ` Rob Herring 2021-07-24 0:12 ` Mauro Carvalho Chehab 2021-07-24 0:12 ` Mauro Carvalho Chehab 2021-07-26 21:37 ` Rob Herring 2021-07-26 21:37 ` Rob Herring 2021-07-26 23:50 ` Mauro Carvalho Chehab 2021-07-26 23:50 ` Mauro Carvalho Chehab 2021-07-27 6:52 ` Mauro Carvalho Chehab [this message] 2021-07-27 6:52 ` Mauro Carvalho Chehab 2021-07-27 22:17 ` Rob Herring 2021-07-27 22:17 ` Rob Herring 2021-07-28 7:38 ` Mauro Carvalho Chehab 2021-07-28 7:38 ` Mauro Carvalho Chehab 2021-07-28 14:28 ` Rob Herring 2021-07-28 14:28 ` Rob Herring 2021-07-29 10:12 ` Mauro Carvalho Chehab 2021-07-29 10:12 ` Mauro Carvalho Chehab 2021-07-21 8:39 ` [PATCH v7 07/10] phy: HiSilicon: Add driver for Kirin " Mauro Carvalho Chehab 2021-07-21 8:39 ` Mauro Carvalho Chehab 2021-07-21 8:39 ` [PATCH v7 08/10] arm64: dts: HiSilicon: Add support for HiKey 970 PCIe controller hardware Mauro Carvalho Chehab 2021-07-21 8:39 ` Mauro Carvalho Chehab 2021-07-22 13:36 ` Manivannan Sadhasivam 2021-07-22 13:36 ` Manivannan Sadhasivam 2021-07-23 6:53 ` Mauro Carvalho Chehab 2021-07-23 6:53 ` Mauro Carvalho Chehab 2021-07-24 4:11 ` Manivannan Sadhasivam 2021-07-24 4:11 ` Manivannan Sadhasivam 2021-08-03 4:25 ` Mauro Carvalho Chehab 2021-08-03 4:25 ` Mauro Carvalho Chehab 2021-08-16 18:26 ` Rob Herring 2021-08-16 18:26 ` Rob Herring 2021-07-21 8:39 ` [PATCH v7 09/10] dt-bindings: PCI: kirin-pcie.txt: Convert it to yaml Mauro Carvalho Chehab 2021-07-23 22:56 ` Rob Herring 2021-07-21 8:39 ` [PATCH v7 10/10] phy-hi3670-pcie: Move reset-gpios to the PCIe DT schema Mauro Carvalho Chehab 2021-07-21 8:39 ` Mauro Carvalho Chehab 2021-07-21 8:39 ` Mauro Carvalho Chehab 2021-07-21 10:15 ` [PATCH v7 11/10] PCI: kirin: Allow building it as a module Mauro Carvalho Chehab 2021-07-21 11:55 ` Arnd Bergmann 2021-07-21 13:10 ` Mauro Carvalho Chehab
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=20210727085205.5aafb5c9@coco.lan \ --to=mchehab+huawei@kernel.org \ --cc=bhelgaas@google.com \ --cc=devicetree@vger.kernel.org \ --cc=kishon@ti.com \ --cc=linux-kernel@vger.kernel.org \ --cc=linux-phy@lists.infradead.org \ --cc=linuxarm@huawei.com \ --cc=mauro.chehab@huawei.com \ --cc=robh@kernel.org \ --cc=vkoul@kernel.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: linkBe 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.