new file mode 100644
@@ -0,0 +1,248 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/phy/fsl,lynx-10g.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: NXP Lynx 10G SerDes
+
+maintainers:
+ - Sean Anderson <sean.anderson@seco.com>
+
+description: |
+ These Lynx "SerDes" devices are found in NXP's QorIQ line of processors. The
+ SerDes provides up to eight lanes. Each lane may be configured individually,
+ or may be combined with adjacent lanes for a multi-lane protocol. The SerDes
+ supports a variety of protocols, including up to 10G Ethernet, PCIe, SATA, and
+ others. The specific protocols supported for each lane depend on the
+ particular SoC.
+
+properties:
+ compatible:
+ items:
+ - enum:
+ - fsl,ls1046a-serdes
+ - fsl,ls1088a-serdes
+ - const: fsl,lynx-10g
+
+ "#address-cells":
+ const: 1
+
+ "#size-cells":
+ const: 0
+
+ "#clock-cells":
+ const: 1
+ description: |
+ The cell contains an ID as described in dt-bindings/clock/fsl,lynx-10g.h.
+ Note that when assigning a rate to a PLL, the PLL's rate is divided by
+ 1000 to avoid overflow. A rate of 5000000 corresponds to 5GHz.
+
+ clocks:
+ maxItems: 2
+ description: |
+ Clock for each PLL reference clock input.
+
+ clock-names:
+ minItems: 2
+ maxItems: 2
+ items:
+ enum:
+ - ref0
+ - ref1
+
+ fsl,unused-lanes-reserved:
+ $ref: /schemas/types.yaml#/definitions/flag
+ description: |
+ Unused lanes are reserved for firmware use, and should not be disabled.
+ Normally, groups containing unused lanes may be reconfigured or disabled
+ to save power. However, when this property is present, unused lanes will
+ not be touched until they are used by another driver. This allows
+ migrating from firmware control of lanes to driver control.
+
+ Lanes not present in any group will never be modified, regardless of the
+ presence of this property.
+
+ reg:
+ maxItems: 1
+
+patternProperties:
+ "^phy@":
+ type: object
+
+ description: |
+ A contiguous group of lanes which will be configured together. Each group
+ corresponds to one phy device. Lanes not described by any group will be
+ left as-is.
+
+ properties:
+ "#phy-cells":
+ const: 0
+
+ reg:
+ minItems: 1
+ maxItems: 8
+ description:
+ The lanes in the group. These must be listed in order. The first lane
+ will have the FIRST_LANE bit set in GCR0. The order of lanes also
+ determines the reset order (TRSTDIR).
+
+ patternProperties:
+ "^(q?sgmii|xfi)":
+ type: object
+
+ description: |
+ A protocol controller which may control the group of lanes. Each
+ controller is selected through the PCCRs. In addition to protocols
+ desired for use by the OS, protocols which may have been configured
+ by the bootloader must also be described. This ensures that only one
+ protocol controller is attached to a group of lanes at once.
+
+ properties:
+ fsl,pccr:
+ $ref: /schemas/types.yaml#/definitions/uint32
+ description: |
+ The index of the PCCR which configures this protocol controller.
+ This is the same as the register name suffix. For example, PCCR8
+ would use a value of 8 for an offset of 0x220 (0x200 + 4 * 8).
+
+ fsl,index:
+ $ref: /schemas/types.yaml#/definitions/uint32
+ description: |
+ The index of the protocol controller. This corresponds to the
+ suffix in the documentation. For example, PEXa would be 0, PEXb
+ 1, etc. Generally, higher fields occupy lower bits.
+
+ fsl,cfg:
+ $ref: /schemas/types.yaml#/definitions/uint32
+ minimum: 1
+ description: |
+ The configuration value to program into the protocol controller
+ field.
+
+ fsl,type:
+ $ref: /schemas/types.yaml#/definitions/uint32
+ enum:
+ - 8 # PHY_TYPE_SGMII
+ - 9 # PHY_TYPE_QSGMII
+ - 13 # PHY_TYPE_2500BASEX
+ - 14 # PHY_TYPE_10GBASER
+ description: |
+ The category of protocols supported by this controller. See
+ "dt-bindings/phy/phy.h" for the relevant definitions. Individual
+ protocols are selected by the phy consumer. The availability of
+ 1000BASE-KX and 10GBASE-KR depends on the SoC.
+
+ - PHY_TYPE_SGMII: 1000BASE-X, SGMII, and 1000BASE-KX
+ - PHY_TYPE_2500BASEX: 2500BASE-X, 1000BASE-X, SGMII, and
+ 1000BASE-KX
+ - PHY_TYPE_QSGMII: QSGMII
+ - PHY_TYPE_10GBASER: 10GBASE-R and 10GBASE-KR
+
+ required:
+ - fsl,pccr
+ - fsl,index
+ - fsl,cfg
+ - fsl,type
+
+ additionalProperties: false
+
+ required:
+ - "#phy-cells"
+ - reg
+
+ additionalProperties: false
+
+required:
+ - "#address-cells"
+ - "#clock-cells"
+ - "#size-cells"
+ - compatible
+ - clocks
+ - clock-names
+ - reg
+
+additionalProperties: false
+
+examples:
+ - |
+ #include <dt-bindings/phy/phy.h>
+
+ serdes1: serdes@1ea0000 {
+ #address-cells = <1>;
+ #size-cells = <0>;
+ #clock-cells = <1>;
+ compatible = "fsl,ls1046a-serdes", "fsl,lynx-10g";
+ reg = <0x1ea0000 0x2000>;
+ clocks = <&clk_100mhz>, <&clk_156mhz>;
+ clock-names = "ref0", "ref1";
+
+ serdes1_0: phy@0 {
+ #phy-cells = <0>;
+ reg = <0>;
+
+ /* SGMII.6 */
+ sgmii-0 {
+ fsl,pccr = <0x8>;
+ fsl,index = <0>;
+ fsl,cfg = <0x1>;
+ fsl,type = <PHY_TYPE_SGMII>;
+ };
+ };
+
+ serdes1_1: phy@1 {
+ #phy-cells = <0>;
+ reg = <1>;
+
+ /* SGMII.5 */
+ sgmii-1 {
+ fsl,pccr = <0x8>;
+ fsl,index = <1>;
+ fsl,cfg = <0x1>;
+ fsl,type = <PHY_TYPE_2500BASEX>;
+ };
+ };
+
+ serdes1_2: phy@2 {
+ #phy-cells = <0>;
+ reg = <2>;
+
+ /* SGMII.10 */
+ sgmii-2 {
+ fsl,pccr = <0x8>;
+ fsl,index = <2>;
+ fsl,cfg = <0x1>;
+ fsl,type = <PHY_TYPE_2500BASEX>;
+ };
+
+ /* XFI.10 */
+ xfi-0 {
+ fsl,pccr = <0xb>;
+ fsl,index = <0>;
+ fsl,cfg = <0x2>;
+ fsl,type = <PHY_TYPE_10GBASER>;
+ };
+ };
+
+ serdes1_3: phy@3 {
+ #phy-cells = <0>;
+ reg = <3>;
+
+ /* SGMII.9 */
+ sgmii-3 {
+ fsl,pccr = <0x8>;
+ fsl,index = <3>;
+ fsl,cfg = <0x1>;
+ fsl,type = <PHY_TYPE_2500BASEX>;
+ };
+
+ /* XFI.9 */
+ xfi-1 {
+ fsl,pccr = <0xb>;
+ fsl,index = <1>;
+ fsl,cfg = <0x1>;
+ fsl,type = <PHY_TYPE_10GBASER>;
+ };
+ };
+ };
+...
This adds a binding for the SerDes module found on QorIQ processors. Each phy is a subnode of the top-level device, possibly supporting multiple lanes and protocols. This "thick" #phy-cells is used due to allow for better organization of parameters. Note that the particular parameters necessary to select a protocol-controller/lane combination vary across different SoCs, and even within different SerDes on the same SoC. The driver is designed to be able to completely reconfigure lanes at runtime. Generally, the phy consumer can select the appropriate protocol using set_mode. There are two PLLs, each of which can be used as the master clock for each lane. Each PLL has its own reference. For the moment they are required, because it simplifies the driver implementation. Absent reference clocks can be modeled by a fixed-clock with a rate of 0. Signed-off-by: Sean Anderson <sean.anderson@seco.com> --- (no changes since v9) Changes in v9: - Add fsl,unused-lanes-reserved to allow for a gradual transition between firmware and Linux control of the SerDes - Change phy-type back to fsl,type, as I was getting the error '#phy-cells' is a dependency of 'phy-type' Changes in v7: - Use double quotes everywhere in yaml Changes in v6: - fsl,type -> phy-type Changes in v4: - Use subnodes to describe lane configuration, instead of describing PCCRs. This is the same style used by phy-cadence-sierra et al. Changes in v3: - Manually expand yaml references - Add mode configuration to device tree Changes in v2: - Rename to fsl,lynx-10g.yaml - Refer to the device in the documentation, rather than the binding - Move compatible first - Document phy cells in the description - Allow a value of 1 for phy-cells. This allows for compatibility with the similar (but according to Ioana Ciornei different enough) lynx-28g binding. - Remove minItems - Use list for clock-names - Fix example binding having too many cells in regs - Add #clock-cells. This will allow using assigned-clocks* to configure the PLLs. - Document the structure of the compatible strings .../devicetree/bindings/phy/fsl,lynx-10g.yaml | 248 ++++++++++++++++++ 1 file changed, 248 insertions(+) create mode 100644 Documentation/devicetree/bindings/phy/fsl,lynx-10g.yaml