1. Patchew
  2. linux
  3. [PATCH v2 00/10] Add PCIe support for Tesla FSD SoC
  4. View patch

[PATCH v2 07/10] dt-bindings: phy: Add PHY bindings support for FSD SoC

Shradha Todi posted 10 patches 3 months, 2 weeks ago
There is a newer version of this series
[PATCH v2 07/10] dt-bindings: phy: Add PHY bindings support for FSD SoC
Posted by Shradha Todi 3 months, 2 weeks ago 
Document PHY device tree bindings for Tesla FSD SoCs.

Signed-off-by: Shradha Todi <shradha.t@samsung.com>
---
 .../bindings/phy/samsung,exynos-pcie-phy.yaml | 25 +++++++++++++++++--
 1 file changed, 23 insertions(+), 2 deletions(-)

diff --git a/Documentation/devicetree/bindings/phy/samsung,exynos-pcie-phy.yaml b/Documentation/devicetree/bindings/phy/samsung,exynos-pcie-phy.yaml
index 41df8bb08ff7..4dc20156cdde 100644
--- a/Documentation/devicetree/bindings/phy/samsung,exynos-pcie-phy.yaml
+++ b/Documentation/devicetree/bindings/phy/samsung,exynos-pcie-phy.yaml
@@ -15,10 +15,13 @@ properties:
     const: 0
 
   compatible:
-    const: samsung,exynos5433-pcie-phy
+    enum:
+      - samsung,exynos5433-pcie-phy
+      - tesla,fsd-pcie-phy
 
   reg:
-    maxItems: 1
+    minItems: 1
+    maxItems: 2
 
   samsung,pmu-syscon:
     $ref: /schemas/types.yaml#/definitions/phandle
@@ -30,6 +33,24 @@ properties:
     description: phandle for FSYS sysreg interface, used to control
                  sysreg registers bits for PCIe PHY
 
+allOf:
+  - if:
+      properties:
+        compatible:
+          contains:
+            enum:
+              - tesla,fsd-pcie-phy
+    then:
+      description:
+        The PHY controller nodes are represented in the aliases node
+        using the following format 'pciephy{n}'. Depending on whether
+        n is 0 or 1, the phy init sequence is chosen.
+      properties:
+        reg:
+          items:
+            - description: PHY
+            - description: PCS
+
 required:
   - "#phy-cells"
   - compatible
-- 
2.49.0
Re: [PATCH v2 07/10] dt-bindings: phy: Add PHY bindings support for FSD SoC
Posted by Rob Herring 3 months, 1 week ago 
On Wed, Jun 25, 2025 at 10:22:26PM +0530, Shradha Todi wrote:
> Document PHY device tree bindings for Tesla FSD SoCs.
> 
> Signed-off-by: Shradha Todi <shradha.t@samsung.com>
> ---
>  .../bindings/phy/samsung,exynos-pcie-phy.yaml | 25 +++++++++++++++++--
>  1 file changed, 23 insertions(+), 2 deletions(-)
> 
> diff --git a/Documentation/devicetree/bindings/phy/samsung,exynos-pcie-phy.yaml b/Documentation/devicetree/bindings/phy/samsung,exynos-pcie-phy.yaml
> index 41df8bb08ff7..4dc20156cdde 100644
> --- a/Documentation/devicetree/bindings/phy/samsung,exynos-pcie-phy.yaml
> +++ b/Documentation/devicetree/bindings/phy/samsung,exynos-pcie-phy.yaml
> @@ -15,10 +15,13 @@ properties:
>      const: 0
>  
>    compatible:
> -    const: samsung,exynos5433-pcie-phy
> +    enum:
> +      - samsung,exynos5433-pcie-phy
> +      - tesla,fsd-pcie-phy
>  
>    reg:
> -    maxItems: 1
> +    minItems: 1
> +    maxItems: 2
>  
>    samsung,pmu-syscon:
>      $ref: /schemas/types.yaml#/definitions/phandle
> @@ -30,6 +33,24 @@ properties:
>      description: phandle for FSYS sysreg interface, used to control
>                   sysreg registers bits for PCIe PHY
>  
> +allOf:
> +  - if:
> +      properties:
> +        compatible:
> +          contains:
> +            enum:
> +              - tesla,fsd-pcie-phy
> +    then:
> +      description:
> +        The PHY controller nodes are represented in the aliases node
> +        using the following format 'pciephy{n}'. Depending on whether
> +        n is 0 or 1, the phy init sequence is chosen.

What? Don't make up your own aliases.

If the PHY instances are different, then maybe you need a different 
compatible. If this is just selecting the PHY mode, you can do that in 
PHY cells as the mode depends on the consumer.


> +      properties:
> +        reg:
> +          items:
> +            - description: PHY
> +            - description: PCS

else:
  properties:
    reg:
      maxItems: 1

> +
>  required:
>    - "#phy-cells"
>    - compatible
> -- 
> 2.49.0
>
RE: [PATCH v2 07/10] dt-bindings: phy: Add PHY bindings support for FSD SoC
Posted by Shradha Todi 3 months, 1 week ago 

> -----Original Message-----
> From: Rob Herring <robh@kernel.org>
> Sent: 28 June 2025 02:47
> To: Shradha Todi <shradha.t@samsung.com>
> Cc: linux-pci@vger.kernel.org; devicetree@vger.kernel.org; linux-arm-kernel@lists.infradead.org;
linux-
> samsung-soc@vger.kernel.org; linux-kernel@vger.kernel.org; linux-phy@lists.infradead.org; linux-
> fsd@tesla.com; manivannan.sadhasivam@linaro.org; lpieralisi@kernel.org; kw@linux.com;
> bhelgaas@google.com; jingoohan1@gmail.com; krzk+dt@kernel.org; conor+dt@kernel.org;
> alim.akhtar@samsung.com; vkoul@kernel.org; kishon@kernel.org; arnd@arndb.de;
> m.szyprowski@samsung.com; jh80.chung@samsung.com; pankaj.dubey@samsung.com
> Subject: Re: [PATCH v2 07/10] dt-bindings: phy: Add PHY bindings support for FSD SoC
> 
> On Wed, Jun 25, 2025 at 10:22:26PM +0530, Shradha Todi wrote:
> > Document PHY device tree bindings for Tesla FSD SoCs.
> >
> > Signed-off-by: Shradha Todi <shradha.t@samsung.com>
> > ---
> >  .../bindings/phy/samsung,exynos-pcie-phy.yaml | 25 +++++++++++++++++--
> >  1 file changed, 23 insertions(+), 2 deletions(-)
> >
> > diff --git a/Documentation/devicetree/bindings/phy/samsung,exynos-pcie-phy.yaml
> b/Documentation/devicetree/bindings/phy/samsung,exynos-pcie-phy.yaml
> > index 41df8bb08ff7..4dc20156cdde 100644
> > --- a/Documentation/devicetree/bindings/phy/samsung,exynos-pcie-phy.yaml
> > +++ b/Documentation/devicetree/bindings/phy/samsung,exynos-pcie-phy.yaml
> > @@ -15,10 +15,13 @@ properties:
> >      const: 0
> >
> >    compatible:
> > -    const: samsung,exynos5433-pcie-phy
> > +    enum:
> > +      - samsung,exynos5433-pcie-phy
> > +      - tesla,fsd-pcie-phy
> >
> >    reg:
> > -    maxItems: 1
> > +    minItems: 1
> > +    maxItems: 2
> >
> >    samsung,pmu-syscon:
> >      $ref: /schemas/types.yaml#/definitions/phandle
> > @@ -30,6 +33,24 @@ properties:
> >      description: phandle for FSYS sysreg interface, used to control
> >                   sysreg registers bits for PCIe PHY
> >
> > +allOf:
> > +  - if:
> > +      properties:
> > +        compatible:
> > +          contains:
> > +            enum:
> > +              - tesla,fsd-pcie-phy
> > +    then:
> > +      description:
> > +        The PHY controller nodes are represented in the aliases node
> > +        using the following format 'pciephy{n}'. Depending on whether
> > +        n is 0 or 1, the phy init sequence is chosen.
> 
> What? Don't make up your own aliases.
> 
> If the PHY instances are different, then maybe you need a different
> compatible. If this is just selecting the PHY mode, you can do that in
> PHY cells as the mode depends on the consumer.
> 

FSD PCIe has 2 instances of PHY. Both are the same HW Samsung
PHYs (Therefore share the same register offsets). But the PHY used here
does not support auto adaptation so we need to tune the PHYs
according to the use case (considering channel loss, etc). This is why we
have 2 different SW PHY initialization sequence depending on the instance
number. Do you think having different compatible (something like
tesla,fsd-pcie-phy0 and tesla,fsd-pcie-phy1) and having phy ID as platform data
is okay in this case? I actually took reference from files like:
drivers/usb/phy/phy-am335x-control.c
drivers/phy/freescale/phy-fsl-imx8-mipi-dphy.c
who use alias to differentiate between register offsets for instances.

> 
> > +      properties:
> > +        reg:
> > +          items:
> > +            - description: PHY
> > +            - description: PCS
> 
> else:
>   properties:
>     reg:
>       maxItems: 1
> 

Will update. Thanks for the review!

> > +
> >  required:
> >    - "#phy-cells"
> >    - compatible
> > --
> > 2.49.0
> >
Re: [PATCH v2 07/10] dt-bindings: phy: Add PHY bindings support for FSD SoC
Posted by Krzysztof Kozlowski 3 months, 1 week ago 
On 01/07/2025 13:06, Shradha Todi wrote:
> 
> 
>> -----Original Message-----
>> From: Rob Herring <robh@kernel.org>
>> Sent: 28 June 2025 02:47
>> To: Shradha Todi <shradha.t@samsung.com>
>> Cc: linux-pci@vger.kernel.org; devicetree@vger.kernel.org; linux-arm-kernel@lists.infradead.org;
> linux-
>> samsung-soc@vger.kernel.org; linux-kernel@vger.kernel.org; linux-phy@lists.infradead.org; linux-
>> fsd@tesla.com; manivannan.sadhasivam@linaro.org; lpieralisi@kernel.org; kw@linux.com;
>> bhelgaas@google.com; jingoohan1@gmail.com; krzk+dt@kernel.org; conor+dt@kernel.org;
>> alim.akhtar@samsung.com; vkoul@kernel.org; kishon@kernel.org; arnd@arndb.de;
>> m.szyprowski@samsung.com; jh80.chung@samsung.com; pankaj.dubey@samsung.com
>> Subject: Re: [PATCH v2 07/10] dt-bindings: phy: Add PHY bindings support for FSD SoC
>>
>> On Wed, Jun 25, 2025 at 10:22:26PM +0530, Shradha Todi wrote:
>>> Document PHY device tree bindings for Tesla FSD SoCs.
>>>
>>> Signed-off-by: Shradha Todi <shradha.t@samsung.com>
>>> ---
>>>  .../bindings/phy/samsung,exynos-pcie-phy.yaml | 25 +++++++++++++++++--
>>>  1 file changed, 23 insertions(+), 2 deletions(-)
>>>
>>> diff --git a/Documentation/devicetree/bindings/phy/samsung,exynos-pcie-phy.yaml
>> b/Documentation/devicetree/bindings/phy/samsung,exynos-pcie-phy.yaml
>>> index 41df8bb08ff7..4dc20156cdde 100644
>>> --- a/Documentation/devicetree/bindings/phy/samsung,exynos-pcie-phy.yaml
>>> +++ b/Documentation/devicetree/bindings/phy/samsung,exynos-pcie-phy.yaml
>>> @@ -15,10 +15,13 @@ properties:
>>>      const: 0
>>>
>>>    compatible:
>>> -    const: samsung,exynos5433-pcie-phy
>>> +    enum:
>>> +      - samsung,exynos5433-pcie-phy
>>> +      - tesla,fsd-pcie-phy
>>>
>>>    reg:
>>> -    maxItems: 1
>>> +    minItems: 1
>>> +    maxItems: 2
>>>
>>>    samsung,pmu-syscon:
>>>      $ref: /schemas/types.yaml#/definitions/phandle
>>> @@ -30,6 +33,24 @@ properties:
>>>      description: phandle for FSYS sysreg interface, used to control
>>>                   sysreg registers bits for PCIe PHY
>>>
>>> +allOf:
>>> +  - if:
>>> +      properties:
>>> +        compatible:
>>> +          contains:
>>> +            enum:
>>> +              - tesla,fsd-pcie-phy
>>> +    then:
>>> +      description:
>>> +        The PHY controller nodes are represented in the aliases node
>>> +        using the following format 'pciephy{n}'. Depending on whether
>>> +        n is 0 or 1, the phy init sequence is chosen.
>>
>> What? Don't make up your own aliases.
>>
>> If the PHY instances are different, then maybe you need a different
>> compatible. If this is just selecting the PHY mode, you can do that in
>> PHY cells as the mode depends on the consumer.
>>
> 
> FSD PCIe has 2 instances of PHY. Both are the same HW Samsung
> PHYs (Therefore share the same register offsets). But the PHY used here

So same?

> does not support auto adaptation so we need to tune the PHYs
> according to the use case (considering channel loss, etc). This is why we

So not same? Decide. Either it is same or not, cannot be both.

If you mean that some wiring is different on the board, then how does it
differ in soc thus how it is per-soc property? If these are use-cases,
then how is even suitable for DT?

I use your Tesla FSD differently and then I exchange DTSI and compatibles?

You are no describing real problem and both binding and your
explanations are vague and imprecise. Binding tells nothing about it, so
it is example of skipping important decisions.

> have 2 different SW PHY initialization sequence depending on the instance
> number. Do you think having different compatible (something like
> tesla,fsd-pcie-phy0 and tesla,fsd-pcie-phy1) and having phy ID as platform data
> is okay in this case? I actually took reference from files like:

And in different use case on same soc you are going to reverse
compatibles or instance IDs?

> drivers/usb/phy/phy-am335x-control.c

So you took 15 years old hardware, code and binding as an example.

No, don't do that ever.

Anyway, poor choices even in newer code should not drive your design.
Design it properly, describe the hardware.

> drivers/phy/freescale/phy-fsl-imx8-mipi-dphy.c
> who use alias to differentiate between register offsets for instances.



Best regards,
Krzysztof
RE: [PATCH v2 07/10] dt-bindings: phy: Add PHY bindings support for FSD SoC
Posted by Shradha Todi 3 months, 1 week ago 

> -----Original Message-----
> From: Krzysztof Kozlowski <krzk@kernel.org>
> Sent: 01 July 2025 16:55
> To: Shradha Todi <shradha.t@samsung.com>; 'Rob Herring' <robh@kernel.org>
> Cc: linux-pci@vger.kernel.org; devicetree@vger.kernel.org; linux-arm-kernel@lists.infradead.org; linux-
> samsung-soc@vger.kernel.org; linux-kernel@vger.kernel.org; linux-phy@lists.infradead.org; linux-
> fsd@tesla.com; mani@kernel.org; lpieralisi@kernel.org; kw@linux.com; bhelgaas@google.com;
> jingoohan1@gmail.com; krzk+dt@kernel.org; conor+dt@kernel.org; alim.akhtar@samsung.com;
> vkoul@kernel.org; kishon@kernel.org; arnd@arndb.de; m.szyprowski@samsung.com;
> jh80.chung@samsung.com; pankaj.dubey@samsung.com
> Subject: Re: [PATCH v2 07/10] dt-bindings: phy: Add PHY bindings support for FSD SoC
> 
> On 01/07/2025 13:06, Shradha Todi wrote:
> >
> >
> >> -----Original Message-----
> >> From: Rob Herring <robh@kernel.org>
> >> Sent: 28 June 2025 02:47
> >> To: Shradha Todi <shradha.t@samsung.com>
> >> Cc: linux-pci@vger.kernel.org; devicetree@vger.kernel.org; linux-arm-kernel@lists.infradead.org;
> > linux-
> >> samsung-soc@vger.kernel.org; linux-kernel@vger.kernel.org; linux-phy@lists.infradead.org; linux-
> >> fsd@tesla.com; manivannan.sadhasivam@linaro.org; lpieralisi@kernel.org; kw@linux.com;
> >> bhelgaas@google.com; jingoohan1@gmail.com; krzk+dt@kernel.org; conor+dt@kernel.org;
> >> alim.akhtar@samsung.com; vkoul@kernel.org; kishon@kernel.org; arnd@arndb.de;
> >> m.szyprowski@samsung.com; jh80.chung@samsung.com; pankaj.dubey@samsung.com
> >> Subject: Re: [PATCH v2 07/10] dt-bindings: phy: Add PHY bindings support for FSD SoC
> >>
> >> On Wed, Jun 25, 2025 at 10:22:26PM +0530, Shradha Todi wrote:
> >>> Document PHY device tree bindings for Tesla FSD SoCs.
> >>>
> >>> Signed-off-by: Shradha Todi <shradha.t@samsung.com>
> >>> ---
> >>>  .../bindings/phy/samsung,exynos-pcie-phy.yaml | 25 +++++++++++++++++--
> >>>  1 file changed, 23 insertions(+), 2 deletions(-)
> >>>
> >>> diff --git a/Documentation/devicetree/bindings/phy/samsung,exynos-pcie-phy.yaml
> >> b/Documentation/devicetree/bindings/phy/samsung,exynos-pcie-phy.yaml
> >>> index 41df8bb08ff7..4dc20156cdde 100644
> >>> --- a/Documentation/devicetree/bindings/phy/samsung,exynos-pcie-phy.yaml
> >>> +++ b/Documentation/devicetree/bindings/phy/samsung,exynos-pcie-phy.yaml
> >>> @@ -15,10 +15,13 @@ properties:
> >>>      const: 0
> >>>
> >>>    compatible:
> >>> -    const: samsung,exynos5433-pcie-phy
> >>> +    enum:
> >>> +      - samsung,exynos5433-pcie-phy
> >>> +      - tesla,fsd-pcie-phy
> >>>
> >>>    reg:
> >>> -    maxItems: 1
> >>> +    minItems: 1
> >>> +    maxItems: 2
> >>>
> >>>    samsung,pmu-syscon:
> >>>      $ref: /schemas/types.yaml#/definitions/phandle
> >>> @@ -30,6 +33,24 @@ properties:
> >>>      description: phandle for FSYS sysreg interface, used to control
> >>>                   sysreg registers bits for PCIe PHY
> >>>
> >>> +allOf:
> >>> +  - if:
> >>> +      properties:
> >>> +        compatible:
> >>> +          contains:
> >>> +            enum:
> >>> +              - tesla,fsd-pcie-phy
> >>> +    then:
> >>> +      description:
> >>> +        The PHY controller nodes are represented in the aliases node
> >>> +        using the following format 'pciephy{n}'. Depending on whether
> >>> +        n is 0 or 1, the phy init sequence is chosen.
> >>
> >> What? Don't make up your own aliases.
> >>
> >> If the PHY instances are different, then maybe you need a different
> >> compatible. If this is just selecting the PHY mode, you can do that in
> >> PHY cells as the mode depends on the consumer.
> >>
> >
> > FSD PCIe has 2 instances of PHY. Both are the same HW Samsung
> > PHYs (Therefore share the same register offsets). But the PHY used here
> 
> So same?
> 
> > does not support auto adaptation so we need to tune the PHYs
> > according to the use case (considering channel loss, etc). This is why we
> 
> So not same? Decide. Either it is same or not, cannot be both.
> 
> If you mean that some wiring is different on the board, then how does it
> differ in soc thus how it is per-soc property? If these are use-cases,
> then how is even suitable for DT?
> 
> I use your Tesla FSD differently and then I exchange DTSI and compatibles?
> 
> You are no describing real problem and both binding and your
> explanations are vague and imprecise. Binding tells nothing about it, so
> it is example of skipping important decisions.
> 
> > have 2 different SW PHY initialization sequence depending on the instance
> > number. Do you think having different compatible (something like
> > tesla,fsd-pcie-phy0 and tesla,fsd-pcie-phy1) and having phy ID as platform data
> > is okay in this case? I actually took reference from files like:
> 
> And in different use case on same soc you are going to reverse
> compatibles or instance IDs?
>

Even though both the PHYs are exactly identical in terms of hardware,
they need to be programmed/initialized/configured differently.

Sorry for my misuse of the word "use-case". To clarify, these configurations
will always remain the same for FSD SoC even if you use it differently.

I will use different compatibles for them as I understand that it is the best
option.
 
> > drivers/usb/phy/phy-am335x-control.c
> 
> So you took 15 years old hardware, code and binding as an example.
> 
> No, don't do that ever.
> 
> Anyway, poor choices even in newer code should not drive your design.
> Design it properly, describe the hardware.
> 
> > drivers/phy/freescale/phy-fsl-imx8-mipi-dphy.c
> > who use alias to differentiate between register offsets for instances.
> 
> 
> 
> Best regards,
> Krzysztof
Re: [PATCH v2 07/10] dt-bindings: phy: Add PHY bindings support for FSD SoC
Posted by Krzysztof Kozlowski 3 months, 1 week ago 
On 01/07/2025 15:35, Shradha Todi wrote:
>>> does not support auto adaptation so we need to tune the PHYs
>>> according to the use case (considering channel loss, etc). This is why we
>>
>> So not same? Decide. Either it is same or not, cannot be both.
>>
>> If you mean that some wiring is different on the board, then how does it
>> differ in soc thus how it is per-soc property? If these are use-cases,
>> then how is even suitable for DT?
>>
>> I use your Tesla FSD differently and then I exchange DTSI and compatibles?
>>
>> You are no describing real problem and both binding and your
>> explanations are vague and imprecise. Binding tells nothing about it, so
>> it is example of skipping important decisions.
>>
>>> have 2 different SW PHY initialization sequence depending on the instance
>>> number. Do you think having different compatible (something like
>>> tesla,fsd-pcie-phy0 and tesla,fsd-pcie-phy1) and having phy ID as platform data
>>> is okay in this case? I actually took reference from files like:
>>
>> And in different use case on same soc you are going to reverse
>> compatibles or instance IDs?
>>
> 
> Even though both the PHYs are exactly identical in terms of hardware,
> they need to be programmed/initialized/configured differently.
> 
> Sorry for my misuse of the word "use-case". To clarify, these configurations
> will always remain the same for FSD SoC even if you use it differently.
> 
> I will use different compatibles for them as I understand that it is the best
> option.

I still do not see the difference in hardware explained.

Best regards,
Krzysztof
RE: [PATCH v2 07/10] dt-bindings: phy: Add PHY bindings support for FSD SoC
Posted by Pankaj Dubey 3 months ago 

> -----Original Message-----
> From: Krzysztof Kozlowski <krzk@kernel.org>
> Sent: Thursday, July 3, 2025 1:48 AM
> To: Shradha Todi <shradha.t@samsung.com>; 'Rob Herring'
> <robh@kernel.org>
> Cc: linux-pci@vger.kernel.org; devicetree@vger.kernel.org; linux-arm-
> kernel@lists.infradead.org; linux-samsung-soc@vger.kernel.org; linux-
> kernel@vger.kernel.org; linux-phy@lists.infradead.org; linux-fsd@tesla.com;
> mani@kernel.org; lpieralisi@kernel.org; kw@linux.com;
> bhelgaas@google.com; jingoohan1@gmail.com; krzk+dt@kernel.org;
> conor+dt@kernel.org; alim.akhtar@samsung.com; vkoul@kernel.org;
> kishon@kernel.org; arnd@arndb.de; m.szyprowski@samsung.com;
> jh80.chung@samsung.com; pankaj.dubey@samsung.com
> Subject: Re: [PATCH v2 07/10] dt-bindings: phy: Add PHY bindings support for
> FSD SoC
> 
> On 01/07/2025 15:35, Shradha Todi wrote:
> >>> does not support auto adaptation so we need to tune the PHYs
> >>> according to the use case (considering channel loss, etc). This is
> >>> why we
> >>
> >> So not same? Decide. Either it is same or not, cannot be both.
> >>
> >> If you mean that some wiring is different on the board, then how does
> >> it differ in soc thus how it is per-soc property? If these are
> >> use-cases, then how is even suitable for DT?
> >>
> >> I use your Tesla FSD differently and then I exchange DTSI and compatibles?
> >>
> >> You are no describing real problem and both binding and your
> >> explanations are vague and imprecise. Binding tells nothing about it,
> >> so it is example of skipping important decisions.
> >>
> >>> have 2 different SW PHY initialization sequence depending on the
> >>> instance number. Do you think having different compatible (something
> >>> like
> >>> tesla,fsd-pcie-phy0 and tesla,fsd-pcie-phy1) and having phy ID as
> >>> platform data is okay in this case? I actually took reference from files like:
> >>
> >> And in different use case on same soc you are going to reverse
> >> compatibles or instance IDs?
> >>
> >
> > Even though both the PHYs are exactly identical in terms of hardware,
> > they need to be programmed/initialized/configured differently.
> >
> > Sorry for my misuse of the word "use-case". To clarify, these
> > configurations will always remain the same for FSD SoC even if you use it
> differently.
> >
> > I will use different compatibles for them as I understand that it is
> > the best option.
> 
> I still do not see the difference in hardware explained.
> 

Hi Krzysztof 

Let me add more details and see if that makes sense to understand the intention
behind the current design of the PHY driver.

In FSD SoC, the two PHY instances, although having identical hardware design and
register maps, are placed in different locations (Placement and routing) inside the
SoC and have distinct PHY-to-Controller topologies. 

One instance is connected to two PCIe controllers, while the other is connected to
only one. As a result, they experience different analog environments, including
varying channel losses and noise profiles.

Since these PHYs lack internal adaptation mechanisms and f/w based tuning,
manual register programming is required for analog tuning, such as equalization,
de-emphasis, and gain. To ensure optimal signal integrity, it is essential to use different
register values for each PHY instance, despite their identical hardware design.
This is because the same register values may not be suitable for both instances due to
their differing environments and topologies.

Do let us know if this explains the intention behind separate programming sequence
for both instance of the PHY?

Thanks,
Pankaj Dubey
> Best regards,
> Krzysztof
Re: [PATCH v2 07/10] dt-bindings: phy: Add PHY bindings support for FSD SoC
Posted by Krzysztof Kozlowski 3 months ago 
On 04/07/2025 15:09, Pankaj Dubey wrote:
> 
> 
>> -----Original Message-----
>> From: Krzysztof Kozlowski <krzk@kernel.org>
>> Sent: Thursday, July 3, 2025 1:48 AM
>> To: Shradha Todi <shradha.t@samsung.com>; 'Rob Herring'
>> <robh@kernel.org>
>> Cc: linux-pci@vger.kernel.org; devicetree@vger.kernel.org; linux-arm-
>> kernel@lists.infradead.org; linux-samsung-soc@vger.kernel.org; linux-
>> kernel@vger.kernel.org; linux-phy@lists.infradead.org; linux-fsd@tesla.com;
>> mani@kernel.org; lpieralisi@kernel.org; kw@linux.com;
>> bhelgaas@google.com; jingoohan1@gmail.com; krzk+dt@kernel.org;
>> conor+dt@kernel.org; alim.akhtar@samsung.com; vkoul@kernel.org;
>> kishon@kernel.org; arnd@arndb.de; m.szyprowski@samsung.com;
>> jh80.chung@samsung.com; pankaj.dubey@samsung.com
>> Subject: Re: [PATCH v2 07/10] dt-bindings: phy: Add PHY bindings support for
>> FSD SoC
>>
>> On 01/07/2025 15:35, Shradha Todi wrote:
>>>>> does not support auto adaptation so we need to tune the PHYs
>>>>> according to the use case (considering channel loss, etc). This is
>>>>> why we
>>>>
>>>> So not same? Decide. Either it is same or not, cannot be both.
>>>>
>>>> If you mean that some wiring is different on the board, then how does
>>>> it differ in soc thus how it is per-soc property? If these are
>>>> use-cases, then how is even suitable for DT?
>>>>
>>>> I use your Tesla FSD differently and then I exchange DTSI and compatibles?
>>>>
>>>> You are no describing real problem and both binding and your
>>>> explanations are vague and imprecise. Binding tells nothing about it,
>>>> so it is example of skipping important decisions.
>>>>
>>>>> have 2 different SW PHY initialization sequence depending on the
>>>>> instance number. Do you think having different compatible (something
>>>>> like
>>>>> tesla,fsd-pcie-phy0 and tesla,fsd-pcie-phy1) and having phy ID as
>>>>> platform data is okay in this case? I actually took reference from files like:
>>>>
>>>> And in different use case on same soc you are going to reverse
>>>> compatibles or instance IDs?
>>>>
>>>
>>> Even though both the PHYs are exactly identical in terms of hardware,
>>> they need to be programmed/initialized/configured differently.
>>>
>>> Sorry for my misuse of the word "use-case". To clarify, these
>>> configurations will always remain the same for FSD SoC even if you use it
>> differently.
>>>
>>> I will use different compatibles for them as I understand that it is
>>> the best option.
>>
>> I still do not see the difference in hardware explained.
>>
> 
> Hi Krzysztof 
> 
> Let me add more details and see if that makes sense to understand the intention
> behind the current design of the PHY driver.
> 
> In FSD SoC, the two PHY instances, although having identical hardware design and
> register maps, are placed in different locations (Placement and routing) inside the
> SoC and have distinct PHY-to-Controller topologies. 
> 
> One instance is connected to two PCIe controllers, while the other is connected to
> only one. As a result, they experience different analog environments, including
> varying channel losses and noise profiles.
> 
> Since these PHYs lack internal adaptation mechanisms and f/w based tuning,
> manual register programming is required for analog tuning, such as equalization,
> de-emphasis, and gain. To ensure optimal signal integrity, it is essential to use different
> register values for each PHY instance, despite their identical hardware design.
> This is because the same register values may not be suitable for both instances due to
> their differing environments and topologies.
> 
> Do let us know if this explains the intention behind separate programming sequence
> for both instance of the PHY?
Thanks, it explains and it should be in binding description if you go
with different compatible, but you should first check if existing
properties do not describe these differences enough, e.g. num-lanes,
max-link-speed.

equalization has its own properties for example.

Best regards,
Krzysztof

Patchew 2.1-devel-b67e4c2

© 2016 - 2025 Red Hat, Inc.