This property specifies slot power limit in mW unit. It is form-factor and
board specific value and must be initialized by hardware.
Some PCIe controllers delegates this work to software to allow hardware
flexibility and therefore this property basically specifies what should
host bridge programs into PCIe Slot Capabilities registers.
Property needs to be specified in mW unit, and not in special format
defined by Slot Capabilities (which encodes scaling factor or different
unit). Host drivers should convert value from mW unit to their format.
Signed-off-by: Pali Rohár <[email protected]>
---
Documentation/devicetree/bindings/pci/pci.txt | 6 ++++++
1 file changed, 6 insertions(+)
diff --git a/Documentation/devicetree/bindings/pci/pci.txt b/Documentation/devicetree/bindings/pci/pci.txt
index 6a8f2874a24d..e67d5db21514 100644
--- a/Documentation/devicetree/bindings/pci/pci.txt
+++ b/Documentation/devicetree/bindings/pci/pci.txt
@@ -32,6 +32,12 @@ driver implementation may support the following properties:
root port to downstream device and host bridge drivers can do programming
which depends on CLKREQ signal existence. For example, programming root port
not to advertise ASPM L1 Sub-States support if there is no CLKREQ signal.
+- slot-power-limit:
+ If present this property specifies slot power limit in mW unit. Host drivers
+ can parse this slot power limit and use it for programming Root Port or host
+ bridge, or for composing and sending PCIe Set_Slot_Power_Limit message
+ through the Root Port or host bridge when transitioning PCIe link from a
+ non-DL_Up Status to a DL_Up Status.
PCI-PCI Bridge properties
-------------------------
--
2.20.1
On Fri, 20 Aug 2021 18:00:21 +0200
Pali Rohár <[email protected]> wrote:
> This property specifies slot power limit in mW unit. It is form-factor and
> board specific value and must be initialized by hardware.
>
> Some PCIe controllers delegates this work to software to allow hardware
> flexibility and therefore this property basically specifies what should
> host bridge programs into PCIe Slot Capabilities registers.
>
> Property needs to be specified in mW unit, and not in special format
> defined by Slot Capabilities (which encodes scaling factor or different
> unit). Host drivers should convert value from mW unit to their format.
>
> Signed-off-by: Pali Rohár <[email protected]>
> ---
> Documentation/devicetree/bindings/pci/pci.txt | 6 ++++++
> 1 file changed, 6 insertions(+)
>
> diff --git a/Documentation/devicetree/bindings/pci/pci.txt b/Documentation/devicetree/bindings/pci/pci.txt
> index 6a8f2874a24d..e67d5db21514 100644
> --- a/Documentation/devicetree/bindings/pci/pci.txt
> +++ b/Documentation/devicetree/bindings/pci/pci.txt
> @@ -32,6 +32,12 @@ driver implementation may support the following properties:
> root port to downstream device and host bridge drivers can do programming
> which depends on CLKREQ signal existence. For example, programming root port
> not to advertise ASPM L1 Sub-States support if there is no CLKREQ signal.
> +- slot-power-limit:
> + If present this property specifies slot power limit in mW unit. Host drivers
> + can parse this slot power limit and use it for programming Root Port or host
> + bridge, or for composing and sending PCIe Set_Slot_Power_Limit message
> + through the Root Port or host bridge when transitioning PCIe link from a
> + non-DL_Up Status to a DL_Up Status.
>
> PCI-PCI Bridge properties
> -------------------------
SFP uses something similar for maximum power, but since the units are
in milliwatt, the name of the property is maximum-power-milliwatt, to
avoid problems. I think it should be done here as well, i.e.
slot-maximum-power-milliwatt
or maybe even
maximum-power-milliwatt.
Marek
On Fri, Aug 20, 2021 at 06:00:21PM +0200, Pali Roh?r wrote:
> This property specifies slot power limit in mW unit. It is form-factor and
> board specific value and must be initialized by hardware.
>
> Some PCIe controllers delegates this work to software to allow hardware
> flexibility and therefore this property basically specifies what should
> host bridge programs into PCIe Slot Capabilities registers.
>
> Property needs to be specified in mW unit, and not in special format
> defined by Slot Capabilities (which encodes scaling factor or different
> unit). Host drivers should convert value from mW unit to their format.
>
> Signed-off-by: Pali Roh?r <[email protected]>
> ---
> Documentation/devicetree/bindings/pci/pci.txt | 6 ++++++
> 1 file changed, 6 insertions(+)
This needs to be in dtschema schemas/pci/pci-bus.yaml instead.
(pci.txt is still here because it needs to be relicensed to move all the
descriptions to pci-bus.yaml.)
>
> diff --git a/Documentation/devicetree/bindings/pci/pci.txt b/Documentation/devicetree/bindings/pci/pci.txt
> index 6a8f2874a24d..e67d5db21514 100644
> --- a/Documentation/devicetree/bindings/pci/pci.txt
> +++ b/Documentation/devicetree/bindings/pci/pci.txt
> @@ -32,6 +32,12 @@ driver implementation may support the following properties:
> root port to downstream device and host bridge drivers can do programming
> which depends on CLKREQ signal existence. For example, programming root port
> not to advertise ASPM L1 Sub-States support if there is no CLKREQ signal.
> +- slot-power-limit:
> + If present this property specifies slot power limit in mW unit. Host drivers
As mentioned, this should have a unit suffix. I'm not sure it is
beneficial to share with SFP in this case though.
> + can parse this slot power limit and use it for programming Root Port or host
> + bridge, or for composing and sending PCIe Set_Slot_Power_Limit message
> + through the Root Port or host bridge when transitioning PCIe link from a
> + non-DL_Up Status to a DL_Up Status.
I no nothing about how this mechanism works, but I think this belongs in
the next section as for PCIe, a slot is always below a PCI-PCI bridge.
If we have N slots, then there's N bridges and needs to be N
slot-power-limit properties, right?
(The same is probably true for all the properties here except
linux,pci-domain.) There's no distinction between host and PCI bridges
in pci-bus.yaml though.
Rob
On Tuesday 24 August 2021 10:35:34 Rob Herring wrote:
> On Fri, Aug 20, 2021 at 06:00:21PM +0200, Pali Rohár wrote:
> > This property specifies slot power limit in mW unit. It is form-factor and
> > board specific value and must be initialized by hardware.
> >
> > Some PCIe controllers delegates this work to software to allow hardware
> > flexibility and therefore this property basically specifies what should
> > host bridge programs into PCIe Slot Capabilities registers.
> >
> > Property needs to be specified in mW unit, and not in special format
> > defined by Slot Capabilities (which encodes scaling factor or different
> > unit). Host drivers should convert value from mW unit to their format.
> >
> > Signed-off-by: Pali Rohár <[email protected]>
> > ---
> > Documentation/devicetree/bindings/pci/pci.txt | 6 ++++++
> > 1 file changed, 6 insertions(+)
>
> This needs to be in dtschema schemas/pci/pci-bus.yaml instead.
>
> (pci.txt is still here because it needs to be relicensed to move all the
> descriptions to pci-bus.yaml.)
Ok, this is just a proposal for a new DTS property. So documentation
issues will be fixed in real patch.
> >
> > diff --git a/Documentation/devicetree/bindings/pci/pci.txt b/Documentation/devicetree/bindings/pci/pci.txt
> > index 6a8f2874a24d..e67d5db21514 100644
> > --- a/Documentation/devicetree/bindings/pci/pci.txt
> > +++ b/Documentation/devicetree/bindings/pci/pci.txt
> > @@ -32,6 +32,12 @@ driver implementation may support the following properties:
> > root port to downstream device and host bridge drivers can do programming
> > which depends on CLKREQ signal existence. For example, programming root port
> > not to advertise ASPM L1 Sub-States support if there is no CLKREQ signal.
> > +- slot-power-limit:
> > + If present this property specifies slot power limit in mW unit. Host drivers
>
> As mentioned, this should have a unit suffix. I'm not sure it is
> beneficial to share with SFP in this case though.
>
> > + can parse this slot power limit and use it for programming Root Port or host
> > + bridge, or for composing and sending PCIe Set_Slot_Power_Limit message
> > + through the Root Port or host bridge when transitioning PCIe link from a
> > + non-DL_Up Status to a DL_Up Status.
>
> I no nothing about how this mechanism works, but I think this belongs in
> the next section as for PCIe, a slot is always below a PCI-PCI bridge.
> If we have N slots, then there's N bridges and needs to be N
> slot-power-limit properties, right?
>
> (The same is probably true for all the properties here except
> linux,pci-domain.) There's no distinction between host and PCI bridges
> in pci-bus.yaml though.
>
> Rob
This slot-power-limit property belongs to same place where are also
other slot properties (link speed, reset gpios, clkreq). So I put it in
place where others are.
But I'm not sure where it should be as it affects link/slot. Because
link has two sides. I guess that link speed and slot power limit could
belong to the root/downstream port and reset gpio to the endpoint card
or upstream port...
On Wednesday 25 August 2021 09:57:52 Rob Herring wrote:
> On Tue, Aug 24, 2021 at 11:14 AM Pali Rohár <[email protected]> wrote:
> >
> > On Tuesday 24 August 2021 10:35:34 Rob Herring wrote:
> > > On Fri, Aug 20, 2021 at 06:00:21PM +0200, Pali Rohár wrote:
> > > > This property specifies slot power limit in mW unit. It is form-factor and
> > > > board specific value and must be initialized by hardware.
> > > >
> > > > Some PCIe controllers delegates this work to software to allow hardware
> > > > flexibility and therefore this property basically specifies what should
> > > > host bridge programs into PCIe Slot Capabilities registers.
> > > >
> > > > Property needs to be specified in mW unit, and not in special format
> > > > defined by Slot Capabilities (which encodes scaling factor or different
> > > > unit). Host drivers should convert value from mW unit to their format.
> > > >
> > > > Signed-off-by: Pali Rohár <[email protected]>
> > > > ---
> > > > Documentation/devicetree/bindings/pci/pci.txt | 6 ++++++
> > > > 1 file changed, 6 insertions(+)
> > >
> > > This needs to be in dtschema schemas/pci/pci-bus.yaml instead.
> > >
> > > (pci.txt is still here because it needs to be relicensed to move all the
> > > descriptions to pci-bus.yaml.)
> >
> > Ok, this is just a proposal for a new DTS property. So documentation
> > issues will be fixed in real patch.
> >
> > > >
> > > > diff --git a/Documentation/devicetree/bindings/pci/pci.txt b/Documentation/devicetree/bindings/pci/pci.txt
> > > > index 6a8f2874a24d..e67d5db21514 100644
> > > > --- a/Documentation/devicetree/bindings/pci/pci.txt
> > > > +++ b/Documentation/devicetree/bindings/pci/pci.txt
> > > > @@ -32,6 +32,12 @@ driver implementation may support the following properties:
> > > > root port to downstream device and host bridge drivers can do programming
> > > > which depends on CLKREQ signal existence. For example, programming root port
> > > > not to advertise ASPM L1 Sub-States support if there is no CLKREQ signal.
> > > > +- slot-power-limit:
> > > > + If present this property specifies slot power limit in mW unit. Host drivers
> > >
> > > As mentioned, this should have a unit suffix. I'm not sure it is
> > > beneficial to share with SFP in this case though.
> > >
> > > > + can parse this slot power limit and use it for programming Root Port or host
> > > > + bridge, or for composing and sending PCIe Set_Slot_Power_Limit message
> > > > + through the Root Port or host bridge when transitioning PCIe link from a
> > > > + non-DL_Up Status to a DL_Up Status.
> > >
> > > I no nothing about how this mechanism works, but I think this belongs in
> > > the next section as for PCIe, a slot is always below a PCI-PCI bridge.
> > > If we have N slots, then there's N bridges and needs to be N
> > > slot-power-limit properties, right?
> > >
> > > (The same is probably true for all the properties here except
> > > linux,pci-domain.) There's no distinction between host and PCI bridges
> > > in pci-bus.yaml though.
> > >
> > > Rob
> >
> > This slot-power-limit property belongs to same place where are also
> > other slot properties (link speed, reset gpios, clkreq). So I put it in
> > place where others are.
> >
> > But I'm not sure where it should be as it affects link/slot. Because
> > link has two sides. I guess that link speed and slot power limit could
> > belong to the root/downstream port and reset gpio to the endpoint card
> > or upstream port...
>
> I wasn't debating whether it goes upstream or downstream, but just
> that it can apply to more than just the host bridge or root port(s).
> We have that now already with reset-gpios. Look at the hikey970 case
> that's queued for 5.15. It's got RP -> switch -> slots/devices with
> reset gpio on each slot.
>
> As for upstream vs. downstream side, this is one of those cases where
> we didn't represent the downstream side in DT, so everything gets
> stuffed in the upstream side. As PCIe is point to point, it doesn't
> matter so much. It would be a bigger issue on old PCI.
Upstream vs downstream matters for hotplugging PCIe cases. Upstream
part (endpoint card) can be unplugged from hotplugging PCIe bridge and
so does not have any node in sysfs (or lspci output). But downstream
part (or root port) of PCIe bridge is always present.
On Tue, Aug 24, 2021 at 11:14 AM Pali Rohár <[email protected]> wrote:
>
> On Tuesday 24 August 2021 10:35:34 Rob Herring wrote:
> > On Fri, Aug 20, 2021 at 06:00:21PM +0200, Pali Rohár wrote:
> > > This property specifies slot power limit in mW unit. It is form-factor and
> > > board specific value and must be initialized by hardware.
> > >
> > > Some PCIe controllers delegates this work to software to allow hardware
> > > flexibility and therefore this property basically specifies what should
> > > host bridge programs into PCIe Slot Capabilities registers.
> > >
> > > Property needs to be specified in mW unit, and not in special format
> > > defined by Slot Capabilities (which encodes scaling factor or different
> > > unit). Host drivers should convert value from mW unit to their format.
> > >
> > > Signed-off-by: Pali Rohár <[email protected]>
> > > ---
> > > Documentation/devicetree/bindings/pci/pci.txt | 6 ++++++
> > > 1 file changed, 6 insertions(+)
> >
> > This needs to be in dtschema schemas/pci/pci-bus.yaml instead.
> >
> > (pci.txt is still here because it needs to be relicensed to move all the
> > descriptions to pci-bus.yaml.)
>
> Ok, this is just a proposal for a new DTS property. So documentation
> issues will be fixed in real patch.
>
> > >
> > > diff --git a/Documentation/devicetree/bindings/pci/pci.txt b/Documentation/devicetree/bindings/pci/pci.txt
> > > index 6a8f2874a24d..e67d5db21514 100644
> > > --- a/Documentation/devicetree/bindings/pci/pci.txt
> > > +++ b/Documentation/devicetree/bindings/pci/pci.txt
> > > @@ -32,6 +32,12 @@ driver implementation may support the following properties:
> > > root port to downstream device and host bridge drivers can do programming
> > > which depends on CLKREQ signal existence. For example, programming root port
> > > not to advertise ASPM L1 Sub-States support if there is no CLKREQ signal.
> > > +- slot-power-limit:
> > > + If present this property specifies slot power limit in mW unit. Host drivers
> >
> > As mentioned, this should have a unit suffix. I'm not sure it is
> > beneficial to share with SFP in this case though.
> >
> > > + can parse this slot power limit and use it for programming Root Port or host
> > > + bridge, or for composing and sending PCIe Set_Slot_Power_Limit message
> > > + through the Root Port or host bridge when transitioning PCIe link from a
> > > + non-DL_Up Status to a DL_Up Status.
> >
> > I no nothing about how this mechanism works, but I think this belongs in
> > the next section as for PCIe, a slot is always below a PCI-PCI bridge.
> > If we have N slots, then there's N bridges and needs to be N
> > slot-power-limit properties, right?
> >
> > (The same is probably true for all the properties here except
> > linux,pci-domain.) There's no distinction between host and PCI bridges
> > in pci-bus.yaml though.
> >
> > Rob
>
> This slot-power-limit property belongs to same place where are also
> other slot properties (link speed, reset gpios, clkreq). So I put it in
> place where others are.
>
> But I'm not sure where it should be as it affects link/slot. Because
> link has two sides. I guess that link speed and slot power limit could
> belong to the root/downstream port and reset gpio to the endpoint card
> or upstream port...
I wasn't debating whether it goes upstream or downstream, but just
that it can apply to more than just the host bridge or root port(s).
We have that now already with reset-gpios. Look at the hikey970 case
that's queued for 5.15. It's got RP -> switch -> slots/devices with
reset gpio on each slot.
As for upstream vs. downstream side, this is one of those cases where
we didn't represent the downstream side in DT, so everything gets
stuffed in the upstream side. As PCIe is point to point, it doesn't
matter so much. It would be a bigger issue on old PCI.
Rob