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@huawei.com, mauro.chehab@huawei.com,
Kishon Vijay Abraham I <kishon@ti.com>,
devicetree@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: Sat, 24 Jul 2021 02:12:44 +0200 [thread overview]
Message-ID: <20210724021244.780297ee@coco.lan> (raw)
In-Reply-To: <20210723225059.GA2727093@robh.at.kernel.org>
Em Fri, 23 Jul 2021 16:50:59 -0600
Rob Herring <robh@kernel.org> escreveu:
> On Wed, Jul 21, 2021 at 10:39:08AM +0200, Mauro Carvalho Chehab wrote:
> > Document the bindings for HiKey 970 (hi3670) PCIe PHY
> > interface, supported via the pcie-kirin driver.
> >
> > Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
> > ---
> > .../phy/hisilicon,phy-hi3670-pcie.yaml | 95 +++++++++++++++++++
> > 1 file changed, 95 insertions(+)
> > create mode 100644 Documentation/devicetree/bindings/phy/hisilicon,phy-hi3670-pcie.yaml
> >
> > diff --git a/Documentation/devicetree/bindings/phy/hisilicon,phy-hi3670-pcie.yaml b/Documentation/devicetree/bindings/phy/hisilicon,phy-hi3670-pcie.yaml
> > new file mode 100644
> > index 000000000000..a5ea13332cac
> > --- /dev/null
> > +++ b/Documentation/devicetree/bindings/phy/hisilicon,phy-hi3670-pcie.yaml
> > @@ -0,0 +1,95 @@
> > +# SPDX-License-Identifier: GPL-2.0-only OR BSD-2-Clause
> > +%YAML 1.2
> > +---
> > +$id: http://devicetree.org/schemas/phy/hisilicon,phy-hi3670-pcie.yaml#
> > +$schema: http://devicetree.org/meta-schemas/core.yaml#
> > +
> > +title: HiSilicon Kirin970 PCIe PHY
> > +
> > +maintainers:
> > + - Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
> > +
> > +description: |+
> > + Bindings for PCIe PHY on HiSilicon Kirin 970.
> > +
> > +properties:
> > + compatible:
> > + const: hisilicon,hi970-pcie-phy
> > +
> > + "#phy-cells":
> > + const: 0
> > +
> > + reg:
> > + maxItems: 1
> > + description: PHY Control registers
> > +
> > + phy-supply:
> > + description: The PCIe PHY power supply
> > +
> > + clocks:
> > + items:
> > + - description: PCIe PHY clock
> > + - description: PCIe AUX clock
> > + - description: PCIe APB PHY clock
> > + - description: PCIe APB SYS clock
> > + - description: PCIe ACLK clock
> > +
> > + clock-names:
> > + items:
> > + - const: phy_ref
> > + - const: aux
> > + - const: apb_phy
> > + - const: apb_sys
> > + - const: aclk
> > +
> > + 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?
> It boils down to this fails to describe how the GPIOs are connected
> which is the point of GPIOs in DT. This in no way captures the hierarchy
> of devices. While you may be lucky that you can just assert or
> deassert all the lines at one time, that's not likely to work in a
> more complicated case (such as having to power up/down each device).
There's no way to power up/down each device, as they all share the
same regulator line (LDO33). So, when this is powered on, all PCI
devices are powered at the same time.
The original DT had names for each reset-gpio, but this was just
informative, as the only possible way for this hardware to work is
to send the PERST# signal via all GPIOs at the same time.
Ok, we might overdesign the DT, in order to consider a non-existent
scenario where it would be possible to power on and reset the devices
in separate, but I can't think on a way to do that, except by maybe
creating virtual phy (or pcie) DT nodes, one for each combination of
regulator + PERST#, and have separate drivers for each one. Such kind
of scenario only makes sense when each PCIe device can be powered on
independently (which is not the case here).
If you have a better idea, I'm all ears.
>
> I realize the right solution is more complex, but that's the only way to
> handle this in a host bridge and board independent way.
>
> If you want the simple solution, just configure all these GPIOs in
> firmware before Linux boots.
This won't work. The PERST# signal should be sent after initializing
the PCIe + PHY and powering up the PEX8606 PCIe bridge chipset
(via LDO33). That happens when the PCIe driver is loaded.
Thanks,
Mauro
--
linux-phy mailing list
linux-phy@lists.infradead.org
https://lists.infradead.org/mailman/listinfo/linux-phy
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@huawei.com, mauro.chehab@huawei.com,
Kishon Vijay Abraham I <kishon@ti.com>,
devicetree@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: Sat, 24 Jul 2021 02:12:44 +0200 [thread overview]
Message-ID: <20210724021244.780297ee@coco.lan> (raw)
In-Reply-To: <20210723225059.GA2727093@robh.at.kernel.org>
Em Fri, 23 Jul 2021 16:50:59 -0600
Rob Herring <robh@kernel.org> escreveu:
> On Wed, Jul 21, 2021 at 10:39:08AM +0200, Mauro Carvalho Chehab wrote:
> > Document the bindings for HiKey 970 (hi3670) PCIe PHY
> > interface, supported via the pcie-kirin driver.
> >
> > Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
> > ---
> > .../phy/hisilicon,phy-hi3670-pcie.yaml | 95 +++++++++++++++++++
> > 1 file changed, 95 insertions(+)
> > create mode 100644 Documentation/devicetree/bindings/phy/hisilicon,phy-hi3670-pcie.yaml
> >
> > diff --git a/Documentation/devicetree/bindings/phy/hisilicon,phy-hi3670-pcie.yaml b/Documentation/devicetree/bindings/phy/hisilicon,phy-hi3670-pcie.yaml
> > new file mode 100644
> > index 000000000000..a5ea13332cac
> > --- /dev/null
> > +++ b/Documentation/devicetree/bindings/phy/hisilicon,phy-hi3670-pcie.yaml
> > @@ -0,0 +1,95 @@
> > +# SPDX-License-Identifier: GPL-2.0-only OR BSD-2-Clause
> > +%YAML 1.2
> > +---
> > +$id: http://devicetree.org/schemas/phy/hisilicon,phy-hi3670-pcie.yaml#
> > +$schema: http://devicetree.org/meta-schemas/core.yaml#
> > +
> > +title: HiSilicon Kirin970 PCIe PHY
> > +
> > +maintainers:
> > + - Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
> > +
> > +description: |+
> > + Bindings for PCIe PHY on HiSilicon Kirin 970.
> > +
> > +properties:
> > + compatible:
> > + const: hisilicon,hi970-pcie-phy
> > +
> > + "#phy-cells":
> > + const: 0
> > +
> > + reg:
> > + maxItems: 1
> > + description: PHY Control registers
> > +
> > + phy-supply:
> > + description: The PCIe PHY power supply
> > +
> > + clocks:
> > + items:
> > + - description: PCIe PHY clock
> > + - description: PCIe AUX clock
> > + - description: PCIe APB PHY clock
> > + - description: PCIe APB SYS clock
> > + - description: PCIe ACLK clock
> > +
> > + clock-names:
> > + items:
> > + - const: phy_ref
> > + - const: aux
> > + - const: apb_phy
> > + - const: apb_sys
> > + - const: aclk
> > +
> > + 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?
> It boils down to this fails to describe how the GPIOs are connected
> which is the point of GPIOs in DT. This in no way captures the hierarchy
> of devices. While you may be lucky that you can just assert or
> deassert all the lines at one time, that's not likely to work in a
> more complicated case (such as having to power up/down each device).
There's no way to power up/down each device, as they all share the
same regulator line (LDO33). So, when this is powered on, all PCI
devices are powered at the same time.
The original DT had names for each reset-gpio, but this was just
informative, as the only possible way for this hardware to work is
to send the PERST# signal via all GPIOs at the same time.
Ok, we might overdesign the DT, in order to consider a non-existent
scenario where it would be possible to power on and reset the devices
in separate, but I can't think on a way to do that, except by maybe
creating virtual phy (or pcie) DT nodes, one for each combination of
regulator + PERST#, and have separate drivers for each one. Such kind
of scenario only makes sense when each PCIe device can be powered on
independently (which is not the case here).
If you have a better idea, I'm all ears.
>
> I realize the right solution is more complex, but that's the only way to
> handle this in a host bridge and board independent way.
>
> If you want the simple solution, just configure all these GPIOs in
> firmware before Linux boots.
This won't work. The PERST# signal should be sent after initializing
the PCIe + PHY and powering up the PEX8606 PCIe bridge chipset
(via LDO33). That happens when the PCIe driver is loaded.
Thanks,
Mauro
next prev parent reply other threads:[~2021-07-24 0:12 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 [this message]
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
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=20210724021244.780297ee@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: 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.