All of lore.kernel.org
 help / color / mirror / Atom feed
From: Rob Herring <robh@kernel.org>
To: Jim Quinlan <jim2101024@gmail.com>
Cc: Mark Brown <broonie@kernel.org>,
	linux-pci <linux-pci@vger.kernel.org>,
	Nicolas Saenz Julienne <nsaenzjulienne@suse.de>,
	bcm-kernel-feedback-list <bcm-kernel-feedback-list@broadcom.com>,
	Jim Quinlan <james.quinlan@broadcom.com>,
	Florian Fainelli <f.fainelli@gmail.com>,
	Bjorn Helgaas <bhelgaas@google.com>,
	"moderated list:BROADCOM BCM2711/BCM2835 ARM ARCHITECTURE" 
	<linux-rpi-kernel@lists.infradead.org>,
	"moderated list:BROADCOM BCM2711/BCM2835 ARM ARCHITECTURE" 
	<linux-arm-kernel@lists.infradead.org>,
	"open list:OPEN FIRMWARE AND FLATTENED DEVICE TREE BINDINGS" 
	<devicetree@vger.kernel.org>,
	open list <linux-kernel@vger.kernel.org>
Subject: Re: [PATCH v4 2/6] dt-bindings: PCI: Add bindings for Brcmstb endpoint device voltage regulators
Date: Thu, 8 Apr 2021 12:55:38 -0500	[thread overview]
Message-ID: <20210408175538.GA1688320@robh.at.kernel.org> (raw)
In-Reply-To: <CANCKTBv_g9FPcBCOi-JxEDrrQWFhNcdsfDATFBydwnLiebj-HA@mail.gmail.com>

On Thu, Apr 08, 2021 at 12:58:05PM -0400, Jim Quinlan wrote:
> On Thu, Apr 8, 2021 at 12:20 PM Rob Herring <robh@kernel.org> wrote:
> >
> > On Tue, Apr 06, 2021 at 02:25:49PM -0400, Jim Quinlan wrote:
> > > On Tue, Apr 6, 2021 at 1:32 PM Mark Brown <broonie@kernel.org> wrote:
> > > >
> > > > On Tue, Apr 06, 2021 at 01:26:51PM -0400, Jim Quinlan wrote:
> > > > > On Tue, Apr 6, 2021 at 12:47 PM Mark Brown <broonie@kernel.org> wrote:
> > > >
> > > > > > No great problem with having these in the controller node (assming it
> > > > > > accurately describes the hardware) but I do think we ought to also be
> > > > > > able to describe these per slot.
> >
> > PCIe is effectively point to point, so there's only 1 slot unless
> > there's a PCIe switch in the middle. If that's the case, then it's all
> > more complicated.
> >
> > > > > Can you explain what you think that would look like in the DT?
> > > >
> > > > I *think* that's just some properties on the nodes for the endpoints,
> > > > note that the driver could just ignore them for now.  Not sure where or
> > > > if we document any extensions but child nodes are in section 4 of the
> > > > v2.1 PCI bus binding.
> > >
> > > Hi Mark,
> > >
> > > I'm a little confused -- here is how I remember the chronology of the
> > > "DT bindings" commit reviews, please correct me if I'm wrong:
> > >
> > > o JimQ submitted a pullreq for using voltage regulators in the same
> > > style as the existing "rockport" PCIe driver.
> > > o After some deliberation, RobH preferred that the voltage regulators
> > > should go into the PCIe subnode device's DT node.
> >
> > IIRC, that's because you said there isn't a standard slot.
> Admittedly, I'm not exactly sure what you mean by a "standard slot".
> Our PCIIe HW does not support  hotplug or have a presence bit or
> anything like that.  Our root complex has one port; it can only
> directly connect to a single switch or endpoint. This connection shows
> up as slot0.  The voltage regulator(s) involved depend on a GPIO that
> turns the power  on/off for the connected device/chip.  The gpio pin
> can vary from board to board but this is easily handled in our DT.
> Some boards have regulators that are always on and not associated with
> a GPIO pin -- these have no representation in our DT.

By standard slot, I mean you have standard voltage rails 12V and 3.3V 
(or 1.5 and 3.3 for mini PCIe) and PERST# signal, no other extra 
things to make a device discoverable, and the timing for 
those rails and PERST# follow what the spec defines.

There's also CLKREQ, WAKE, and hotplug detect signals, but I think those 
are all optional and could be tied off. I think most PCI h/w is not 
hotplug capable.

Rob

WARNING: multiple messages have this Message-ID (diff)
From: Rob Herring <robh@kernel.org>
To: Jim Quinlan <jim2101024@gmail.com>
Cc: Mark Brown <broonie@kernel.org>,
	linux-pci <linux-pci@vger.kernel.org>,
	Nicolas Saenz Julienne <nsaenzjulienne@suse.de>,
	bcm-kernel-feedback-list <bcm-kernel-feedback-list@broadcom.com>,
	Jim Quinlan <james.quinlan@broadcom.com>,
	Florian Fainelli <f.fainelli@gmail.com>,
	Bjorn Helgaas <bhelgaas@google.com>,
	"moderated list:BROADCOM BCM2711/BCM2835 ARM ARCHITECTURE"
	<linux-rpi-kernel@lists.infradead.org>,
	"moderated list:BROADCOM BCM2711/BCM2835 ARM ARCHITECTURE"
	<linux-arm-kernel@lists.infradead.org>,
	"open list:OPEN FIRMWARE AND FLATTENED DEVICE TREE BINDINGS"
	<devicetree@vger.kernel.org>,
	open list <linux-kernel@vger.kernel.org>
Subject: Re: [PATCH v4 2/6] dt-bindings: PCI: Add bindings for Brcmstb endpoint device voltage regulators
Date: Thu, 8 Apr 2021 12:55:38 -0500	[thread overview]
Message-ID: <20210408175538.GA1688320@robh.at.kernel.org> (raw)
In-Reply-To: <CANCKTBv_g9FPcBCOi-JxEDrrQWFhNcdsfDATFBydwnLiebj-HA@mail.gmail.com>

On Thu, Apr 08, 2021 at 12:58:05PM -0400, Jim Quinlan wrote:
> On Thu, Apr 8, 2021 at 12:20 PM Rob Herring <robh@kernel.org> wrote:
> >
> > On Tue, Apr 06, 2021 at 02:25:49PM -0400, Jim Quinlan wrote:
> > > On Tue, Apr 6, 2021 at 1:32 PM Mark Brown <broonie@kernel.org> wrote:
> > > >
> > > > On Tue, Apr 06, 2021 at 01:26:51PM -0400, Jim Quinlan wrote:
> > > > > On Tue, Apr 6, 2021 at 12:47 PM Mark Brown <broonie@kernel.org> wrote:
> > > >
> > > > > > No great problem with having these in the controller node (assming it
> > > > > > accurately describes the hardware) but I do think we ought to also be
> > > > > > able to describe these per slot.
> >
> > PCIe is effectively point to point, so there's only 1 slot unless
> > there's a PCIe switch in the middle. If that's the case, then it's all
> > more complicated.
> >
> > > > > Can you explain what you think that would look like in the DT?
> > > >
> > > > I *think* that's just some properties on the nodes for the endpoints,
> > > > note that the driver could just ignore them for now.  Not sure where or
> > > > if we document any extensions but child nodes are in section 4 of the
> > > > v2.1 PCI bus binding.
> > >
> > > Hi Mark,
> > >
> > > I'm a little confused -- here is how I remember the chronology of the
> > > "DT bindings" commit reviews, please correct me if I'm wrong:
> > >
> > > o JimQ submitted a pullreq for using voltage regulators in the same
> > > style as the existing "rockport" PCIe driver.
> > > o After some deliberation, RobH preferred that the voltage regulators
> > > should go into the PCIe subnode device's DT node.
> >
> > IIRC, that's because you said there isn't a standard slot.
> Admittedly, I'm not exactly sure what you mean by a "standard slot".
> Our PCIIe HW does not support  hotplug or have a presence bit or
> anything like that.  Our root complex has one port; it can only
> directly connect to a single switch or endpoint. This connection shows
> up as slot0.  The voltage regulator(s) involved depend on a GPIO that
> turns the power  on/off for the connected device/chip.  The gpio pin
> can vary from board to board but this is easily handled in our DT.
> Some boards have regulators that are always on and not associated with
> a GPIO pin -- these have no representation in our DT.

By standard slot, I mean you have standard voltage rails 12V and 3.3V 
(or 1.5 and 3.3 for mini PCIe) and PERST# signal, no other extra 
things to make a device discoverable, and the timing for 
those rails and PERST# follow what the spec defines.

There's also CLKREQ, WAKE, and hotplug detect signals, but I think those 
are all optional and could be tied off. I think most PCI h/w is not 
hotplug capable.

Rob

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

  reply	other threads:[~2021-04-08 17:55 UTC|newest]

Thread overview: 46+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-04-01 21:21 [PATCH v4 0/6] PCI: brcmstb: add slot0 device regulators and panic handler Jim Quinlan
2021-04-01 21:21 ` Jim Quinlan
2021-04-01 21:21 ` [PATCH v4 1/6] PCI: brcmstb: Check return value of clk_prepare_enable() Jim Quinlan
2021-04-01 21:21   ` Jim Quinlan
2021-04-01 21:21 ` [PATCH v4 2/6] dt-bindings: PCI: Add bindings for Brcmstb endpoint device voltage regulators Jim Quinlan
2021-04-01 21:21   ` Jim Quinlan
2021-04-06 16:47   ` Mark Brown
2021-04-06 16:47     ` Mark Brown
2021-04-06 17:26     ` Jim Quinlan
2021-04-06 17:26       ` Jim Quinlan
2021-04-06 17:32       ` Mark Brown
2021-04-06 17:32         ` Mark Brown
2021-04-06 18:25         ` Jim Quinlan
2021-04-06 18:25           ` Jim Quinlan
2021-04-07 11:27           ` Mark Brown
2021-04-07 11:27             ` Mark Brown
2021-04-07 18:35             ` Florian Fainelli
2021-04-07 18:35               ` Florian Fainelli
2021-04-07 20:07               ` Mark Brown
2021-04-07 20:07                 ` Mark Brown
2021-04-08 16:20           ` Rob Herring
2021-04-08 16:20             ` Rob Herring
2021-04-08 16:33             ` Mark Brown
2021-04-08 16:33               ` Mark Brown
2021-04-08 16:58             ` Jim Quinlan
2021-04-08 16:58               ` Jim Quinlan
2021-04-08 17:55               ` Rob Herring [this message]
2021-04-08 17:55                 ` Rob Herring
2021-04-08 17:41     ` Rob Herring
2021-04-08 17:41       ` Rob Herring
2021-04-01 21:21 ` [PATCH v4 3/6] PCI: brcmstb: Add control of slot0 " Jim Quinlan
2021-04-01 21:21   ` Jim Quinlan
2021-04-06 16:34   ` Mark Brown
2021-04-06 16:34     ` Mark Brown
2021-04-06 16:59     ` Jim Quinlan
2021-04-06 16:59       ` Jim Quinlan
2021-04-06 17:23       ` Mark Brown
2021-04-06 17:23         ` Mark Brown
2021-04-06 17:29         ` Jim Quinlan
2021-04-06 17:29           ` Jim Quinlan
2021-04-01 21:21 ` [PATCH v4 4/6] PCI: brcmstb: Do not turn off regulators if EP can wake up Jim Quinlan
2021-04-01 21:21   ` Jim Quinlan
2021-04-01 21:21 ` [PATCH v4 5/6] PCI: brcmstb: Give 7216 SOCs their own config type Jim Quinlan
2021-04-01 21:21   ` Jim Quinlan
2021-04-01 21:21 ` [PATCH v4 6/6] PCI: brcmstb: Add panic/die handler to RC driver Jim Quinlan
2021-04-01 21:21   ` Jim Quinlan

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=20210408175538.GA1688320@robh.at.kernel.org \
    --to=robh@kernel.org \
    --cc=bcm-kernel-feedback-list@broadcom.com \
    --cc=bhelgaas@google.com \
    --cc=broonie@kernel.org \
    --cc=devicetree@vger.kernel.org \
    --cc=f.fainelli@gmail.com \
    --cc=james.quinlan@broadcom.com \
    --cc=jim2101024@gmail.com \
    --cc=linux-arm-kernel@lists.infradead.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-pci@vger.kernel.org \
    --cc=linux-rpi-kernel@lists.infradead.org \
    --cc=nsaenzjulienne@suse.de \
    /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.