[PATCH v2] schemas: pci: Document PCIe T_POWER_ON

[PATCH v2] schemas: pci: Document PCIe T_POWER_ON

[Krishna Chaitanya Chundru]

From PCIe r6, sec 5.5.4 & Table 5-11 in sec 5.5.5 T_POWER_ON is the
minimum amount of time(in us) that each component must wait in L1.2.Exit
after sampling CLKREQ# asserted before actively driving the interface to
ensure no device is ever actively driving into an unpowered component and
these values are based on the components and AC coupling capacitors used
in the connection linking the two components.

This property should be used to indicate the T_POWER_ON for each Root Port.

Signed-off-by: Krishna Chaitanya Chundru <krishna.chundru@oss.qualcomm.com>
---
Changes in v1:
- Updated the commiit text (Mani).
- Link to v1: https://lore.kernel.org/all/20251110112550.2070659-1-krishna.chundru@oss.qualcomm.com/#t

 dtschema/schemas/pci/pci-bus-common.yaml | 9 +++++++++
 1 file changed, 9 insertions(+)

diff --git a/dtschema/schemas/pci/pci-bus-common.yaml b/dtschema/schemas/pci/pci-bus-common.yaml
index 5257339..bbe5510 100644
--- a/dtschema/schemas/pci/pci-bus-common.yaml
+++ b/dtschema/schemas/pci/pci-bus-common.yaml
@@ -152,6 +152,15 @@ properties:
       This property is invalid in host bridge nodes.
     maxItems: 1
 
+  t-power-on-us:
+    description:
+      The minimum amount of time that each component must wait in
+      L1.2.Exit after sampling CLKREQ# asserted before actively driving
+      the interface to ensure no device is ever actively driving into an
+      unpowered component. This value is based on the components and AC
+      coupling capacitors used in the connection linking the two
+      components(PCIe r6.0, sec 5.5.4).
+
   supports-clkreq:
     description:
       If present this property specifies that CLKREQ signal routing exists from
-- 
2.34.1

Re: [PATCH v2] schemas: pci: Document PCIe T_POWER_ON

[Manivannan Sadhasivam]

On Mon, Nov 10, 2025 at 04:59:47PM +0530, Krishna Chaitanya Chundru wrote:
> From PCIe r6, sec 5.5.4 & Table 5-11 in sec 5.5.5 T_POWER_ON is the
> minimum amount of time(in us) that each component must wait in L1.2.Exit
> after sampling CLKREQ# asserted before actively driving the interface to
> ensure no device is ever actively driving into an unpowered component and
> these values are based on the components and AC coupling capacitors used
> in the connection linking the two components.
> 
> This property should be used to indicate the T_POWER_ON for each Root Port.
> 

I'm not sure if we should restrict this property to just Root Ports. Defining a
property in 'pci-bus-common.yaml' means, all PCI bridges could use it, but this
value is applicable to endpoint devices also.

Also, you might want to add some info that the driver (or DT consumer) should
derive the T_POWER_ON Scale and T_POWER_ON Value from this value.

- Mani

> Signed-off-by: Krishna Chaitanya Chundru <krishna.chundru@oss.qualcomm.com>
> ---
> Changes in v1:
> - Updated the commiit text (Mani).
> - Link to v1: https://lore.kernel.org/all/20251110112550.2070659-1-krishna.chundru@oss.qualcomm.com/#t
> 
>  dtschema/schemas/pci/pci-bus-common.yaml | 9 +++++++++
>  1 file changed, 9 insertions(+)
> 
> diff --git a/dtschema/schemas/pci/pci-bus-common.yaml b/dtschema/schemas/pci/pci-bus-common.yaml
> index 5257339..bbe5510 100644
> --- a/dtschema/schemas/pci/pci-bus-common.yaml
> +++ b/dtschema/schemas/pci/pci-bus-common.yaml
> @@ -152,6 +152,15 @@ properties:
>        This property is invalid in host bridge nodes.
>      maxItems: 1
>  
> +  t-power-on-us:
> +    description:
> +      The minimum amount of time that each component must wait in
> +      L1.2.Exit after sampling CLKREQ# asserted before actively driving
> +      the interface to ensure no device is ever actively driving into an
> +      unpowered component. This value is based on the components and AC
> +      coupling capacitors used in the connection linking the two
> +      components(PCIe r6.0, sec 5.5.4).
> +
>    supports-clkreq:
>      description:
>        If present this property specifies that CLKREQ signal routing exists from
> -- 
> 2.34.1
> 
> 

-- 
மணிவண்ணன் சதாசிவம்

Re: [PATCH v2] schemas: pci: Document PCIe T_POWER_ON

[Lukas Wunner]

On Mon, Nov 10, 2025 at 04:59:47PM +0530, Krishna Chaitanya Chundru wrote:
> From PCIe r6, sec 5.5.4 & Table 5-11 in sec 5.5.5 T_POWER_ON is the

Please use the latest spec version as reference, i.e. PCIe r7.0.

> minimum amount of time(in us) that each component must wait in L1.2.Exit
> after sampling CLKREQ# asserted before actively driving the interface to
> ensure no device is ever actively driving into an unpowered component and
> these values are based on the components and AC coupling capacitors used
> in the connection linking the two components.
> 
> This property should be used to indicate the T_POWER_ON for each Root Port.

What's the difference between this property and the Port T_POWER_ON_Scale
and T_POWER_ON_Value in the L1 PM Substates Capabilities Register?

Why do you need this in the device tree even though it's available
in the register?

Thanks,

Lukas

Re: [PATCH v2] schemas: pci: Document PCIe T_POWER_ON

[Krishna Chaitanya Chundru]

On 11/10/2025 6:11 PM, Lukas Wunner wrote:
> On Mon, Nov 10, 2025 at 04:59:47PM +0530, Krishna Chaitanya Chundru wrote:
>>  From PCIe r6, sec 5.5.4 & Table 5-11 in sec 5.5.5 T_POWER_ON is the
> Please use the latest spec version as reference, i.e. PCIe r7.0.
ack.
>> minimum amount of time(in us) that each component must wait in L1.2.Exit
>> after sampling CLKREQ# asserted before actively driving the interface to
>> ensure no device is ever actively driving into an unpowered component and
>> these values are based on the components and AC coupling capacitors used
>> in the connection linking the two components.
>>
>> This property should be used to indicate the T_POWER_ON for each Root Port.
> What's the difference between this property and the Port T_POWER_ON_Scale
> and T_POWER_ON_Value in the L1 PM Substates Capabilities Register?
>
> Why do you need this in the device tree even though it's available
> in the register?

This value is same as L1 PM substates value, some controllers needs to 
update this
value before enumeration as hardware might now program this value 
correctly[1].

[1]: [PATCH] PCI: qcom: Program correct T_POWER_ON value for L1.2 exit 
timing

<https://lore.kernel.org/all/20251104-t_power_on_fux-v1-1-eb5916e47fd7@oss.qualcomm.com/>- 
Krishna Chaitanya.

> Thanks,
>
> Lukas

Re: [PATCH v2] schemas: pci: Document PCIe T_POWER_ON

[Manivannan Sadhasivam]

On Mon, Nov 10, 2025 at 01:41:45PM +0100, Lukas Wunner wrote:
> On Mon, Nov 10, 2025 at 04:59:47PM +0530, Krishna Chaitanya Chundru wrote:
> > From PCIe r6, sec 5.5.4 & Table 5-11 in sec 5.5.5 T_POWER_ON is the
> 
> Please use the latest spec version as reference, i.e. PCIe r7.0.
> 
> > minimum amount of time(in us) that each component must wait in L1.2.Exit
> > after sampling CLKREQ# asserted before actively driving the interface to
> > ensure no device is ever actively driving into an unpowered component and
> > these values are based on the components and AC coupling capacitors used
> > in the connection linking the two components.
> > 
> > This property should be used to indicate the T_POWER_ON for each Root Port.
> 
> What's the difference between this property and the Port T_POWER_ON_Scale
> and T_POWER_ON_Value in the L1 PM Substates Capabilities Register?
> 
> Why do you need this in the device tree even though it's available
> in the register?
> 

Someone needs to program these registers. In the x86 world, BIOS will do it
happily, but in devicetree world, OS has to do it. And since this is a platform
specific value, this is getting passed from devicetree.

- Mani

-- 
மணிவண்ணன் சதாசிவம்

Re: [PATCH v2] schemas: pci: Document PCIe T_POWER_ON

[Anand Moon]

Hi Manivannan

On Thu, 13 Nov 2025 at 10:01, Manivannan Sadhasivam <mani@kernel.org> wrote:
>
> On Mon, Nov 10, 2025 at 01:41:45PM +0100, Lukas Wunner wrote:
> > On Mon, Nov 10, 2025 at 04:59:47PM +0530, Krishna Chaitanya Chundru wrote:
> > > From PCIe r6, sec 5.5.4 & Table 5-11 in sec 5.5.5 T_POWER_ON is the
> >
> > Please use the latest spec version as reference, i.e. PCIe r7.0.
> >
> > > minimum amount of time(in us) that each component must wait in L1.2.Exit
> > > after sampling CLKREQ# asserted before actively driving the interface to
> > > ensure no device is ever actively driving into an unpowered component and
> > > these values are based on the components and AC coupling capacitors used
> > > in the connection linking the two components.
> > >
> > > This property should be used to indicate the T_POWER_ON for each Root Port.
> >
> > What's the difference between this property and the Port T_POWER_ON_Scale
> > and T_POWER_ON_Value in the L1 PM Substates Capabilities Register?
> >
> > Why do you need this in the device tree even though it's available
> > in the register?
> >
>
> Someone needs to program these registers. In the x86 world, BIOS will do it
> happily, but in devicetree world, OS has to do it. And since this is a platform
> specific value, this is getting passed from devicetree.
>
According to the RK3588 TRM Part 2, the DSP_PCIE_L1SUB_CAPABILITY_REG (0x4)
It is a commonly configurable parameter, It can be tuned on for the
Rockchip platform.
> - Mani
>
> --
> மணிவண்ணன் சதாசிவம்
>
Thanks
-Anand

I could not apply this patch

$ git am ./v2_20251110_krishna_chundru_schemas_pci_document_pcie_t_power_on.mbx
Applying: schemas: pci: Document PCIe T_POWER_ON
error: dtschema/schemas/pci/pci-bus-common.yaml: does not exist in index
Patch failed at 0001 schemas: pci: Document PCIe T_POWER_ON
hint: Use 'git am --show-current-patch=diff' to see the failed patch
hint: When you have resolved this problem, run "git am --continue".
hint: If you prefer to skip this patch, run "git am --skip" instead.
hint: To restore the original branch and stop patching, run "git am --abort".
hint: Disable this message with "git config set advice.mergeConflict false"

Re: [PATCH v2] schemas: pci: Document PCIe T_POWER_ON

[Manivannan Sadhasivam]

On Thu, Nov 13, 2025 at 10:46:59AM +0530, Anand Moon wrote:
> Hi Manivannan
> 
> On Thu, 13 Nov 2025 at 10:01, Manivannan Sadhasivam <mani@kernel.org> wrote:
> >
> > On Mon, Nov 10, 2025 at 01:41:45PM +0100, Lukas Wunner wrote:
> > > On Mon, Nov 10, 2025 at 04:59:47PM +0530, Krishna Chaitanya Chundru wrote:
> > > > From PCIe r6, sec 5.5.4 & Table 5-11 in sec 5.5.5 T_POWER_ON is the
> > >
> > > Please use the latest spec version as reference, i.e. PCIe r7.0.
> > >
> > > > minimum amount of time(in us) that each component must wait in L1.2.Exit
> > > > after sampling CLKREQ# asserted before actively driving the interface to
> > > > ensure no device is ever actively driving into an unpowered component and
> > > > these values are based on the components and AC coupling capacitors used
> > > > in the connection linking the two components.
> > > >
> > > > This property should be used to indicate the T_POWER_ON for each Root Port.
> > >
> > > What's the difference between this property and the Port T_POWER_ON_Scale
> > > and T_POWER_ON_Value in the L1 PM Substates Capabilities Register?
> > >
> > > Why do you need this in the device tree even though it's available
> > > in the register?
> > >
> >
> > Someone needs to program these registers. In the x86 world, BIOS will do it
> > happily, but in devicetree world, OS has to do it. And since this is a platform
> > specific value, this is getting passed from devicetree.
> >
> According to the RK3588 TRM Part 2, the DSP_PCIE_L1SUB_CAPABILITY_REG (0x4)
> It is a commonly configurable parameter, It can be tuned on for the
> Rockchip platform.

T_POWER_ON is a generic value defined in the spec. All compatible platforms
should support setting this value through 'L1 PM Substates Capabilities'
register or by platform specific register.

> > - Mani
> >
> > --
> > மணிவண்ணன் சதாசிவம்
> >
> Thanks
> -Anand
> 
> I could not apply this patch
> 
> $ git am ./v2_20251110_krishna_chundru_schemas_pci_document_pcie_t_power_on.mbx
> Applying: schemas: pci: Document PCIe T_POWER_ON
> error: dtschema/schemas/pci/pci-bus-common.yaml: does not exist in index
> Patch failed at 0001 schemas: pci: Document PCIe T_POWER_ON
> hint: Use 'git am --show-current-patch=diff' to see the failed patch
> hint: When you have resolved this problem, run "git am --continue".
> hint: If you prefer to skip this patch, run "git am --skip" instead.
> hint: To restore the original branch and stop patching, run "git am --abort".
> hint: Disable this message with "git config set advice.mergeConflict false"

This is a dtschema patch, not Linux kernel.

- Mani

-- 
மணிவண்ணன் சதாசிவம்

Re: [PATCH v2] schemas: pci: Document PCIe T_POWER_ON

[Anand Moon]

Hi Manivannan

On Thu, 13 Nov 2025 at 11:21, Manivannan Sadhasivam <mani@kernel.org> wrote:
>
> On Thu, Nov 13, 2025 at 10:46:59AM +0530, Anand Moon wrote:
> > Hi Manivannan
> >
> > On Thu, 13 Nov 2025 at 10:01, Manivannan Sadhasivam <mani@kernel.org> wrote:
> > >
> > > On Mon, Nov 10, 2025 at 01:41:45PM +0100, Lukas Wunner wrote:
> > > > On Mon, Nov 10, 2025 at 04:59:47PM +0530, Krishna Chaitanya Chundru wrote:
> > > > > From PCIe r6, sec 5.5.4 & Table 5-11 in sec 5.5.5 T_POWER_ON is the
> > > >
> > > > Please use the latest spec version as reference, i.e. PCIe r7.0.
> > > >
> > > > > minimum amount of time(in us) that each component must wait in L1.2.Exit
> > > > > after sampling CLKREQ# asserted before actively driving the interface to
> > > > > ensure no device is ever actively driving into an unpowered component and
> > > > > these values are based on the components and AC coupling capacitors used
> > > > > in the connection linking the two components.
> > > > >
> > > > > This property should be used to indicate the T_POWER_ON for each Root Port.
> > > >
> > > > What's the difference between this property and the Port T_POWER_ON_Scale
> > > > and T_POWER_ON_Value in the L1 PM Substates Capabilities Register?
> > > >
> > > > Why do you need this in the device tree even though it's available
> > > > in the register?
> > > >
> > >
> > > Someone needs to program these registers. In the x86 world, BIOS will do it
> > > happily, but in devicetree world, OS has to do it. And since this is a platform
> > > specific value, this is getting passed from devicetree.
> > >
> > According to the RK3588 TRM Part 2, the DSP_PCIE_L1SUB_CAPABILITY_REG (0x4)
> > It is a commonly configurable parameter, It can be tuned on for the
> > Rockchip platform.
>
> T_POWER_ON is a generic value defined in the spec. All compatible platforms
> should support setting this value through 'L1 PM Substates Capabilities'
> register or by platform specific register.
>
Ok, Thanks.
> > > - Mani
> > >
> > > --
> > > மணிவண்ணன் சதாசிவம்
> > >
> > Thanks
> > -Anand
> >
> > I could not apply this patch
> >
> > $ git am ./v2_20251110_krishna_chundru_schemas_pci_document_pcie_t_power_on.mbx
> > Applying: schemas: pci: Document PCIe T_POWER_ON
> > error: dtschema/schemas/pci/pci-bus-common.yaml: does not exist in index
> > Patch failed at 0001 schemas: pci: Document PCIe T_POWER_ON
> > hint: Use 'git am --show-current-patch=diff' to see the failed patch
> > hint: When you have resolved this problem, run "git am --continue".
> > hint: If you prefer to skip this patch, run "git am --skip" instead.
> > hint: To restore the original branch and stop patching, run "git am --abort".
> > hint: Disable this message with "git config set advice.mergeConflict false"
>
> This is a dtschema patch, not Linux kernel.
>
Ok, got that.
> - Mani
>
> --
> மணிவண்ணன் சதாசிவம்
Thanks
-Anand

Re: [PATCH v2] schemas: pci: Document PCIe T_POWER_ON

[Krishna Chaitanya Chundru]

On 11/10/2025 5:33 PM, Manivannan Sadhasivam wrote:
> On Mon, Nov 10, 2025 at 04:59:47PM +0530, Krishna Chaitanya Chundru wrote:
>>  From PCIe r6, sec 5.5.4 & Table 5-11 in sec 5.5.5 T_POWER_ON is the
>> minimum amount of time(in us) that each component must wait in L1.2.Exit
>> after sampling CLKREQ# asserted before actively driving the interface to
>> ensure no device is ever actively driving into an unpowered component and
>> these values are based on the components and AC coupling capacitors used
>> in the connection linking the two components.
>>
>> This property should be used to indicate the T_POWER_ON for each Root Port.
>>
> I'm not sure if we should restrict this property to just Root Ports. Defining a
> property in 'pci-bus-common.yaml' means, all PCI bridges could use it, but this
> value is applicable to endpoint devices also.
Better to add in pci-device.yaml then.
> Also, you might want to add some info that the driver (or DT consumer) should
> derive the T_POWER_ON Scale and T_POWER_ON Value from this value.
ack

- Krishna Chaitanya.
> - Mani
>
>> Signed-off-by: Krishna Chaitanya Chundru <krishna.chundru@oss.qualcomm.com>
>> ---
>> Changes in v1:
>> - Updated the commiit text (Mani).
>> - Link to v1: https://lore.kernel.org/all/20251110112550.2070659-1-krishna.chundru@oss.qualcomm.com/#t
>>
>>   dtschema/schemas/pci/pci-bus-common.yaml | 9 +++++++++
>>   1 file changed, 9 insertions(+)
>>
>> diff --git a/dtschema/schemas/pci/pci-bus-common.yaml b/dtschema/schemas/pci/pci-bus-common.yaml
>> index 5257339..bbe5510 100644
>> --- a/dtschema/schemas/pci/pci-bus-common.yaml
>> +++ b/dtschema/schemas/pci/pci-bus-common.yaml
>> @@ -152,6 +152,15 @@ properties:
>>         This property is invalid in host bridge nodes.
>>       maxItems: 1
>>   
>> +  t-power-on-us:
>> +    description:
>> +      The minimum amount of time that each component must wait in
>> +      L1.2.Exit after sampling CLKREQ# asserted before actively driving
>> +      the interface to ensure no device is ever actively driving into an
>> +      unpowered component. This value is based on the components and AC
>> +      coupling capacitors used in the connection linking the two
>> +      components(PCIe r6.0, sec 5.5.4).
>> +
>>     supports-clkreq:
>>       description:
>>         If present this property specifies that CLKREQ signal routing exists from
>> -- 
>> 2.34.1
>>
>>

Re: [PATCH v2] schemas: pci: Document PCIe T_POWER_ON

[Lukas Wunner]

On Thu, Nov 13, 2025 at 09:33:54AM +0530, Krishna Chaitanya Chundru wrote:
> On 11/10/2025 6:11 PM, Lukas Wunner wrote:
> > On Mon, Nov 10, 2025 at 04:59:47PM +0530, Krishna Chaitanya Chundru wrote:
> > >  From PCIe r6, sec 5.5.4 & Table 5-11 in sec 5.5.5 T_POWER_ON is the
> > Please use the latest spec version as reference, i.e. PCIe r7.0.
> ack.
> > > minimum amount of time(in us) that each component must wait in L1.2.Exit
> > > after sampling CLKREQ# asserted before actively driving the interface to
> > > ensure no device is ever actively driving into an unpowered component and
> > > these values are based on the components and AC coupling capacitors used
> > > in the connection linking the two components.
> > > 
> > > This property should be used to indicate the T_POWER_ON for each Root Port.
> > What's the difference between this property and the Port T_POWER_ON_Scale
> > and T_POWER_ON_Value in the L1 PM Substates Capabilities Register?
> > 
> > Why do you need this in the device tree even though it's available
> > in the register?
> 
> This value is same as L1 PM substates value, some controllers needs to
> update this
> value before enumeration as hardware might now program this value
> correctly[1].
> 
> [1]: [PATCH] PCI: qcom: Program correct T_POWER_ON value for L1.2 exit
> timing
> 
> <https://lore.kernel.org/all/20251104-t_power_on_fux-v1-1-eb5916e47fd7@oss.qualcomm.com/>

Per PCIe r7.0 sec 7.8.3.2, all fields in the L1 PM Substates Capabilities
Register are of type "HwInit", which sec 7.4 defines as:

   "Register bits are permitted, as an implementation option, to be
    hard-coded, initialized by system/device firmware, or initialized
    by hardware mechanisms such as pin strapping or nonvolatile storage.
    Initialization by system firmware is permitted only for
    system-integrated devices.
    Bits must be fixed in value and read-only after initialization."
                                    ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^

These bits are not supposed to be writable by the operating system,
so what you're doing in that patch is not spec-compliant.

I think it needs to be made explicit in the devicetree schema that
the property is only intended for non-compliant hardware which allows
(and requires) the operating system to initialize the register.

Maybe it makes more sense to have a property which specifies the raw
32-bit register contents, instead of having a property for each
individual field.  Otherwise you'll have to amend the schema
whenever the PCIe spec extends the register with additional fields.

Thanks,

Lukas

Re: [PATCH v2] schemas: pci: Document PCIe T_POWER_ON

[Bjorn Helgaas]

On Thu, Nov 13, 2025 at 09:36:48AM +0100, Lukas Wunner wrote:
> On Thu, Nov 13, 2025 at 09:33:54AM +0530, Krishna Chaitanya Chundru wrote:
> > On 11/10/2025 6:11 PM, Lukas Wunner wrote:
> > > On Mon, Nov 10, 2025 at 04:59:47PM +0530, Krishna Chaitanya Chundru wrote:
> > > > From PCIe r6, sec 5.5.4 & Table 5-11 in sec 5.5.5 T_POWER_ON
> > > > is the minimum amount of time(in us) that each component must
> > > > wait in L1.2.Exit after sampling CLKREQ# asserted before
> > > > actively driving the interface to ensure no device is ever
> > > > actively driving into an unpowered component and these values
> > > > are based on the components and AC coupling capacitors used
> > > > in the connection linking the two components.
> > > > 
> > > > This property should be used to indicate the T_POWER_ON for
> > > > each Root Port.
> > >
> > > What's the difference between this property and the Port
> > > T_POWER_ON_Scale and T_POWER_ON_Value in the L1 PM Substates
> > > Capabilities Register?
> > > 
> > > Why do you need this in the device tree even though it's
> > > available in the register?
> > 
> > This value is same as L1 PM substates value, some controllers
> > needs to update this value before enumeration as hardware might
> > now program this value correctly[1].
> > 
> > [1]: [PATCH] PCI: qcom: Program correct T_POWER_ON value for L1.2
> > exit timing
> > 
> > <https://lore.kernel.org/all/20251104-t_power_on_fux-v1-1-eb5916e47fd7@oss.qualcomm.com/>
> 
> Per PCIe r7.0 sec 7.8.3.2, all fields in the L1 PM Substates Capabilities
> Register are of type "HwInit", which sec 7.4 defines as:
> 
>    "Register bits are permitted, as an implementation option, to be
>     hard-coded, initialized by system/device firmware, or initialized
>     by hardware mechanisms such as pin strapping or nonvolatile storage.
>     Initialization by system firmware is permitted only for
>     system-integrated devices.
>     Bits must be fixed in value and read-only after initialization."
>                                     ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
> 
> These bits are not supposed to be writable by the operating system,
> so what you're doing in that patch is not spec-compliant.
> 
> I think it needs to be made explicit in the devicetree schema that
> the property is only intended for non-compliant hardware which allows
> (and requires) the operating system to initialize the register.

I don't see a driver patch that uses this yet, but I assume the driver
will use a device-specific way to set the value that will appear in
the L1 PM Substates Capabilities register, and the register visible in
config space probably is read-only as the PCIe spec describes, so I
don't think this makes the hardware non-compliant.

> Maybe it makes more sense to have a property which specifies the raw
> 32-bit register contents, instead of having a property for each
> individual field.  Otherwise you'll have to amend the schema
> whenever the PCIe spec extends the register with additional fields.

I don't have any personal experience with this hardware, but I think
the device-specific registers that back the standard PCI config
registers sometimes use different formats.  pcie-brcmstb.c is a good
example that I've tripped over several times:
https://lore.kernel.org/all/5ca0b4a2-ec3a-4fa5-a691-7e3bab88890a@broadcom.com/

Bjorn

Re: [PATCH v2] schemas: pci: Document PCIe T_POWER_ON

[Manivannan Sadhasivam]

On Thu, Nov 13, 2025 at 09:36:48AM +0100, Lukas Wunner wrote:
> On Thu, Nov 13, 2025 at 09:33:54AM +0530, Krishna Chaitanya Chundru wrote:
> > On 11/10/2025 6:11 PM, Lukas Wunner wrote:
> > > On Mon, Nov 10, 2025 at 04:59:47PM +0530, Krishna Chaitanya Chundru wrote:
> > > >  From PCIe r6, sec 5.5.4 & Table 5-11 in sec 5.5.5 T_POWER_ON is the
> > > Please use the latest spec version as reference, i.e. PCIe r7.0.
> > ack.
> > > > minimum amount of time(in us) that each component must wait in L1.2.Exit
> > > > after sampling CLKREQ# asserted before actively driving the interface to
> > > > ensure no device is ever actively driving into an unpowered component and
> > > > these values are based on the components and AC coupling capacitors used
> > > > in the connection linking the two components.
> > > > 
> > > > This property should be used to indicate the T_POWER_ON for each Root Port.
> > > What's the difference between this property and the Port T_POWER_ON_Scale
> > > and T_POWER_ON_Value in the L1 PM Substates Capabilities Register?
> > > 
> > > Why do you need this in the device tree even though it's available
> > > in the register?
> > 
> > This value is same as L1 PM substates value, some controllers needs to
> > update this
> > value before enumeration as hardware might now program this value
> > correctly[1].
> > 
> > [1]: [PATCH] PCI: qcom: Program correct T_POWER_ON value for L1.2 exit
> > timing
> > 
> > <https://lore.kernel.org/all/20251104-t_power_on_fux-v1-1-eb5916e47fd7@oss.qualcomm.com/>
> 
> Per PCIe r7.0 sec 7.8.3.2, all fields in the L1 PM Substates Capabilities
> Register are of type "HwInit", which sec 7.4 defines as:
> 
>    "Register bits are permitted, as an implementation option, to be
>     hard-coded, initialized by system/device firmware, or initialized
>     by hardware mechanisms such as pin strapping or nonvolatile storage.
>     Initialization by system firmware is permitted only for
>     system-integrated devices.
>     Bits must be fixed in value and read-only after initialization."
>                                     ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
> 
> These bits are not supposed to be writable by the operating system,
> so what you're doing in that patch is not spec-compliant.
> 

I interpret 'initialized by system/device firmware', same as 'initialized by
OS', as both are mostly same for the devicetree platforms. So it is fine IMO.
Ofc, if the initialization was carried out by the firmware, then OS has no
business in changing it, but it is not the case.

> I think it needs to be made explicit in the devicetree schema that
> the property is only intended for non-compliant hardware which allows
> (and requires) the operating system to initialize the register.
> 

Sorry, I disagree. The hardware is spec compliant, just that the firmware missed
initializing the fields.

> Maybe it makes more sense to have a property which specifies the raw
> 32-bit register contents, instead of having a property for each
> individual field.  Otherwise you'll have to amend the schema
> whenever the PCIe spec extends the register with additional fields.
> 

DT properties do not specify a register value, but instead they specify hardware
configuration value and that's what this property is doing. The OS/other DT
consumers should interpret this value as per the spec and program the relevant
registers.

- Mani

-- 
மணிவண்ணன் சதாசிவம்

Re: [PATCH v2] schemas: pci: Document PCIe T_POWER_ON

[Shawn Lin]

在 2025/11/14 星期五 0:41, Manivannan Sadhasivam 写道:
> On Thu, Nov 13, 2025 at 09:36:48AM +0100, Lukas Wunner wrote:
>> On Thu, Nov 13, 2025 at 09:33:54AM +0530, Krishna Chaitanya Chundru wrote:
>>> On 11/10/2025 6:11 PM, Lukas Wunner wrote:
>>>> On Mon, Nov 10, 2025 at 04:59:47PM +0530, Krishna Chaitanya Chundru wrote:
>>>>>   From PCIe r6, sec 5.5.4 & Table 5-11 in sec 5.5.5 T_POWER_ON is the
>>>> Please use the latest spec version as reference, i.e. PCIe r7.0.
>>> ack.
>>>>> minimum amount of time(in us) that each component must wait in L1.2.Exit
>>>>> after sampling CLKREQ# asserted before actively driving the interface to
>>>>> ensure no device is ever actively driving into an unpowered component and
>>>>> these values are based on the components and AC coupling capacitors used
>>>>> in the connection linking the two components.
>>>>>
>>>>> This property should be used to indicate the T_POWER_ON for each Root Port.
>>>> What's the difference between this property and the Port T_POWER_ON_Scale
>>>> and T_POWER_ON_Value in the L1 PM Substates Capabilities Register?
>>>>
>>>> Why do you need this in the device tree even though it's available
>>>> in the register?
>>>
>>> This value is same as L1 PM substates value, some controllers needs to
>>> update this
>>> value before enumeration as hardware might now program this value
>>> correctly[1].
>>>
>>> [1]: [PATCH] PCI: qcom: Program correct T_POWER_ON value for L1.2 exit
>>> timing
>>>
>>> <https://lore.kernel.org/all/20251104-t_power_on_fux-v1-1-eb5916e47fd7@oss.qualcomm.com/>
>>
>> Per PCIe r7.0 sec 7.8.3.2, all fields in the L1 PM Substates Capabilities
>> Register are of type "HwInit", which sec 7.4 defines as:
>>
>>     "Register bits are permitted, as an implementation option, to be
>>      hard-coded, initialized by system/device firmware, or initialized
>>      by hardware mechanisms such as pin strapping or nonvolatile storage.
>>      Initialization by system firmware is permitted only for
>>      system-integrated devices.
>>      Bits must be fixed in value and read-only after initialization."
>>                                      ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
>>
>> These bits are not supposed to be writable by the operating system,
>> so what you're doing in that patch is not spec-compliant.
>>
> 
> I interpret 'initialized by system/device firmware', same as 'initialized by
> OS', as both are mostly same for the devicetree platforms. So it is fine IMO.
> Ofc, if the initialization was carried out by the firmware, then OS has no
> business in changing it, but it is not the case.
> 

Yes, I tend to agree with Mani. Another problem is the s2r process in
embedded ARM world. For power-saving, most platforms would cut-off the
power supply of PCIe controller during system suspend, so we save and
restore this value when relink is done, right? OS had already done this
kind of thing already.

>> I think it needs to be made explicit in the devicetree schema that
>> the property is only intended for non-compliant hardware which allows
>> (and requires) the operating system to initialize the register.
>>
> 
> Sorry, I disagree. The hardware is spec compliant, just that the firmware missed
> initializing the fields.
> 
>> Maybe it makes more sense to have a property which specifies the raw
>> 32-bit register contents, instead of having a property for each
>> individual field.  Otherwise you'll have to amend the schema
>> whenever the PCIe spec extends the register with additional fields.
>>
> 
> DT properties do not specify a register value, but instead they specify hardware
> configuration value and that's what this property is doing. The OS/other DT
> consumers should interpret this value as per the spec and program the relevant
> registers.
> 
> - Mani
>