[PATCH v3 0/6] PCI: Enable Power and configure the QPS615 PCIe switch

[PATCH v3 0/6] PCI: Enable Power and configure the QPS615 PCIe switch

[Krishna chaitanya chundru]

QPS615 is the PCIe switch which has one upstream and three downstream
ports. To one of the downstream ports ethernet MAC is connected as endpoint
device. Other two downstream ports are supposed to connect to external
device. One Host can connect to QPS615 by upstream port.

QPS615 switch power is controlled by the GPIO's. After powering on
the switch will immediately participate in the link training. if the
host is also ready by that time PCIe link will established. 

The QPS615 needs to configured certain parameters like de-emphasis,
disable unused port etc before link is established.

As the controller starts link training before the probe of pwrctl driver,
the PCIe link may come up as soon as we power on the switch. Due to this
configuring the switch itself through i2c will not have any effect as
this configuration needs to done before link training. To avoid this
introduce two functions in pci_ops to start_link() & stop_link() which
will disable the link training if the PCIe link is not up yet.

Signed-off-by: Krishna chaitanya chundru <quic_krichai@quicinc.com>
---
Changes in v2:
- As per offline discussions with rob i2c-parent is best suitable to
  use i2c client device. So use i2c-parent as suggested and remove i2c
  client node reference from the dt-bindings & devicetree.
- Remove "PCI: Change the parent to correctly represent pcie hierarchy"
  as this requires seperate discussions.
- Remove bdf logic to identify the dsp's and usp's to make it generic
  by using the logic that downstream devices will always child of
  upstream node and dsp1, dsp2 will always in same order (dmitry)
- Remove recursive function for parsing devicetree instead parse
  only for required devicetree nodes (dmitry)
- Fix the issue in be & le conversion (dmitry).
- Call put_device for i2c device once done with the usage (dmitry)
- Use $defs to describe common properties between upstream port and
  downstream properties. and remove unneccessary if then. (Krzysztof)
- Place the qcom,qps615 compatibility in dt-binding document in alphabatic order (Krzysztof)
- Rename qcom,no-dfe to describe it as hardware capability and change
  qcom,nfts description to reflect hardware details (Krzysztof)
- Fix the indentation in the example in dt binding (dmitry)
- Add more description to qcom,nfts (dmitry)
- Remove nanosec from the property description (dmitry)
- Link to v2: https://lore.kernel.org/r/linux-arm-msm/20240803-qps615-v2-0-9560b7c71369@quicinc.com/T/
Changes in v1:
- Instead of referencing whole i2c-bus add i2c-client node and reference it (Dmitry)
- Change the regulator's as per the schematics as per offline review
(bjorn Andresson)
- Remove additional host check in bus.c (Bart)
- For stop_link op change return type from int to void (Bart)
- Remove firmware based approach for configuring sequence as suggested
by multiple reviewers.
- Introduce new dt-properties for the switch to configure the switch
as we are replacing the firmware based approach.
- The downstream ports add properties in the child nodes which will
represented in PCIe hierarchy format.
- Removed D3cold D0 sequence in suspend resume for now as it needs
separate discussion.
- Link to v1: https://lore.kernel.org/linux-pci/20240626-qps615-v1-4-2ade7bd91e02@quicinc.com/T/

---
Krishna chaitanya chundru (6):
      dt-bindings: PCI: Add binding for qps615
      arm64: dts: qcom: qcs6490-rb3gen2: Add node for qps615
      PCI: Add new start_link() & stop_link function ops
      PCI: dwc: Add support for new pci function op
      PCI: qcom: Add support for host_stop_link() & host_start_link()
      PCI: pwrctl: Add power control driver for qps615

 .../devicetree/bindings/pci/qcom,qps615.yaml       | 205 +++++++
 arch/arm64/boot/dts/qcom/qcs6490-rb3gen2.dts       | 115 ++++
 arch/arm64/boot/dts/qcom/sc7280.dtsi               |   2 +-
 drivers/pci/controller/dwc/pcie-designware-host.c  |  18 +
 drivers/pci/controller/dwc/pcie-designware.h       |  16 +
 drivers/pci/controller/dwc/pcie-qcom.c             |  39 ++
 drivers/pci/pwrctl/Kconfig                         |   8 +
 drivers/pci/pwrctl/Makefile                        |   1 +
 drivers/pci/pwrctl/pci-pwrctl-qps615.c             | 630 +++++++++++++++++++++
 include/linux/pci.h                                |   2 +
 10 files changed, 1035 insertions(+), 1 deletion(-)
---
base-commit: ae43de0875223d271eb6004cfb08be697520f55c
change-id: 20241022-qps615_pwr-8d3837f61aec

Best regards,
-- 
Krishna chaitanya chundru <quic_krichai@quicinc.com>

[PATCH v3 1/6] dt-bindings: PCI: Add binding for qps615

[Krishna chaitanya chundru]

Add binding describing the Qualcomm PCIe switch, QPS615,
which provides Ethernet MAC integrated to the 3rd downstream port
and two downstream PCIe ports.

Signed-off-by: Krishna chaitanya chundru <quic_krichai@quicinc.com>
---
 .../devicetree/bindings/pci/qcom,qps615.yaml       | 205 +++++++++++++++++++++
 1 file changed, 205 insertions(+)

diff --git a/Documentation/devicetree/bindings/pci/qcom,qps615.yaml b/Documentation/devicetree/bindings/pci/qcom,qps615.yaml
new file mode 100644
index 000000000000..e6a63a0bb0f3
--- /dev/null
+++ b/Documentation/devicetree/bindings/pci/qcom,qps615.yaml
@@ -0,0 +1,205 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/pci/qcom,qps615.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Qualcomm QPS615 PCIe switch
+
+maintainers:
+  - Krishna chaitanya chundru <quic_krichai@quicinc.com>
+
+description: |
+  Qualcomm QPS615 PCIe switch has one upstream and three downstream
+  ports. The 3rd downstream port has integrated endpoint device of
+  Ethernet MAC. Other two downstream ports are supposed to connect
+  to external device.
+
+  The QPS615 PCIe switch can be configured through I2C interface before
+  PCIe link is established to change FTS, ASPM related entry delays,
+  tx amplitude etc for better power efficiency and functionality.
+
+properties:
+  compatible:
+    enum:
+      - pci1179,0623
+
+  reg:
+    maxItems: 1
+
+  i2c-parent:
+    $ref: /schemas/types.yaml#/definitions/phandle-array
+    description: |
+      A phandle to the parent I2C node and the slave address of the device
+      used to do configure qps615 to change FTS, tx amplitude etc.
+    items:
+      - description: Phandle to the I2C controller node
+      - description: I2C slave address
+
+  vdd18-supply: true
+
+  vdd09-supply: true
+
+  vddc-supply: true
+
+  vddio1-supply: true
+
+  vddio2-supply: true
+
+  vddio18-supply: true
+
+  reset-gpios:
+    maxItems: 1
+    description:
+      GPIO controlling the RESX# pin.
+
+  qps615,axi-clk-freq-hz:
+    description:
+      AXI clock rate which is internal bus of the switch
+      The switch only runs in two frequencies i.e 250MHz and 125MHz.
+    enum: [125000000, 250000000]
+
+allOf:
+  - $ref: "#/$defs/qps615-node"
+
+patternProperties:
+  "@1?[0-9a-f](,[0-7])?$":
+    description: child nodes describing the internal downstream ports
+      the qps615 switch.
+    type: object
+    $ref: "#/$defs/qps615-node"
+    unevaluatedProperties: false
+
+$defs:
+  qps615-node:
+    type: object
+
+    properties:
+      qcom,l0s-entry-delay-ns:
+        description: Aspm l0s entry delay.
+
+      qcom,l1-entry-delay-ns:
+        description: Aspm l1 entry delay.
+
+      qcom,tx-amplitude-millivolt:
+        $ref: /schemas/types.yaml#/definitions/uint32
+        description: Change Tx Margin setting for low power consumption.
+
+      qcom,no-dfe-support:
+        type: boolean
+        description: Disable DFE (Decision Feedback Equalizer), which mitigates
+          intersymbol interference and some reflections caused by impedance mismatches.
+
+      qcom,nfts:
+        $ref: /schemas/types.yaml#/definitions/uint32
+        description:
+          Number of Fast Training Sequence (FTS) used during L0s to L0 exit
+          for bit and Symbol lock.
+
+    allOf:
+      - $ref: /schemas/pci/pci-bus.yaml#
+
+unevaluatedProperties: false
+
+required:
+  - vdd18-supply
+  - vdd09-supply
+  - vddc-supply
+  - vddio1-supply
+  - vddio2-supply
+  - vddio18-supply
+  - i2c-parent
+  - reset-gpios
+
+examples:
+  - |
+
+    #include <dt-bindings/gpio/gpio.h>
+
+    pcie {
+        #address-cells = <3>;
+        #size-cells = <2>;
+
+        pcie@0 {
+            device_type = "pci";
+            reg = <0x0 0x0 0x0 0x0 0x0>;
+
+            #address-cells = <3>;
+            #size-cells = <2>;
+            ranges;
+            bus-range = <0x01 0xff>;
+
+            pcie@0,0 {
+                compatible = "pci1179,0623";
+                reg = <0x10000 0x0 0x0 0x0 0x0>;
+                device_type = "pci";
+                #address-cells = <3>;
+                #size-cells = <2>;
+                ranges;
+                bus-range = <0x02 0xff>;
+
+                i2c-parent = <&qup_i2c 0x77>;
+
+                vdd18-supply = <&vdd>;
+                vdd09-supply = <&vdd>;
+                vddc-supply = <&vdd>;
+                vddio1-supply = <&vdd>;
+                vddio2-supply = <&vdd>;
+                vddio18-supply = <&vdd>;
+
+                reset-gpios = <&gpio 1 GPIO_ACTIVE_LOW>;
+
+                pcie@1,0 {
+                    reg = <0x20800 0x0 0x0 0x0 0x0>;
+                    #address-cells = <3>;
+                    #size-cells = <2>;
+                    device_type = "pci";
+                    ranges;
+                    bus-range = <0x03 0xff>;
+
+                    qcom,no-dfe-support;
+                };
+
+                pcie@2,0 {
+                    reg = <0x21000 0x0 0x0 0x0 0x0>;
+                    #address-cells = <3>;
+                    #size-cells = <2>;
+                    device_type = "pci";
+                    ranges;
+                    bus-range = <0x04 0xff>;
+
+                    qcom,nfts = <10>;
+                };
+
+                pcie@3,0 {
+                    reg = <0x21800 0x0 0x0 0x0 0x0>;
+                    #address-cells = <3>;
+                    #size-cells = <2>;
+                    device_type = "pci";
+                    ranges;
+                    bus-range = <0x05 0xff>;
+
+                    qcom,tx-amplitude-millivolt = <10>;
+                    pcie@0,0 {
+                        reg = <0x50000 0x0 0x0 0x0 0x0>;
+                        #address-cells = <3>;
+                        #size-cells = <2>;
+                        device_type = "pci";
+                        ranges;
+
+                        qcom,l1-entry-delay-ns = <10>;
+                    };
+
+                    pcie@0,1 {
+                        reg = <0x50100 0x0 0x0 0x0 0x0>;
+                        #address-cells = <3>;
+                        #size-cells = <2>;
+                        device_type = "pci";
+                        ranges;
+
+                        qcom,l0s-entry-delay-ns = <10>;
+                    };
+                };
+            };
+        };
+    };

-- 
2.34.1

[PATCH v3 2/6] arm64: dts: qcom: qcs6490-rb3gen2: Add node for qps615

[Krishna chaitanya chundru]

Add QPS615 PCIe switch node which has 3 downstream ports and in one
downstream port two embedded ethernet devices are present.

Power to the QPS615 is supplied through two LDO regulators, controlled
by two GPIOs, these are added as fixed regulators. And the QPS615 is
configured through i2c.

Signed-off-by: Krishna chaitanya chundru <quic_krichai@quicinc.com>
---
 arch/arm64/boot/dts/qcom/qcs6490-rb3gen2.dts | 115 +++++++++++++++++++++++++++
 arch/arm64/boot/dts/qcom/sc7280.dtsi         |   2 +-
 2 files changed, 116 insertions(+), 1 deletion(-)

diff --git a/arch/arm64/boot/dts/qcom/qcs6490-rb3gen2.dts b/arch/arm64/boot/dts/qcom/qcs6490-rb3gen2.dts
index 0d45662b8028..0e890841b600 100644
--- a/arch/arm64/boot/dts/qcom/qcs6490-rb3gen2.dts
+++ b/arch/arm64/boot/dts/qcom/qcs6490-rb3gen2.dts
@@ -202,6 +202,30 @@ vph_pwr: vph-pwr-regulator {
 		regulator-min-microvolt = <3700000>;
 		regulator-max-microvolt = <3700000>;
 	};
+
+	vdd_ntn_0p9: regulator-vdd-ntn-0p9 {
+		compatible = "regulator-fixed";
+		regulator-name = "VDD_NTN_0P9";
+		gpio = <&pm8350c_gpios 2 GPIO_ACTIVE_HIGH>;
+		regulator-min-microvolt = <899400>;
+		regulator-max-microvolt = <899400>;
+		enable-active-high;
+		pinctrl-0 = <&ntn_0p9_en>;
+		pinctrl-names = "default";
+		regulator-enable-ramp-delay = <4300>;
+	};
+
+	vdd_ntn_1p8: regulator-vdd-ntn-1p8 {
+		compatible = "regulator-fixed";
+		regulator-name = "VDD_NTN_1P8";
+		gpio = <&pm8350c_gpios 3 GPIO_ACTIVE_HIGH>;
+		regulator-min-microvolt = <1800000>;
+		regulator-max-microvolt = <1800000>;
+		enable-active-high;
+		pinctrl-0 = <&ntn_1p8_en>;
+		pinctrl-names = "default";
+		regulator-enable-ramp-delay = <10000>;
+	};
 };
 
 &apps_rsc {
@@ -684,6 +708,75 @@ &mdss_edp_phy {
 	status = "okay";
 };
 
+&pcie1_port {
+	pcie@0,0 {
+		compatible = "pci1179,0623";
+		reg = <0x10000 0x0 0x0 0x0 0x0>;
+		#address-cells = <3>;
+		#size-cells = <2>;
+
+		device_type = "pci";
+		ranges;
+		bus-range = <0x2 0xff>;
+
+		vddc-supply = <&vdd_ntn_0p9>;
+		vdd18-supply = <&vdd_ntn_1p8>;
+		vdd09-supply = <&vdd_ntn_0p9>;
+		vddio1-supply = <&vdd_ntn_1p8>;
+		vddio2-supply = <&vdd_ntn_1p8>;
+		vddio18-supply = <&vdd_ntn_1p8>;
+
+		i2c-parent = <&i2c0 0x77>;
+
+		reset-gpios = <&pm8350c_gpios 1 GPIO_ACTIVE_LOW>;
+
+		pcie@1,0 {
+			reg = <0x20800 0x0 0x0 0x0 0x0>;
+			#address-cells = <3>;
+			#size-cells = <2>;
+
+			device_type = "pci";
+			ranges;
+			bus-range = <0x3 0xff>;
+		};
+
+		pcie@2,0 {
+			reg = <0x21000 0x0 0x0 0x0 0x0>;
+			#address-cells = <3>;
+			#size-cells = <2>;
+
+			device_type = "pci";
+			ranges;
+			bus-range = <0x4 0xff>;
+		};
+
+		pcie@3,0 {
+			reg = <0x21800 0x0 0x0 0x0 0x0>;
+			#address-cells = <3>;
+			#size-cells = <2>;
+			device_type = "pci";
+			ranges;
+			bus-range = <0x5 0xff>;
+
+			pcie@0,0 {
+				reg = <0x50000 0x0 0x0 0x0 0x0>;
+				#address-cells = <3>;
+				#size-cells = <2>;
+				device_type = "pci";
+				ranges;
+			};
+
+			pcie@0,1 {
+				reg = <0x50100 0x0 0x0 0x0 0x0>;
+				#address-cells = <3>;
+				#size-cells = <2>;
+				device_type = "pci";
+				ranges;
+			};
+		};
+	};
+};
+
 &pmk8350_rtc {
 	status = "okay";
 };
@@ -812,6 +905,28 @@ lt9611_rst_pin: lt9611-rst-state {
 	};
 };
 
+&pm8350c_gpios {
+	ntn_0p9_en: ntn-0p9-en-state {
+		pins = "gpio2";
+		function = "normal";
+
+		bias-disable;
+		input-disable;
+		output-enable;
+		power-source = <0>;
+	};
+
+	ntn_1p8_en: ntn-1p8-en-state {
+		pins = "gpio3";
+		function = "normal";
+
+		bias-disable;
+		input-disable;
+		output-enable;
+		power-source = <0>;
+	};
+};
+
 &tlmm {
 	lt9611_irq_pin: lt9611-irq-state {
 		pins = "gpio24";
diff --git a/arch/arm64/boot/dts/qcom/sc7280.dtsi b/arch/arm64/boot/dts/qcom/sc7280.dtsi
index 3d8410683402..82434f085ff0 100644
--- a/arch/arm64/boot/dts/qcom/sc7280.dtsi
+++ b/arch/arm64/boot/dts/qcom/sc7280.dtsi
@@ -2279,7 +2279,7 @@ pcie1: pcie@1c08000 {
 
 			status = "disabled";
 
-			pcie@0 {
+			pcie1_port: pcie@0 {
 				device_type = "pci";
 				reg = <0x0 0x0 0x0 0x0 0x0>;
 				bus-range = <0x01 0xff>;

-- 
2.34.1

[PATCH v3 3/6] PCI: Add new start_link() & stop_link function ops

[Krishna chaitanya chundru]

Certain devices like QPS615 which uses PCI pwrctl framework
needs to configure the device before PCI link is up.

If the controller driver already enables link training as part of
its probe, after the device is powered on, controller and device
participates in the link training and link can come up immediately
and maynot have time to configure the device.

So we need to stop the link training by using stop_link() and enable
them back after device is configured by using start_link().

Signed-off-by: Krishna chaitanya chundru <quic_krichai@quicinc.com>
---
 include/linux/pci.h | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/include/linux/pci.h b/include/linux/pci.h
index 573b4c4c2be6..fe6a9b4b22ee 100644
--- a/include/linux/pci.h
+++ b/include/linux/pci.h
@@ -806,6 +806,8 @@ struct pci_ops {
 	void __iomem *(*map_bus)(struct pci_bus *bus, unsigned int devfn, int where);
 	int (*read)(struct pci_bus *bus, unsigned int devfn, int where, int size, u32 *val);
 	int (*write)(struct pci_bus *bus, unsigned int devfn, int where, int size, u32 val);
+	int (*start_link)(struct pci_bus *bus);
+	void (*stop_link)(struct pci_bus *bus);
 };
 
 /*

-- 
2.34.1

[PATCH v3 4/6] PCI: dwc: Add support for new pci function op

[Krishna chaitanya chundru]

Add the support for stop_link() and  start_link() function op.

Signed-off-by: Krishna chaitanya chundru <quic_krichai@quicinc.com>
---
 drivers/pci/controller/dwc/pcie-designware-host.c | 18 ++++++++++++++++++
 drivers/pci/controller/dwc/pcie-designware.h      | 16 ++++++++++++++++
 2 files changed, 34 insertions(+)

diff --git a/drivers/pci/controller/dwc/pcie-designware-host.c b/drivers/pci/controller/dwc/pcie-designware-host.c
index 3e41865c7290..d7e7f782390a 100644
--- a/drivers/pci/controller/dwc/pcie-designware-host.c
+++ b/drivers/pci/controller/dwc/pcie-designware-host.c
@@ -691,10 +691,28 @@ void __iomem *dw_pcie_own_conf_map_bus(struct pci_bus *bus, unsigned int devfn,
 }
 EXPORT_SYMBOL_GPL(dw_pcie_own_conf_map_bus);
 
+static int dw_pcie_op_start_link(struct pci_bus *bus)
+{
+	struct dw_pcie_rp *pp = bus->sysdata;
+	struct dw_pcie *pci = to_dw_pcie_from_pp(pp);
+
+	return dw_pcie_host_start_link(pci);
+}
+
+static void dw_pcie_op_stop_link(struct pci_bus *bus)
+{
+	struct dw_pcie_rp *pp = bus->sysdata;
+	struct dw_pcie *pci = to_dw_pcie_from_pp(pp);
+
+	dw_pcie_host_stop_link(pci);
+}
+
 static struct pci_ops dw_pcie_ops = {
 	.map_bus = dw_pcie_own_conf_map_bus,
 	.read = pci_generic_config_read,
 	.write = pci_generic_config_write,
+	.start_link = dw_pcie_op_start_link,
+	.stop_link = dw_pcie_op_stop_link,
 };
 
 static int dw_pcie_iatu_setup(struct dw_pcie_rp *pp)
diff --git a/drivers/pci/controller/dwc/pcie-designware.h b/drivers/pci/controller/dwc/pcie-designware.h
index 347ab74ac35a..b88b4edafcc3 100644
--- a/drivers/pci/controller/dwc/pcie-designware.h
+++ b/drivers/pci/controller/dwc/pcie-designware.h
@@ -433,6 +433,8 @@ struct dw_pcie_ops {
 	enum dw_pcie_ltssm (*get_ltssm)(struct dw_pcie *pcie);
 	int	(*start_link)(struct dw_pcie *pcie);
 	void	(*stop_link)(struct dw_pcie *pcie);
+	int	(*host_start_link)(struct dw_pcie *pcie);
+	void	(*host_stop_link)(struct dw_pcie *pcie);
 };
 
 struct dw_pcie {
@@ -665,6 +667,20 @@ static inline void dw_pcie_stop_link(struct dw_pcie *pci)
 		pci->ops->stop_link(pci);
 }
 
+static inline int dw_pcie_host_start_link(struct dw_pcie *pci)
+{
+	if (pci->ops && pci->ops->host_start_link)
+		return pci->ops->host_start_link(pci);
+
+	return 0;
+}
+
+static inline void dw_pcie_host_stop_link(struct dw_pcie *pci)
+{
+	if (pci->ops && pci->ops->host_stop_link)
+		pci->ops->host_stop_link(pci);
+}
+
 static inline enum dw_pcie_ltssm dw_pcie_get_ltssm(struct dw_pcie *pci)
 {
 	u32 val;

-- 
2.34.1

[PATCH v3 5/6] PCI: qcom: Add support for host_stop_link() & host_start_link()

[Krishna chaitanya chundru]

For the switches like QPS615 which needs to configure it before
the PCIe link is established.

If the link is up, the boatloader might powered and configured the
endpoint/switch already. In that case don't touch PCIe link else
assert the PERST# and disable LTSSM bit so that PCIe controller
will not participate in the link training as part of host_stop_link().

De-assert the PERST# and enable LTSSM bit back in host_start_link().

Introduce ltssm_disable function op to stop the link training.

Signed-off-by: Krishna chaitanya chundru <quic_krichai@quicinc.com>
---
 drivers/pci/controller/dwc/pcie-qcom.c | 39 ++++++++++++++++++++++++++++++++++
 1 file changed, 39 insertions(+)

diff --git a/drivers/pci/controller/dwc/pcie-qcom.c b/drivers/pci/controller/dwc/pcie-qcom.c
index ef44a82be058..048aea94e319 100644
--- a/drivers/pci/controller/dwc/pcie-qcom.c
+++ b/drivers/pci/controller/dwc/pcie-qcom.c
@@ -246,6 +246,7 @@ struct qcom_pcie_ops {
 	void (*host_post_init)(struct qcom_pcie *pcie);
 	void (*deinit)(struct qcom_pcie *pcie);
 	void (*ltssm_enable)(struct qcom_pcie *pcie);
+	void (*ltssm_disable)(struct qcom_pcie *pcie);
 	int (*config_sid)(struct qcom_pcie *pcie);
 };
 
@@ -617,6 +618,41 @@ static int qcom_pcie_post_init_1_0_0(struct qcom_pcie *pcie)
 	return 0;
 }
 
+static int qcom_pcie_host_start_link(struct dw_pcie *pci)
+{
+	struct qcom_pcie *pcie = to_qcom_pcie(pci);
+
+	if (!dw_pcie_link_up(pcie->pci))  {
+		qcom_ep_reset_deassert(pcie);
+
+		if (pcie->cfg->ops->ltssm_enable)
+			pcie->cfg->ops->ltssm_enable(pcie);
+	}
+
+	return 0;
+}
+
+static void qcom_pcie_host_stop_link(struct dw_pcie *pci)
+{
+	struct qcom_pcie *pcie = to_qcom_pcie(pci);
+
+	if (!dw_pcie_link_up(pcie->pci))  {
+		qcom_ep_reset_assert(pcie);
+
+		if (pcie->cfg->ops->ltssm_disable)
+			pcie->cfg->ops->ltssm_disable(pcie);
+	}
+}
+
+static void qcom_pcie_2_3_2_ltssm_disable(struct qcom_pcie *pcie)
+{
+	u32 val;
+
+	val = readl(pcie->parf + PARF_LTSSM);
+	val &= ~LTSSM_EN;
+	writel(val, pcie->parf + PARF_LTSSM);
+}
+
 static void qcom_pcie_2_3_2_ltssm_enable(struct qcom_pcie *pcie)
 {
 	u32 val;
@@ -1361,6 +1397,7 @@ static const struct qcom_pcie_ops ops_1_9_0 = {
 	.host_post_init = qcom_pcie_host_post_init_2_7_0,
 	.deinit = qcom_pcie_deinit_2_7_0,
 	.ltssm_enable = qcom_pcie_2_3_2_ltssm_enable,
+	.ltssm_disable = qcom_pcie_2_3_2_ltssm_disable,
 	.config_sid = qcom_pcie_config_sid_1_9_0,
 };
 
@@ -1418,6 +1455,8 @@ static const struct qcom_pcie_cfg cfg_sc8280xp = {
 static const struct dw_pcie_ops dw_pcie_ops = {
 	.link_up = qcom_pcie_link_up,
 	.start_link = qcom_pcie_start_link,
+	.host_start_link = qcom_pcie_host_start_link,
+	.host_stop_link = qcom_pcie_host_stop_link,
 };
 
 static int qcom_pcie_icc_init(struct qcom_pcie *pcie)

-- 
2.34.1

[PATCH v3 6/6] PCI: pwrctl: Add power control driver for qps615

[Krishna chaitanya chundru]

QPS615 is the PCIe switch which has one upstream and three downstream
ports. To one of the downstream ports ethernet MAC is connected as endpoint
device. Other two downstream ports are supposed to connect to external
device. One Host can connect to QPS615 by upstream port. QPS615 switch
needs to be configured after powering on and before PCIe link was up.

The PCIe controller driver already enables link training at the host side
even before qps615 driver probe happens, due to this when driver enables
power to the switch it participates in the link training and PCIe link
may come up before configuring the switch through i2c. To prevent the
host from participating in link training, disable link training on the
host side to ensure the link does not come up before the switch is
configured via I2C.

Based up on dt property and type of the port, qps615 is configured
through i2c.

Signed-off-by: Krishna chaitanya chundru <quic_krichai@quicinc.com>
---
 drivers/pci/pwrctl/Kconfig             |   8 +
 drivers/pci/pwrctl/Makefile            |   1 +
 drivers/pci/pwrctl/pci-pwrctl-qps615.c | 630 +++++++++++++++++++++++++++++++++
 3 files changed, 639 insertions(+)

diff --git a/drivers/pci/pwrctl/Kconfig b/drivers/pci/pwrctl/Kconfig
index 54589bb2403b..fe945d176b8b 100644
--- a/drivers/pci/pwrctl/Kconfig
+++ b/drivers/pci/pwrctl/Kconfig
@@ -10,3 +10,11 @@ config PCI_PWRCTL_PWRSEQ
 	tristate
 	select POWER_SEQUENCING
 	select PCI_PWRCTL
+
+config PCI_PWRCTL_QPS615
+	tristate "PCI Power Control driver for QPS615"
+	select PCI_PWRCTL
+	help
+	  Say Y here to enable the pwrctl driver for Qualcomm
+	  QPS615 PCIe switch which enables and configures it
+	  through i2c.
diff --git a/drivers/pci/pwrctl/Makefile b/drivers/pci/pwrctl/Makefile
index d308aae4800c..ac563a70c023 100644
--- a/drivers/pci/pwrctl/Makefile
+++ b/drivers/pci/pwrctl/Makefile
@@ -4,3 +4,4 @@ obj-$(CONFIG_PCI_PWRCTL)		+= pci-pwrctl-core.o
 pci-pwrctl-core-y			:= core.o
 
 obj-$(CONFIG_PCI_PWRCTL_PWRSEQ)		+= pci-pwrctl-pwrseq.o
+obj-$(CONFIG_PCI_PWRCTL_QPS615)		+= pci-pwrctl-qps615.o
diff --git a/drivers/pci/pwrctl/pci-pwrctl-qps615.c b/drivers/pci/pwrctl/pci-pwrctl-qps615.c
new file mode 100644
index 000000000000..c338e35c9083
--- /dev/null
+++ b/drivers/pci/pwrctl/pci-pwrctl-qps615.c
@@ -0,0 +1,630 @@
+// SPDX-License-Identifier: GPL-2.0-only
+/*
+ * Copyright (c) 2024 Qualcomm Innovation Center, Inc. All rights reserved.
+ */
+
+#include <linux/delay.h>
+#include <linux/device.h>
+#include <linux/i2c.h>
+#include <linux/mod_devicetable.h>
+#include <linux/module.h>
+#include <linux/of.h>
+#include <linux/of_platform.h>
+#include <linux/pci.h>
+#include <linux/pci-pwrctl.h>
+#include <linux/platform_device.h>
+#include <linux/regulator/consumer.h>
+#include <linux/string.h>
+#include <linux/types.h>
+#include <linux/unaligned.h>
+
+#include "../pci.h"
+
+#define QPS615_GPIO_CONFIG		0x801208
+#define QPS615_RESET_GPIO		0x801210
+
+#define QPS615_BUS_CONTROL		0x801014
+
+#define QPS615_PORT_L0S_DELAY		0x82496c
+#define QPS615_PORT_L1_DELAY		0x824970
+
+#define QPS615_EMBEDDED_ETH_DELAY	0x8200d8
+#define QPS615_ETH_L1_DELAY_MASK	GENMASK(27, 18)
+#define QPS615_ETH_L1_DELAY_VALUE(x)	FIELD_PREP(QPS615_ETH_L1_DELAY_MASK, x)
+#define QPS615_ETH_L0S_DELAY_MASK	GENMASK(17, 13)
+#define QPS615_ETH_L0S_DELAY_VALUE(x)	FIELD_PREP(QPS615_ETH_L0S_DELAY_MASK, x)
+
+#define QPS615_NFTS_2_5_GT		0x824978
+#define QPS615_NFTS_5_GT		0x82497c
+
+#define QPS615_PORT_LANE_ACCESS_ENABLE	0x828000
+
+#define QPS615_PHY_RATE_CHANGE_OVERRIDE	0x828040
+#define QPS615_PHY_RATE_CHANGE		0x828050
+
+#define QPS615_TX_MARGIN		0x828234
+
+#define QPS615_DFE_ENABLE		0x828a04
+#define QPS615_DFE_EQ0_MODE		0x828a08
+#define QPS615_DFE_EQ1_MODE		0x828a0c
+#define QPS615_DFE_EQ2_MODE		0x828a14
+#define QPS615_DFE_PD_MASK		0x828254
+
+#define QPS615_PORT_SELECT		0x82c02c
+#define QPS615_PORT_ACCESS_ENABLE	0x82c030
+
+#define QPS615_POWER_CONTROL		0x82b09c
+#define QPS615_POWER_CONTROL_OVREN	0x82b2c8
+
+#define QPS615_FREQ_125_MHZ		125000000
+#define QPS615_FREQ_250_MHZ		250000000
+
+#define QPS615_GPIO_MASK		0xfffffff3
+
+struct qps615_pwrctl_reg_setting {
+	unsigned int offset;
+	unsigned int val;
+};
+
+enum qps615_pwrctl_ports {
+	QPS615_USP,
+	QPS615_DSP1,
+	QPS615_DSP2,
+	QPS615_DSP3,
+	QPS615_ETHERNET,
+	QPS615_MAX
+};
+
+struct qps615_pwrctl_cfg {
+	u32 l0s_delay;
+	u32 l1_delay;
+	u32 tx_amp;
+	u32 nfts;
+	bool disable_dfe;
+	bool disable_port;
+	bool axi_freq_125;
+};
+
+#define QPS615_PWRCTL_MAX_SUPPLY	6
+
+struct qps615_pwrctl_ctx {
+	struct regulator_bulk_data supplies[QPS615_PWRCTL_MAX_SUPPLY];
+	struct qps615_pwrctl_cfg cfg[QPS615_MAX];
+	struct gpio_desc *reset_gpio;
+	struct i2c_adapter *adapter;
+	struct i2c_client *client;
+	struct pci_pwrctl pwrctl;
+};
+
+/*
+ * downstream port power off sequence, hardcoding the address
+ * as we don't know register names for these register offsets.
+ */
+static const struct qps615_pwrctl_reg_setting common_pwroff_seq[] = {
+	{0x82900c, 0x1},
+	{0x829010, 0x1},
+	{0x829018, 0x0},
+	{0x829020, 0x1},
+	{0x82902c, 0x1},
+	{0x829030, 0x1},
+	{0x82903c, 0x1},
+	{0x829058, 0x0},
+	{0x82905c, 0x1},
+	{0x829060, 0x1},
+	{0x8290cc, 0x1},
+	{0x8290d0, 0x1},
+	{0x8290d8, 0x1},
+	{0x8290e0, 0x1},
+	{0x8290e8, 0x1},
+	{0x8290ec, 0x1},
+	{0x8290f4, 0x1},
+	{0x82910c, 0x1},
+	{0x829110, 0x1},
+	{0x829114, 0x1},
+};
+
+static const struct qps615_pwrctl_reg_setting dsp1_pwroff_seq[] = {
+	{QPS615_PORT_ACCESS_ENABLE, 0x2},
+	{QPS615_PORT_LANE_ACCESS_ENABLE, 0x3},
+	{QPS615_POWER_CONTROL, 0x014f4804},
+	{QPS615_POWER_CONTROL_OVREN, 0x1},
+	{QPS615_PORT_ACCESS_ENABLE, 0x4},
+};
+
+static const struct qps615_pwrctl_reg_setting dsp2_pwroff_seq[] = {
+	{QPS615_PORT_ACCESS_ENABLE, 0x8},
+	{QPS615_PORT_LANE_ACCESS_ENABLE, 0x1},
+	{QPS615_POWER_CONTROL, 0x014f4804},
+	{QPS615_POWER_CONTROL_OVREN, 0x1},
+	{QPS615_PORT_ACCESS_ENABLE, 0x8},
+};
+
+/*
+ * Since all transfers are initiated by the probe, no locks are necessary,
+ * ensuring there are no concurrent calls.
+ */
+static int qps615_pwrctl_i2c_write(struct i2c_client *client,
+				   u32 reg_addr, u32 reg_val)
+{
+	struct i2c_msg msg;
+	u8 msg_buf[7];
+	int ret;
+
+	msg.addr = client->addr;
+	msg.len = 7;
+	msg.flags = 0;
+
+	/* Big Endian for reg addr */
+	put_unaligned_be24(reg_addr, &msg_buf[0]);
+
+	/* Little Endian for reg val */
+	put_unaligned_le32(reg_val, &msg_buf[3]);
+
+	msg.buf = msg_buf;
+	ret = i2c_transfer(client->adapter, &msg, 1);
+	return ret == 1 ? 0 : ret;
+}
+
+static int qps615_pwrctl_i2c_read(struct i2c_client *client,
+				  u32 reg_addr, u32 *reg_val)
+{
+	struct i2c_msg msg[2];
+	u8 wr_data[3];
+	u32 rd_data;
+	int ret;
+
+	msg[0].addr = client->addr;
+	msg[0].len = 3;
+	msg[0].flags = 0;
+
+	/* Big Endian for reg addr */
+	put_unaligned_be24(reg_addr, &wr_data[0]);
+
+	msg[0].buf = wr_data;
+
+	msg[1].addr = client->addr;
+	msg[1].len = 4;
+	msg[1].flags = I2C_M_RD;
+
+	msg[1].buf = (u8 *)&rd_data;
+
+	ret = i2c_transfer(client->adapter, &msg[0], 2);
+	if (ret == 2) {
+		*reg_val = get_unaligned_le32(&rd_data);
+		return 0;
+	}
+
+	/* If only one message successfully completed, return -ENODEV */
+	return ret == 1 ? -ENODEV : ret;
+}
+
+static int qps615_pwrctl_i2c_bulk_write(struct i2c_client *client,
+					const struct qps615_pwrctl_reg_setting *seq, int len)
+{
+	int ret, i;
+
+	for (i = 0; i < len; i++) {
+		ret = qps615_pwrctl_i2c_write(client, seq[i].offset, seq[i].val);
+		if (ret)
+			return ret;
+	}
+
+	return 0;
+}
+
+static int qps615_pwrctl_disable_port(struct qps615_pwrctl_ctx *ctx,
+				      enum qps615_pwrctl_ports port)
+{
+	const struct qps615_pwrctl_reg_setting *seq;
+	int ret, len;
+
+	if (port == QPS615_DSP1) {
+		seq = dsp1_pwroff_seq;
+		len = ARRAY_SIZE(dsp1_pwroff_seq);
+	} else {
+		seq = dsp2_pwroff_seq;
+		len = ARRAY_SIZE(dsp2_pwroff_seq);
+	}
+
+	ret = qps615_pwrctl_i2c_bulk_write(ctx->client, seq, len);
+	if (ret)
+		return ret;
+
+	return qps615_pwrctl_i2c_bulk_write(ctx->client,
+					    common_pwroff_seq, ARRAY_SIZE(common_pwroff_seq));
+}
+
+static int qps615_pwrctl_set_l0s_l1_entry_delay(struct qps615_pwrctl_ctx *ctx,
+						enum qps615_pwrctl_ports port, bool is_l1, u32 ns)
+{
+	u32 rd_val, units, mask;
+	int ret;
+
+	/* convert to units of 256ns */
+	units = ns / 256;
+
+	if (port == QPS615_ETHERNET) {
+		ret = qps615_pwrctl_i2c_read(ctx->client, QPS615_EMBEDDED_ETH_DELAY, &rd_val);
+		if (ret)
+			return ret;
+		mask = is_l1 ? QPS615_ETH_L1_DELAY_MASK : QPS615_ETH_L0S_DELAY_MASK;
+		rd_val = u32_replace_bits(rd_val, units, mask);
+		return qps615_pwrctl_i2c_write(ctx->client, QPS615_EMBEDDED_ETH_DELAY, rd_val);
+	}
+
+	ret = qps615_pwrctl_i2c_write(ctx->client, QPS615_PORT_SELECT, BIT(port));
+	if (ret)
+		return ret;
+
+	return qps615_pwrctl_i2c_write(ctx->client,
+				       is_l1 ? QPS615_PORT_L1_DELAY : QPS615_PORT_L0S_DELAY, units);
+}
+
+static int qps615_pwrctl_set_tx_amplitude(struct qps615_pwrctl_ctx *ctx,
+					  enum qps615_pwrctl_ports port, u32 amp)
+{
+	int port_access;
+
+	switch (port) {
+	case QPS615_USP:
+		port_access = 0x1;
+		break;
+	case QPS615_DSP1:
+		port_access = 0x2;
+		break;
+	case QPS615_DSP2:
+		port_access = 0x8;
+		break;
+	default:
+		return -EINVAL;
+	};
+
+	struct qps615_pwrctl_reg_setting tx_amp_seq[] = {
+		{QPS615_PORT_ACCESS_ENABLE, port_access},
+		{QPS615_PORT_LANE_ACCESS_ENABLE, 0x3},
+		{QPS615_TX_MARGIN, amp},
+	};
+
+	return qps615_pwrctl_i2c_bulk_write(ctx->client, tx_amp_seq, ARRAY_SIZE(tx_amp_seq));
+}
+
+static int qps615_pwrctl_disable_dfe(struct qps615_pwrctl_ctx *ctx,
+				     enum qps615_pwrctl_ports port)
+{
+	int port_access, lane_access = 0x3;
+	u32 phy_rate = 0x21;
+
+	switch (port) {
+	case QPS615_USP:
+		phy_rate = 0x1;
+		port_access = 0x1;
+		break;
+	case QPS615_DSP1:
+		port_access = 0x2;
+		break;
+	case QPS615_DSP2:
+		port_access = 0x8;
+		lane_access = 0x1;
+		break;
+	default:
+		return -EINVAL;
+	};
+
+	struct qps615_pwrctl_reg_setting disable_dfe_seq[] = {
+		{QPS615_PORT_ACCESS_ENABLE, port_access},
+		{QPS615_PORT_LANE_ACCESS_ENABLE, lane_access},
+		{QPS615_DFE_ENABLE, 0x0},
+		{QPS615_DFE_EQ0_MODE, 0x411},
+		{QPS615_DFE_EQ1_MODE, 0x11},
+		{QPS615_DFE_EQ2_MODE, 0x11},
+		{QPS615_DFE_PD_MASK, 0x7},
+		{QPS615_PHY_RATE_CHANGE_OVERRIDE, 0x10},
+		{QPS615_PHY_RATE_CHANGE, phy_rate},
+		{QPS615_PHY_RATE_CHANGE, 0x0},
+		{QPS615_PHY_RATE_CHANGE_OVERRIDE, 0x0},
+	};
+
+	return qps615_pwrctl_i2c_bulk_write(ctx->client,
+					    disable_dfe_seq, ARRAY_SIZE(disable_dfe_seq));
+}
+
+static int qps615_pwrctl_set_nfts(struct qps615_pwrctl_ctx *ctx,
+				  enum qps615_pwrctl_ports port, u32 nfts)
+{
+	int ret;
+	struct qps615_pwrctl_reg_setting nfts_seq[] = {
+		{QPS615_NFTS_2_5_GT, nfts},
+		{QPS615_NFTS_5_GT, nfts},
+	};
+
+	ret =  qps615_pwrctl_i2c_write(ctx->client, QPS615_PORT_SELECT, BIT(port));
+	if (ret)
+		return ret;
+
+	return qps615_pwrctl_i2c_bulk_write(ctx->client, nfts_seq, ARRAY_SIZE(nfts_seq));
+}
+
+static int qps615_pwrctl_assert_deassert_reset(struct qps615_pwrctl_ctx *ctx, bool deassert)
+{
+	int ret, val;
+
+	ret = qps615_pwrctl_i2c_write(ctx->client, QPS615_GPIO_CONFIG, QPS615_GPIO_MASK);
+	if (ret)
+		return ret;
+
+	val = deassert ? 0xc : 0;
+
+	return qps615_pwrctl_i2c_write(ctx->client, QPS615_RESET_GPIO, val);
+}
+
+static int qps615_pwrctl_parse_device_dt(struct qps615_pwrctl_ctx *ctx, struct device_node *node,
+					 enum qps615_pwrctl_ports port)
+{
+	struct qps615_pwrctl_cfg *cfg;
+	u32 axi_freq = 0;
+	int ret;
+
+	cfg = &ctx->cfg[port];
+
+	if (!of_device_is_available(node)) {
+		cfg->disable_port = true;
+		return 0;
+	};
+
+	ret = of_property_read_u32(node, "qcom,axi-clk-freq-hz", &axi_freq);
+	if (ret && ret != -EINVAL)
+		return ret;
+	else if (axi_freq && (axi_freq != QPS615_FREQ_125_MHZ || axi_freq != QPS615_FREQ_250_MHZ))
+		return -EINVAL;
+	else if (axi_freq == QPS615_FREQ_125_MHZ)
+		cfg->axi_freq_125 = true;
+
+	ret = of_property_read_u32(node, "qcom,l0s-entry-delay-ns", &cfg->l0s_delay);
+	if (ret && ret != -EINVAL)
+		return ret;
+
+	ret = of_property_read_u32(node, "qcom,l1-entry-delay-ns", &cfg->l1_delay);
+	if (ret && ret != -EINVAL)
+		return ret;
+
+	ret = of_property_read_u32(node, "qcom,tx-amplitude-millivolt", &cfg->tx_amp);
+	if (ret && ret != -EINVAL)
+		return ret;
+
+	ret = of_property_read_u32(node, "qcom,nfts", &cfg->nfts);
+	if (ret && ret != -EINVAL)
+		return ret;
+
+	cfg->disable_dfe = of_property_read_bool(node, "qcom,no-dfe-support");
+
+	return 0;
+}
+
+static void qps615_pwrctl_power_off(struct qps615_pwrctl_ctx *ctx)
+{
+	gpiod_set_value(ctx->reset_gpio, 1);
+
+	regulator_bulk_disable(ARRAY_SIZE(ctx->supplies), ctx->supplies);
+}
+
+static int qps615_pwrctl_power_on(struct qps615_pwrctl_ctx *ctx)
+{
+	struct qps615_pwrctl_cfg *cfg;
+	int ret, i;
+
+	ret = regulator_bulk_enable(ARRAY_SIZE(ctx->supplies), ctx->supplies);
+	if (ret < 0)
+		return dev_err_probe(ctx->pwrctl.dev, ret, "cannot enable regulators\n");
+
+	gpiod_set_value(ctx->reset_gpio, 0);
+
+	 /* wait for the internal osc frequency to stablise */
+	usleep_range(10000, 10500);
+
+	ret = qps615_pwrctl_assert_deassert_reset(ctx, false);
+	if (ret)
+		goto out;
+
+	if (ctx->cfg[QPS615_USP].axi_freq_125) {
+		ret = qps615_pwrctl_i2c_write(ctx->client, QPS615_BUS_CONTROL, BIT(16));
+		if (ret)
+			dev_err(ctx->pwrctl.dev, "Setting AXI clk freq failed %d\n", ret);
+	}
+
+	for (i = 0; i < QPS615_MAX; i++) {
+		cfg = &ctx->cfg[i];
+		if (cfg->disable_port) {
+			ret = qps615_pwrctl_disable_port(ctx, i);
+			if (ret) {
+				dev_err(ctx->pwrctl.dev, "Disabling port failed\n");
+				goto out;
+			}
+		}
+
+		if (cfg->l0s_delay) {
+			ret = qps615_pwrctl_set_l0s_l1_entry_delay(ctx, i, false, cfg->l0s_delay);
+			if (ret) {
+				dev_err(ctx->pwrctl.dev, "Setting L0s entry delay failed\n");
+				goto out;
+			}
+		}
+
+		if (cfg->l1_delay) {
+			ret = qps615_pwrctl_set_l0s_l1_entry_delay(ctx, i, true, cfg->l1_delay);
+			if (ret) {
+				dev_err(ctx->pwrctl.dev, "Setting L1 entry delay failed\n");
+				goto out;
+			}
+		}
+
+		if (cfg->tx_amp) {
+			ret = qps615_pwrctl_set_tx_amplitude(ctx, i, cfg->tx_amp);
+			if (ret) {
+				dev_err(ctx->pwrctl.dev, "Setting Tx amplitube failed\n");
+				goto out;
+			}
+		}
+
+		if (cfg->nfts) {
+			ret = qps615_pwrctl_set_nfts(ctx, i, cfg->nfts);
+			if (ret) {
+				dev_err(ctx->pwrctl.dev, "Setting nfts failed\n");
+				goto out;
+			}
+		}
+
+		if (cfg->disable_dfe) {
+			ret = qps615_pwrctl_disable_dfe(ctx, i);
+			if (ret) {
+				dev_err(ctx->pwrctl.dev, "Disabling DFE failed\n");
+				goto out;
+			}
+		}
+	}
+
+	ret = qps615_pwrctl_assert_deassert_reset(ctx, true);
+	if (!ret)
+		return 0;
+
+out:
+	qps615_pwrctl_power_off(ctx);
+	return ret;
+}
+
+static int qps615_pwrctl_probe(struct platform_device *pdev)
+{
+	struct device *dev = &pdev->dev;
+	struct pci_host_bridge *bridge;
+	enum qps615_pwrctl_ports port;
+	struct qps615_pwrctl_ctx *ctx;
+	int ret, addr;
+
+	bridge = pci_find_host_bridge(to_pci_dev(dev->parent)->bus);
+
+	ctx = devm_kzalloc(dev, sizeof(*ctx), GFP_KERNEL);
+	if (!ctx)
+		return -ENOMEM;
+
+	ret = of_property_read_u32_index(pdev->dev.of_node, "i2c-parent", 1, &addr);
+	if (ret)
+		return dev_err_probe(dev, ret, "Failed to read i2c-parent property\n");
+
+	ctx->adapter = of_find_i2c_adapter_by_node(of_parse_phandle(dev->of_node, "i2c-parent", 0));
+	of_node_put(dev->of_node);
+	if (!ctx->adapter)
+		return dev_err_probe(dev, -EPROBE_DEFER, "Failed to find I2C adapter\n");
+
+	ctx->client = i2c_new_dummy_device(ctx->adapter, addr);
+	if (IS_ERR(ctx->client)) {
+		dev_err(dev, "Failed to create I2C client\n");
+		i2c_put_adapter(ctx->adapter);
+		return PTR_ERR(ctx->client);
+	}
+
+	ctx->supplies[0].supply = "vddc";
+	ctx->supplies[1].supply = "vdd18";
+	ctx->supplies[2].supply = "vdd09";
+	ctx->supplies[3].supply = "vddio1";
+	ctx->supplies[4].supply = "vddio2";
+	ctx->supplies[5].supply = "vddio18";
+	ret = devm_regulator_bulk_get(dev, ARRAY_SIZE(ctx->supplies), ctx->supplies);
+	if (ret) {
+		dev_err_probe(dev, ret,
+			      "failed to get supply regulator\n");
+		goto remove_i2c;
+	}
+
+	ctx->reset_gpio = devm_gpiod_get(dev, "reset", GPIOD_ASIS);
+	if (IS_ERR(ctx->reset_gpio)) {
+		ret = dev_err_probe(dev, PTR_ERR(ctx->reset_gpio), "failed to get reset GPIO\n");
+		goto remove_i2c;
+	}
+
+	platform_set_drvdata(pdev, ctx);
+
+	pci_pwrctl_init(&ctx->pwrctl, dev);
+
+	port = QPS615_USP;
+	ret = qps615_pwrctl_parse_device_dt(ctx, pdev->dev.of_node, port);
+	if (ret) {
+		dev_err(dev, "failed to parse device tree properties: %d\n", ret);
+		goto remove_i2c;
+	}
+
+	/*
+	 * Downstream ports are always children of the upstream port.
+	 * The first node represents DSP1, the second node represents DSP2, and so on.
+	 */
+	for_each_child_of_node_scoped(pdev->dev.of_node, child) {
+		ret = qps615_pwrctl_parse_device_dt(ctx, child, port++);
+		if (ret)
+			break;
+		/* Embedded ethernet device are under DSP3 */
+		if (port == QPS615_DSP3)
+			for_each_child_of_node_scoped(child, child1) {
+				ret = qps615_pwrctl_parse_device_dt(ctx, child1, port++);
+				if (ret)
+					break;
+			}
+	}
+	if (ret) {
+		dev_err(dev, "failed to parse device tree properties: %d\n", ret);
+		goto remove_i2c;
+	}
+
+	if (bridge->ops->stop_link)
+		bridge->ops->stop_link(to_pci_dev(dev->parent)->bus);
+
+	ret = qps615_pwrctl_power_on(ctx);
+	if (ret)
+		goto remove_i2c;
+
+	if (bridge->ops->start_link) {
+		ret = bridge->ops->start_link(to_pci_dev(dev->parent)->bus);
+		if (ret)
+			goto power_off;
+	}
+
+	ret = devm_pci_pwrctl_device_set_ready(dev, &ctx->pwrctl);
+	if (ret)
+		goto power_off;
+
+	return 0;
+
+power_off:
+	qps615_pwrctl_power_off(ctx);
+remove_i2c:
+	i2c_unregister_device(ctx->client);
+	i2c_put_adapter(ctx->adapter);
+	return ret;
+}
+
+static void qps615_pwrctl_remove(struct platform_device *pdev)
+{
+	struct qps615_pwrctl_ctx *ctx = platform_get_drvdata(pdev);
+
+	qps615_pwrctl_power_off(ctx);
+	i2c_unregister_device(ctx->client);
+	i2c_put_adapter(ctx->adapter);
+}
+
+static const struct of_device_id qps615_pwrctl_of_match[] = {
+	{ .compatible = "pci1179,0623"},
+	{ }
+};
+MODULE_DEVICE_TABLE(of, qps615_pwrctl_of_match);
+
+static struct platform_driver qps615_pwrctl_driver = {
+	.driver = {
+		.name = "pwrctl-qps615",
+		.of_match_table = qps615_pwrctl_of_match,
+		.probe_type = PROBE_PREFER_ASYNCHRONOUS,
+	},
+	.probe = qps615_pwrctl_probe,
+	.remove_new = qps615_pwrctl_remove,
+};
+module_platform_driver(qps615_pwrctl_driver);
+
+MODULE_AUTHOR("Krishna chaitanya chundru <quic_krichai@quicinc.com>");
+MODULE_DESCRIPTION("Qualcomm QPS615 power control driver");
+MODULE_LICENSE("GPL");

-- 
2.34.1

Re: [PATCH v3 2/6] arm64: dts: qcom: qcs6490-rb3gen2: Add node for qps615

[Bjorn Andersson]

On Tue, Nov 12, 2024 at 08:31:34PM +0530, Krishna chaitanya chundru wrote:
> Add QPS615 PCIe switch node which has 3 downstream ports and in one
> downstream port two embedded ethernet devices are present.
> 
> Power to the QPS615 is supplied through two LDO regulators, controlled
> by two GPIOs, these are added as fixed regulators. And the QPS615 is
> configured through i2c.
> 
> Signed-off-by: Krishna chaitanya chundru <quic_krichai@quicinc.com>

Reviewed-by: Bjorn Andersson <andersson@kernel.org>

Regards,
Bjorn

> ---
>  arch/arm64/boot/dts/qcom/qcs6490-rb3gen2.dts | 115 +++++++++++++++++++++++++++
>  arch/arm64/boot/dts/qcom/sc7280.dtsi         |   2 +-
>  2 files changed, 116 insertions(+), 1 deletion(-)
> 
> diff --git a/arch/arm64/boot/dts/qcom/qcs6490-rb3gen2.dts b/arch/arm64/boot/dts/qcom/qcs6490-rb3gen2.dts
> index 0d45662b8028..0e890841b600 100644
> --- a/arch/arm64/boot/dts/qcom/qcs6490-rb3gen2.dts
> +++ b/arch/arm64/boot/dts/qcom/qcs6490-rb3gen2.dts
> @@ -202,6 +202,30 @@ vph_pwr: vph-pwr-regulator {
>  		regulator-min-microvolt = <3700000>;
>  		regulator-max-microvolt = <3700000>;
>  	};
> +
> +	vdd_ntn_0p9: regulator-vdd-ntn-0p9 {
> +		compatible = "regulator-fixed";
> +		regulator-name = "VDD_NTN_0P9";
> +		gpio = <&pm8350c_gpios 2 GPIO_ACTIVE_HIGH>;
> +		regulator-min-microvolt = <899400>;
> +		regulator-max-microvolt = <899400>;
> +		enable-active-high;
> +		pinctrl-0 = <&ntn_0p9_en>;
> +		pinctrl-names = "default";
> +		regulator-enable-ramp-delay = <4300>;
> +	};
> +
> +	vdd_ntn_1p8: regulator-vdd-ntn-1p8 {
> +		compatible = "regulator-fixed";
> +		regulator-name = "VDD_NTN_1P8";
> +		gpio = <&pm8350c_gpios 3 GPIO_ACTIVE_HIGH>;
> +		regulator-min-microvolt = <1800000>;
> +		regulator-max-microvolt = <1800000>;
> +		enable-active-high;
> +		pinctrl-0 = <&ntn_1p8_en>;
> +		pinctrl-names = "default";
> +		regulator-enable-ramp-delay = <10000>;
> +	};
>  };
>  
>  &apps_rsc {
> @@ -684,6 +708,75 @@ &mdss_edp_phy {
>  	status = "okay";
>  };
>  
> +&pcie1_port {
> +	pcie@0,0 {
> +		compatible = "pci1179,0623";
> +		reg = <0x10000 0x0 0x0 0x0 0x0>;
> +		#address-cells = <3>;
> +		#size-cells = <2>;
> +
> +		device_type = "pci";
> +		ranges;
> +		bus-range = <0x2 0xff>;
> +
> +		vddc-supply = <&vdd_ntn_0p9>;
> +		vdd18-supply = <&vdd_ntn_1p8>;
> +		vdd09-supply = <&vdd_ntn_0p9>;
> +		vddio1-supply = <&vdd_ntn_1p8>;
> +		vddio2-supply = <&vdd_ntn_1p8>;
> +		vddio18-supply = <&vdd_ntn_1p8>;
> +
> +		i2c-parent = <&i2c0 0x77>;
> +
> +		reset-gpios = <&pm8350c_gpios 1 GPIO_ACTIVE_LOW>;
> +
> +		pcie@1,0 {
> +			reg = <0x20800 0x0 0x0 0x0 0x0>;
> +			#address-cells = <3>;
> +			#size-cells = <2>;
> +
> +			device_type = "pci";
> +			ranges;
> +			bus-range = <0x3 0xff>;
> +		};
> +
> +		pcie@2,0 {
> +			reg = <0x21000 0x0 0x0 0x0 0x0>;
> +			#address-cells = <3>;
> +			#size-cells = <2>;
> +
> +			device_type = "pci";
> +			ranges;
> +			bus-range = <0x4 0xff>;
> +		};
> +
> +		pcie@3,0 {
> +			reg = <0x21800 0x0 0x0 0x0 0x0>;
> +			#address-cells = <3>;
> +			#size-cells = <2>;
> +			device_type = "pci";
> +			ranges;
> +			bus-range = <0x5 0xff>;
> +
> +			pcie@0,0 {
> +				reg = <0x50000 0x0 0x0 0x0 0x0>;
> +				#address-cells = <3>;
> +				#size-cells = <2>;
> +				device_type = "pci";
> +				ranges;
> +			};
> +
> +			pcie@0,1 {
> +				reg = <0x50100 0x0 0x0 0x0 0x0>;
> +				#address-cells = <3>;
> +				#size-cells = <2>;
> +				device_type = "pci";
> +				ranges;
> +			};
> +		};
> +	};
> +};
> +
>  &pmk8350_rtc {
>  	status = "okay";
>  };
> @@ -812,6 +905,28 @@ lt9611_rst_pin: lt9611-rst-state {
>  	};
>  };
>  
> +&pm8350c_gpios {
> +	ntn_0p9_en: ntn-0p9-en-state {
> +		pins = "gpio2";
> +		function = "normal";
> +
> +		bias-disable;
> +		input-disable;
> +		output-enable;
> +		power-source = <0>;
> +	};
> +
> +	ntn_1p8_en: ntn-1p8-en-state {
> +		pins = "gpio3";
> +		function = "normal";
> +
> +		bias-disable;
> +		input-disable;
> +		output-enable;
> +		power-source = <0>;
> +	};
> +};
> +
>  &tlmm {
>  	lt9611_irq_pin: lt9611-irq-state {
>  		pins = "gpio24";
> diff --git a/arch/arm64/boot/dts/qcom/sc7280.dtsi b/arch/arm64/boot/dts/qcom/sc7280.dtsi
> index 3d8410683402..82434f085ff0 100644
> --- a/arch/arm64/boot/dts/qcom/sc7280.dtsi
> +++ b/arch/arm64/boot/dts/qcom/sc7280.dtsi
> @@ -2279,7 +2279,7 @@ pcie1: pcie@1c08000 {
>  
>  			status = "disabled";
>  
> -			pcie@0 {
> +			pcie1_port: pcie@0 {
>  				device_type = "pci";
>  				reg = <0x0 0x0 0x0 0x0 0x0>;
>  				bus-range = <0x01 0xff>;
> 
> -- 
> 2.34.1
> 

Re: [PATCH v3 1/6] dt-bindings: PCI: Add binding for qps615

[Bjorn Andersson]

On Tue, Nov 12, 2024 at 08:31:33PM +0530, Krishna chaitanya chundru wrote:
> Add binding describing the Qualcomm PCIe switch, QPS615,
> which provides Ethernet MAC integrated to the 3rd downstream port
> and two downstream PCIe ports.
> 

Reviewed-by: Bjorn Andersson <andersson@kernel.org>

Regards,
Bjorn

> Signed-off-by: Krishna chaitanya chundru <quic_krichai@quicinc.com>
> ---
>  .../devicetree/bindings/pci/qcom,qps615.yaml       | 205 +++++++++++++++++++++
>  1 file changed, 205 insertions(+)
> 
> diff --git a/Documentation/devicetree/bindings/pci/qcom,qps615.yaml b/Documentation/devicetree/bindings/pci/qcom,qps615.yaml
> new file mode 100644
> index 000000000000..e6a63a0bb0f3
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/pci/qcom,qps615.yaml
> @@ -0,0 +1,205 @@
> +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
> +%YAML 1.2
> +---
> +$id: http://devicetree.org/schemas/pci/qcom,qps615.yaml#
> +$schema: http://devicetree.org/meta-schemas/core.yaml#
> +
> +title: Qualcomm QPS615 PCIe switch
> +
> +maintainers:
> +  - Krishna chaitanya chundru <quic_krichai@quicinc.com>
> +
> +description: |
> +  Qualcomm QPS615 PCIe switch has one upstream and three downstream
> +  ports. The 3rd downstream port has integrated endpoint device of
> +  Ethernet MAC. Other two downstream ports are supposed to connect
> +  to external device.
> +
> +  The QPS615 PCIe switch can be configured through I2C interface before
> +  PCIe link is established to change FTS, ASPM related entry delays,
> +  tx amplitude etc for better power efficiency and functionality.
> +
> +properties:
> +  compatible:
> +    enum:
> +      - pci1179,0623
> +
> +  reg:
> +    maxItems: 1
> +
> +  i2c-parent:
> +    $ref: /schemas/types.yaml#/definitions/phandle-array
> +    description: |
> +      A phandle to the parent I2C node and the slave address of the device
> +      used to do configure qps615 to change FTS, tx amplitude etc.
> +    items:
> +      - description: Phandle to the I2C controller node
> +      - description: I2C slave address
> +
> +  vdd18-supply: true
> +
> +  vdd09-supply: true
> +
> +  vddc-supply: true
> +
> +  vddio1-supply: true
> +
> +  vddio2-supply: true
> +
> +  vddio18-supply: true
> +
> +  reset-gpios:
> +    maxItems: 1
> +    description:
> +      GPIO controlling the RESX# pin.
> +
> +  qps615,axi-clk-freq-hz:
> +    description:
> +      AXI clock rate which is internal bus of the switch
> +      The switch only runs in two frequencies i.e 250MHz and 125MHz.
> +    enum: [125000000, 250000000]
> +
> +allOf:
> +  - $ref: "#/$defs/qps615-node"
> +
> +patternProperties:
> +  "@1?[0-9a-f](,[0-7])?$":
> +    description: child nodes describing the internal downstream ports
> +      the qps615 switch.
> +    type: object
> +    $ref: "#/$defs/qps615-node"
> +    unevaluatedProperties: false
> +
> +$defs:
> +  qps615-node:
> +    type: object
> +
> +    properties:
> +      qcom,l0s-entry-delay-ns:
> +        description: Aspm l0s entry delay.
> +
> +      qcom,l1-entry-delay-ns:
> +        description: Aspm l1 entry delay.
> +
> +      qcom,tx-amplitude-millivolt:
> +        $ref: /schemas/types.yaml#/definitions/uint32
> +        description: Change Tx Margin setting for low power consumption.
> +
> +      qcom,no-dfe-support:
> +        type: boolean
> +        description: Disable DFE (Decision Feedback Equalizer), which mitigates
> +          intersymbol interference and some reflections caused by impedance mismatches.
> +
> +      qcom,nfts:
> +        $ref: /schemas/types.yaml#/definitions/uint32
> +        description:
> +          Number of Fast Training Sequence (FTS) used during L0s to L0 exit
> +          for bit and Symbol lock.
> +
> +    allOf:
> +      - $ref: /schemas/pci/pci-bus.yaml#
> +
> +unevaluatedProperties: false
> +
> +required:
> +  - vdd18-supply
> +  - vdd09-supply
> +  - vddc-supply
> +  - vddio1-supply
> +  - vddio2-supply
> +  - vddio18-supply
> +  - i2c-parent
> +  - reset-gpios
> +
> +examples:
> +  - |
> +
> +    #include <dt-bindings/gpio/gpio.h>
> +
> +    pcie {
> +        #address-cells = <3>;
> +        #size-cells = <2>;
> +
> +        pcie@0 {
> +            device_type = "pci";
> +            reg = <0x0 0x0 0x0 0x0 0x0>;
> +
> +            #address-cells = <3>;
> +            #size-cells = <2>;
> +            ranges;
> +            bus-range = <0x01 0xff>;
> +
> +            pcie@0,0 {
> +                compatible = "pci1179,0623";
> +                reg = <0x10000 0x0 0x0 0x0 0x0>;
> +                device_type = "pci";
> +                #address-cells = <3>;
> +                #size-cells = <2>;
> +                ranges;
> +                bus-range = <0x02 0xff>;
> +
> +                i2c-parent = <&qup_i2c 0x77>;
> +
> +                vdd18-supply = <&vdd>;
> +                vdd09-supply = <&vdd>;
> +                vddc-supply = <&vdd>;
> +                vddio1-supply = <&vdd>;
> +                vddio2-supply = <&vdd>;
> +                vddio18-supply = <&vdd>;
> +
> +                reset-gpios = <&gpio 1 GPIO_ACTIVE_LOW>;
> +
> +                pcie@1,0 {
> +                    reg = <0x20800 0x0 0x0 0x0 0x0>;
> +                    #address-cells = <3>;
> +                    #size-cells = <2>;
> +                    device_type = "pci";
> +                    ranges;
> +                    bus-range = <0x03 0xff>;
> +
> +                    qcom,no-dfe-support;
> +                };
> +
> +                pcie@2,0 {
> +                    reg = <0x21000 0x0 0x0 0x0 0x0>;
> +                    #address-cells = <3>;
> +                    #size-cells = <2>;
> +                    device_type = "pci";
> +                    ranges;
> +                    bus-range = <0x04 0xff>;
> +
> +                    qcom,nfts = <10>;
> +                };
> +
> +                pcie@3,0 {
> +                    reg = <0x21800 0x0 0x0 0x0 0x0>;
> +                    #address-cells = <3>;
> +                    #size-cells = <2>;
> +                    device_type = "pci";
> +                    ranges;
> +                    bus-range = <0x05 0xff>;
> +
> +                    qcom,tx-amplitude-millivolt = <10>;
> +                    pcie@0,0 {
> +                        reg = <0x50000 0x0 0x0 0x0 0x0>;
> +                        #address-cells = <3>;
> +                        #size-cells = <2>;
> +                        device_type = "pci";
> +                        ranges;
> +
> +                        qcom,l1-entry-delay-ns = <10>;
> +                    };
> +
> +                    pcie@0,1 {
> +                        reg = <0x50100 0x0 0x0 0x0 0x0>;
> +                        #address-cells = <3>;
> +                        #size-cells = <2>;
> +                        device_type = "pci";
> +                        ranges;
> +
> +                        qcom,l0s-entry-delay-ns = <10>;
> +                    };
> +                };
> +            };
> +        };
> +    };
> 
> -- 
> 2.34.1
> 

Re: [PATCH v3 6/6] PCI: pwrctl: Add power control driver for qps615

[Bjorn Andersson]

On Tue, Nov 12, 2024 at 08:31:38PM +0530, Krishna chaitanya chundru wrote:
> QPS615 is the PCIe switch which has one upstream and three downstream
> ports. To one of the downstream ports ethernet MAC is connected as endpoint
> device. Other two downstream ports are supposed to connect to external
> device. One Host can connect to QPS615 by upstream port. QPS615 switch
> needs to be configured after powering on and before PCIe link was up.
> 
> The PCIe controller driver already enables link training at the host side
> even before qps615 driver probe happens, due to this when driver enables
> power to the switch it participates in the link training and PCIe link
> may come up before configuring the switch through i2c. To prevent the
> host from participating in link training, disable link training on the
> host side to ensure the link does not come up before the switch is
> configured via I2C.
> 
> Based up on dt property and type of the port, qps615 is configured
> through i2c.

Reviewed-by: Bjorn Andersson <andersson@kernel.org>

Regards,
Bjorn

> 
> Signed-off-by: Krishna chaitanya chundru <quic_krichai@quicinc.com>
> ---
>  drivers/pci/pwrctl/Kconfig             |   8 +
>  drivers/pci/pwrctl/Makefile            |   1 +
>  drivers/pci/pwrctl/pci-pwrctl-qps615.c | 630 +++++++++++++++++++++++++++++++++
>  3 files changed, 639 insertions(+)
> 
> diff --git a/drivers/pci/pwrctl/Kconfig b/drivers/pci/pwrctl/Kconfig
> index 54589bb2403b..fe945d176b8b 100644
> --- a/drivers/pci/pwrctl/Kconfig
> +++ b/drivers/pci/pwrctl/Kconfig
> @@ -10,3 +10,11 @@ config PCI_PWRCTL_PWRSEQ
>  	tristate
>  	select POWER_SEQUENCING
>  	select PCI_PWRCTL
> +
> +config PCI_PWRCTL_QPS615
> +	tristate "PCI Power Control driver for QPS615"
> +	select PCI_PWRCTL
> +	help
> +	  Say Y here to enable the pwrctl driver for Qualcomm
> +	  QPS615 PCIe switch which enables and configures it
> +	  through i2c.
> diff --git a/drivers/pci/pwrctl/Makefile b/drivers/pci/pwrctl/Makefile
> index d308aae4800c..ac563a70c023 100644
> --- a/drivers/pci/pwrctl/Makefile
> +++ b/drivers/pci/pwrctl/Makefile
> @@ -4,3 +4,4 @@ obj-$(CONFIG_PCI_PWRCTL)		+= pci-pwrctl-core.o
>  pci-pwrctl-core-y			:= core.o
>  
>  obj-$(CONFIG_PCI_PWRCTL_PWRSEQ)		+= pci-pwrctl-pwrseq.o
> +obj-$(CONFIG_PCI_PWRCTL_QPS615)		+= pci-pwrctl-qps615.o
> diff --git a/drivers/pci/pwrctl/pci-pwrctl-qps615.c b/drivers/pci/pwrctl/pci-pwrctl-qps615.c
> new file mode 100644
> index 000000000000..c338e35c9083
> --- /dev/null
> +++ b/drivers/pci/pwrctl/pci-pwrctl-qps615.c
> @@ -0,0 +1,630 @@
> +// SPDX-License-Identifier: GPL-2.0-only
> +/*
> + * Copyright (c) 2024 Qualcomm Innovation Center, Inc. All rights reserved.
> + */
> +
> +#include <linux/delay.h>
> +#include <linux/device.h>
> +#include <linux/i2c.h>
> +#include <linux/mod_devicetable.h>
> +#include <linux/module.h>
> +#include <linux/of.h>
> +#include <linux/of_platform.h>
> +#include <linux/pci.h>
> +#include <linux/pci-pwrctl.h>
> +#include <linux/platform_device.h>
> +#include <linux/regulator/consumer.h>
> +#include <linux/string.h>
> +#include <linux/types.h>
> +#include <linux/unaligned.h>
> +
> +#include "../pci.h"
> +
> +#define QPS615_GPIO_CONFIG		0x801208
> +#define QPS615_RESET_GPIO		0x801210
> +
> +#define QPS615_BUS_CONTROL		0x801014
> +
> +#define QPS615_PORT_L0S_DELAY		0x82496c
> +#define QPS615_PORT_L1_DELAY		0x824970
> +
> +#define QPS615_EMBEDDED_ETH_DELAY	0x8200d8
> +#define QPS615_ETH_L1_DELAY_MASK	GENMASK(27, 18)
> +#define QPS615_ETH_L1_DELAY_VALUE(x)	FIELD_PREP(QPS615_ETH_L1_DELAY_MASK, x)
> +#define QPS615_ETH_L0S_DELAY_MASK	GENMASK(17, 13)
> +#define QPS615_ETH_L0S_DELAY_VALUE(x)	FIELD_PREP(QPS615_ETH_L0S_DELAY_MASK, x)
> +
> +#define QPS615_NFTS_2_5_GT		0x824978
> +#define QPS615_NFTS_5_GT		0x82497c
> +
> +#define QPS615_PORT_LANE_ACCESS_ENABLE	0x828000
> +
> +#define QPS615_PHY_RATE_CHANGE_OVERRIDE	0x828040
> +#define QPS615_PHY_RATE_CHANGE		0x828050
> +
> +#define QPS615_TX_MARGIN		0x828234
> +
> +#define QPS615_DFE_ENABLE		0x828a04
> +#define QPS615_DFE_EQ0_MODE		0x828a08
> +#define QPS615_DFE_EQ1_MODE		0x828a0c
> +#define QPS615_DFE_EQ2_MODE		0x828a14
> +#define QPS615_DFE_PD_MASK		0x828254
> +
> +#define QPS615_PORT_SELECT		0x82c02c
> +#define QPS615_PORT_ACCESS_ENABLE	0x82c030
> +
> +#define QPS615_POWER_CONTROL		0x82b09c
> +#define QPS615_POWER_CONTROL_OVREN	0x82b2c8
> +
> +#define QPS615_FREQ_125_MHZ		125000000
> +#define QPS615_FREQ_250_MHZ		250000000
> +
> +#define QPS615_GPIO_MASK		0xfffffff3
> +
> +struct qps615_pwrctl_reg_setting {
> +	unsigned int offset;
> +	unsigned int val;
> +};
> +
> +enum qps615_pwrctl_ports {
> +	QPS615_USP,
> +	QPS615_DSP1,
> +	QPS615_DSP2,
> +	QPS615_DSP3,
> +	QPS615_ETHERNET,
> +	QPS615_MAX
> +};
> +
> +struct qps615_pwrctl_cfg {
> +	u32 l0s_delay;
> +	u32 l1_delay;
> +	u32 tx_amp;
> +	u32 nfts;
> +	bool disable_dfe;
> +	bool disable_port;
> +	bool axi_freq_125;
> +};
> +
> +#define QPS615_PWRCTL_MAX_SUPPLY	6
> +
> +struct qps615_pwrctl_ctx {
> +	struct regulator_bulk_data supplies[QPS615_PWRCTL_MAX_SUPPLY];
> +	struct qps615_pwrctl_cfg cfg[QPS615_MAX];
> +	struct gpio_desc *reset_gpio;
> +	struct i2c_adapter *adapter;
> +	struct i2c_client *client;
> +	struct pci_pwrctl pwrctl;
> +};
> +
> +/*
> + * downstream port power off sequence, hardcoding the address
> + * as we don't know register names for these register offsets.
> + */
> +static const struct qps615_pwrctl_reg_setting common_pwroff_seq[] = {
> +	{0x82900c, 0x1},
> +	{0x829010, 0x1},
> +	{0x829018, 0x0},
> +	{0x829020, 0x1},
> +	{0x82902c, 0x1},
> +	{0x829030, 0x1},
> +	{0x82903c, 0x1},
> +	{0x829058, 0x0},
> +	{0x82905c, 0x1},
> +	{0x829060, 0x1},
> +	{0x8290cc, 0x1},
> +	{0x8290d0, 0x1},
> +	{0x8290d8, 0x1},
> +	{0x8290e0, 0x1},
> +	{0x8290e8, 0x1},
> +	{0x8290ec, 0x1},
> +	{0x8290f4, 0x1},
> +	{0x82910c, 0x1},
> +	{0x829110, 0x1},
> +	{0x829114, 0x1},
> +};
> +
> +static const struct qps615_pwrctl_reg_setting dsp1_pwroff_seq[] = {
> +	{QPS615_PORT_ACCESS_ENABLE, 0x2},
> +	{QPS615_PORT_LANE_ACCESS_ENABLE, 0x3},
> +	{QPS615_POWER_CONTROL, 0x014f4804},
> +	{QPS615_POWER_CONTROL_OVREN, 0x1},
> +	{QPS615_PORT_ACCESS_ENABLE, 0x4},
> +};
> +
> +static const struct qps615_pwrctl_reg_setting dsp2_pwroff_seq[] = {
> +	{QPS615_PORT_ACCESS_ENABLE, 0x8},
> +	{QPS615_PORT_LANE_ACCESS_ENABLE, 0x1},
> +	{QPS615_POWER_CONTROL, 0x014f4804},
> +	{QPS615_POWER_CONTROL_OVREN, 0x1},
> +	{QPS615_PORT_ACCESS_ENABLE, 0x8},
> +};
> +
> +/*
> + * Since all transfers are initiated by the probe, no locks are necessary,
> + * ensuring there are no concurrent calls.
> + */
> +static int qps615_pwrctl_i2c_write(struct i2c_client *client,
> +				   u32 reg_addr, u32 reg_val)
> +{
> +	struct i2c_msg msg;
> +	u8 msg_buf[7];
> +	int ret;
> +
> +	msg.addr = client->addr;
> +	msg.len = 7;
> +	msg.flags = 0;
> +
> +	/* Big Endian for reg addr */
> +	put_unaligned_be24(reg_addr, &msg_buf[0]);
> +
> +	/* Little Endian for reg val */
> +	put_unaligned_le32(reg_val, &msg_buf[3]);
> +
> +	msg.buf = msg_buf;
> +	ret = i2c_transfer(client->adapter, &msg, 1);
> +	return ret == 1 ? 0 : ret;
> +}
> +
> +static int qps615_pwrctl_i2c_read(struct i2c_client *client,
> +				  u32 reg_addr, u32 *reg_val)
> +{
> +	struct i2c_msg msg[2];
> +	u8 wr_data[3];
> +	u32 rd_data;
> +	int ret;
> +
> +	msg[0].addr = client->addr;
> +	msg[0].len = 3;
> +	msg[0].flags = 0;
> +
> +	/* Big Endian for reg addr */
> +	put_unaligned_be24(reg_addr, &wr_data[0]);
> +
> +	msg[0].buf = wr_data;
> +
> +	msg[1].addr = client->addr;
> +	msg[1].len = 4;
> +	msg[1].flags = I2C_M_RD;
> +
> +	msg[1].buf = (u8 *)&rd_data;
> +
> +	ret = i2c_transfer(client->adapter, &msg[0], 2);
> +	if (ret == 2) {
> +		*reg_val = get_unaligned_le32(&rd_data);
> +		return 0;
> +	}
> +
> +	/* If only one message successfully completed, return -ENODEV */
> +	return ret == 1 ? -ENODEV : ret;
> +}
> +
> +static int qps615_pwrctl_i2c_bulk_write(struct i2c_client *client,
> +					const struct qps615_pwrctl_reg_setting *seq, int len)
> +{
> +	int ret, i;
> +
> +	for (i = 0; i < len; i++) {
> +		ret = qps615_pwrctl_i2c_write(client, seq[i].offset, seq[i].val);
> +		if (ret)
> +			return ret;
> +	}
> +
> +	return 0;
> +}
> +
> +static int qps615_pwrctl_disable_port(struct qps615_pwrctl_ctx *ctx,
> +				      enum qps615_pwrctl_ports port)
> +{
> +	const struct qps615_pwrctl_reg_setting *seq;
> +	int ret, len;
> +
> +	if (port == QPS615_DSP1) {
> +		seq = dsp1_pwroff_seq;
> +		len = ARRAY_SIZE(dsp1_pwroff_seq);
> +	} else {
> +		seq = dsp2_pwroff_seq;
> +		len = ARRAY_SIZE(dsp2_pwroff_seq);
> +	}
> +
> +	ret = qps615_pwrctl_i2c_bulk_write(ctx->client, seq, len);
> +	if (ret)
> +		return ret;
> +
> +	return qps615_pwrctl_i2c_bulk_write(ctx->client,
> +					    common_pwroff_seq, ARRAY_SIZE(common_pwroff_seq));
> +}
> +
> +static int qps615_pwrctl_set_l0s_l1_entry_delay(struct qps615_pwrctl_ctx *ctx,
> +						enum qps615_pwrctl_ports port, bool is_l1, u32 ns)
> +{
> +	u32 rd_val, units, mask;
> +	int ret;
> +
> +	/* convert to units of 256ns */
> +	units = ns / 256;
> +
> +	if (port == QPS615_ETHERNET) {
> +		ret = qps615_pwrctl_i2c_read(ctx->client, QPS615_EMBEDDED_ETH_DELAY, &rd_val);
> +		if (ret)
> +			return ret;
> +		mask = is_l1 ? QPS615_ETH_L1_DELAY_MASK : QPS615_ETH_L0S_DELAY_MASK;
> +		rd_val = u32_replace_bits(rd_val, units, mask);
> +		return qps615_pwrctl_i2c_write(ctx->client, QPS615_EMBEDDED_ETH_DELAY, rd_val);
> +	}
> +
> +	ret = qps615_pwrctl_i2c_write(ctx->client, QPS615_PORT_SELECT, BIT(port));
> +	if (ret)
> +		return ret;
> +
> +	return qps615_pwrctl_i2c_write(ctx->client,
> +				       is_l1 ? QPS615_PORT_L1_DELAY : QPS615_PORT_L0S_DELAY, units);
> +}
> +
> +static int qps615_pwrctl_set_tx_amplitude(struct qps615_pwrctl_ctx *ctx,
> +					  enum qps615_pwrctl_ports port, u32 amp)
> +{
> +	int port_access;
> +
> +	switch (port) {
> +	case QPS615_USP:
> +		port_access = 0x1;
> +		break;
> +	case QPS615_DSP1:
> +		port_access = 0x2;
> +		break;
> +	case QPS615_DSP2:
> +		port_access = 0x8;
> +		break;
> +	default:
> +		return -EINVAL;
> +	};
> +
> +	struct qps615_pwrctl_reg_setting tx_amp_seq[] = {
> +		{QPS615_PORT_ACCESS_ENABLE, port_access},
> +		{QPS615_PORT_LANE_ACCESS_ENABLE, 0x3},
> +		{QPS615_TX_MARGIN, amp},
> +	};
> +
> +	return qps615_pwrctl_i2c_bulk_write(ctx->client, tx_amp_seq, ARRAY_SIZE(tx_amp_seq));
> +}
> +
> +static int qps615_pwrctl_disable_dfe(struct qps615_pwrctl_ctx *ctx,
> +				     enum qps615_pwrctl_ports port)
> +{
> +	int port_access, lane_access = 0x3;
> +	u32 phy_rate = 0x21;
> +
> +	switch (port) {
> +	case QPS615_USP:
> +		phy_rate = 0x1;
> +		port_access = 0x1;
> +		break;
> +	case QPS615_DSP1:
> +		port_access = 0x2;
> +		break;
> +	case QPS615_DSP2:
> +		port_access = 0x8;
> +		lane_access = 0x1;
> +		break;
> +	default:
> +		return -EINVAL;
> +	};
> +
> +	struct qps615_pwrctl_reg_setting disable_dfe_seq[] = {
> +		{QPS615_PORT_ACCESS_ENABLE, port_access},
> +		{QPS615_PORT_LANE_ACCESS_ENABLE, lane_access},
> +		{QPS615_DFE_ENABLE, 0x0},
> +		{QPS615_DFE_EQ0_MODE, 0x411},
> +		{QPS615_DFE_EQ1_MODE, 0x11},
> +		{QPS615_DFE_EQ2_MODE, 0x11},
> +		{QPS615_DFE_PD_MASK, 0x7},
> +		{QPS615_PHY_RATE_CHANGE_OVERRIDE, 0x10},
> +		{QPS615_PHY_RATE_CHANGE, phy_rate},
> +		{QPS615_PHY_RATE_CHANGE, 0x0},
> +		{QPS615_PHY_RATE_CHANGE_OVERRIDE, 0x0},
> +	};
> +
> +	return qps615_pwrctl_i2c_bulk_write(ctx->client,
> +					    disable_dfe_seq, ARRAY_SIZE(disable_dfe_seq));
> +}
> +
> +static int qps615_pwrctl_set_nfts(struct qps615_pwrctl_ctx *ctx,
> +				  enum qps615_pwrctl_ports port, u32 nfts)
> +{
> +	int ret;
> +	struct qps615_pwrctl_reg_setting nfts_seq[] = {
> +		{QPS615_NFTS_2_5_GT, nfts},
> +		{QPS615_NFTS_5_GT, nfts},
> +	};
> +
> +	ret =  qps615_pwrctl_i2c_write(ctx->client, QPS615_PORT_SELECT, BIT(port));
> +	if (ret)
> +		return ret;
> +
> +	return qps615_pwrctl_i2c_bulk_write(ctx->client, nfts_seq, ARRAY_SIZE(nfts_seq));
> +}
> +
> +static int qps615_pwrctl_assert_deassert_reset(struct qps615_pwrctl_ctx *ctx, bool deassert)
> +{
> +	int ret, val;
> +
> +	ret = qps615_pwrctl_i2c_write(ctx->client, QPS615_GPIO_CONFIG, QPS615_GPIO_MASK);
> +	if (ret)
> +		return ret;
> +
> +	val = deassert ? 0xc : 0;
> +
> +	return qps615_pwrctl_i2c_write(ctx->client, QPS615_RESET_GPIO, val);
> +}
> +
> +static int qps615_pwrctl_parse_device_dt(struct qps615_pwrctl_ctx *ctx, struct device_node *node,
> +					 enum qps615_pwrctl_ports port)
> +{
> +	struct qps615_pwrctl_cfg *cfg;
> +	u32 axi_freq = 0;
> +	int ret;
> +
> +	cfg = &ctx->cfg[port];
> +
> +	if (!of_device_is_available(node)) {
> +		cfg->disable_port = true;
> +		return 0;
> +	};
> +
> +	ret = of_property_read_u32(node, "qcom,axi-clk-freq-hz", &axi_freq);
> +	if (ret && ret != -EINVAL)
> +		return ret;
> +	else if (axi_freq && (axi_freq != QPS615_FREQ_125_MHZ || axi_freq != QPS615_FREQ_250_MHZ))
> +		return -EINVAL;
> +	else if (axi_freq == QPS615_FREQ_125_MHZ)
> +		cfg->axi_freq_125 = true;
> +
> +	ret = of_property_read_u32(node, "qcom,l0s-entry-delay-ns", &cfg->l0s_delay);
> +	if (ret && ret != -EINVAL)
> +		return ret;
> +
> +	ret = of_property_read_u32(node, "qcom,l1-entry-delay-ns", &cfg->l1_delay);
> +	if (ret && ret != -EINVAL)
> +		return ret;
> +
> +	ret = of_property_read_u32(node, "qcom,tx-amplitude-millivolt", &cfg->tx_amp);
> +	if (ret && ret != -EINVAL)
> +		return ret;
> +
> +	ret = of_property_read_u32(node, "qcom,nfts", &cfg->nfts);
> +	if (ret && ret != -EINVAL)
> +		return ret;
> +
> +	cfg->disable_dfe = of_property_read_bool(node, "qcom,no-dfe-support");
> +
> +	return 0;
> +}
> +
> +static void qps615_pwrctl_power_off(struct qps615_pwrctl_ctx *ctx)
> +{
> +	gpiod_set_value(ctx->reset_gpio, 1);
> +
> +	regulator_bulk_disable(ARRAY_SIZE(ctx->supplies), ctx->supplies);
> +}
> +
> +static int qps615_pwrctl_power_on(struct qps615_pwrctl_ctx *ctx)
> +{
> +	struct qps615_pwrctl_cfg *cfg;
> +	int ret, i;
> +
> +	ret = regulator_bulk_enable(ARRAY_SIZE(ctx->supplies), ctx->supplies);
> +	if (ret < 0)
> +		return dev_err_probe(ctx->pwrctl.dev, ret, "cannot enable regulators\n");
> +
> +	gpiod_set_value(ctx->reset_gpio, 0);
> +
> +	 /* wait for the internal osc frequency to stablise */
> +	usleep_range(10000, 10500);
> +
> +	ret = qps615_pwrctl_assert_deassert_reset(ctx, false);
> +	if (ret)
> +		goto out;
> +
> +	if (ctx->cfg[QPS615_USP].axi_freq_125) {
> +		ret = qps615_pwrctl_i2c_write(ctx->client, QPS615_BUS_CONTROL, BIT(16));
> +		if (ret)
> +			dev_err(ctx->pwrctl.dev, "Setting AXI clk freq failed %d\n", ret);
> +	}
> +
> +	for (i = 0; i < QPS615_MAX; i++) {
> +		cfg = &ctx->cfg[i];
> +		if (cfg->disable_port) {
> +			ret = qps615_pwrctl_disable_port(ctx, i);
> +			if (ret) {
> +				dev_err(ctx->pwrctl.dev, "Disabling port failed\n");
> +				goto out;
> +			}
> +		}
> +
> +		if (cfg->l0s_delay) {
> +			ret = qps615_pwrctl_set_l0s_l1_entry_delay(ctx, i, false, cfg->l0s_delay);
> +			if (ret) {
> +				dev_err(ctx->pwrctl.dev, "Setting L0s entry delay failed\n");
> +				goto out;
> +			}
> +		}
> +
> +		if (cfg->l1_delay) {
> +			ret = qps615_pwrctl_set_l0s_l1_entry_delay(ctx, i, true, cfg->l1_delay);
> +			if (ret) {
> +				dev_err(ctx->pwrctl.dev, "Setting L1 entry delay failed\n");
> +				goto out;
> +			}
> +		}
> +
> +		if (cfg->tx_amp) {
> +			ret = qps615_pwrctl_set_tx_amplitude(ctx, i, cfg->tx_amp);
> +			if (ret) {
> +				dev_err(ctx->pwrctl.dev, "Setting Tx amplitube failed\n");
> +				goto out;
> +			}
> +		}
> +
> +		if (cfg->nfts) {
> +			ret = qps615_pwrctl_set_nfts(ctx, i, cfg->nfts);
> +			if (ret) {
> +				dev_err(ctx->pwrctl.dev, "Setting nfts failed\n");
> +				goto out;
> +			}
> +		}
> +
> +		if (cfg->disable_dfe) {
> +			ret = qps615_pwrctl_disable_dfe(ctx, i);
> +			if (ret) {
> +				dev_err(ctx->pwrctl.dev, "Disabling DFE failed\n");
> +				goto out;
> +			}
> +		}
> +	}
> +
> +	ret = qps615_pwrctl_assert_deassert_reset(ctx, true);
> +	if (!ret)
> +		return 0;
> +
> +out:
> +	qps615_pwrctl_power_off(ctx);
> +	return ret;
> +}
> +
> +static int qps615_pwrctl_probe(struct platform_device *pdev)
> +{
> +	struct device *dev = &pdev->dev;
> +	struct pci_host_bridge *bridge;
> +	enum qps615_pwrctl_ports port;
> +	struct qps615_pwrctl_ctx *ctx;
> +	int ret, addr;
> +
> +	bridge = pci_find_host_bridge(to_pci_dev(dev->parent)->bus);
> +
> +	ctx = devm_kzalloc(dev, sizeof(*ctx), GFP_KERNEL);
> +	if (!ctx)
> +		return -ENOMEM;
> +
> +	ret = of_property_read_u32_index(pdev->dev.of_node, "i2c-parent", 1, &addr);
> +	if (ret)
> +		return dev_err_probe(dev, ret, "Failed to read i2c-parent property\n");
> +
> +	ctx->adapter = of_find_i2c_adapter_by_node(of_parse_phandle(dev->of_node, "i2c-parent", 0));
> +	of_node_put(dev->of_node);
> +	if (!ctx->adapter)
> +		return dev_err_probe(dev, -EPROBE_DEFER, "Failed to find I2C adapter\n");
> +
> +	ctx->client = i2c_new_dummy_device(ctx->adapter, addr);
> +	if (IS_ERR(ctx->client)) {
> +		dev_err(dev, "Failed to create I2C client\n");
> +		i2c_put_adapter(ctx->adapter);
> +		return PTR_ERR(ctx->client);
> +	}
> +
> +	ctx->supplies[0].supply = "vddc";
> +	ctx->supplies[1].supply = "vdd18";
> +	ctx->supplies[2].supply = "vdd09";
> +	ctx->supplies[3].supply = "vddio1";
> +	ctx->supplies[4].supply = "vddio2";
> +	ctx->supplies[5].supply = "vddio18";
> +	ret = devm_regulator_bulk_get(dev, ARRAY_SIZE(ctx->supplies), ctx->supplies);
> +	if (ret) {
> +		dev_err_probe(dev, ret,
> +			      "failed to get supply regulator\n");
> +		goto remove_i2c;
> +	}
> +
> +	ctx->reset_gpio = devm_gpiod_get(dev, "reset", GPIOD_ASIS);
> +	if (IS_ERR(ctx->reset_gpio)) {
> +		ret = dev_err_probe(dev, PTR_ERR(ctx->reset_gpio), "failed to get reset GPIO\n");
> +		goto remove_i2c;
> +	}
> +
> +	platform_set_drvdata(pdev, ctx);
> +
> +	pci_pwrctl_init(&ctx->pwrctl, dev);
> +
> +	port = QPS615_USP;
> +	ret = qps615_pwrctl_parse_device_dt(ctx, pdev->dev.of_node, port);
> +	if (ret) {
> +		dev_err(dev, "failed to parse device tree properties: %d\n", ret);
> +		goto remove_i2c;
> +	}
> +
> +	/*
> +	 * Downstream ports are always children of the upstream port.
> +	 * The first node represents DSP1, the second node represents DSP2, and so on.
> +	 */
> +	for_each_child_of_node_scoped(pdev->dev.of_node, child) {
> +		ret = qps615_pwrctl_parse_device_dt(ctx, child, port++);
> +		if (ret)
> +			break;
> +		/* Embedded ethernet device are under DSP3 */
> +		if (port == QPS615_DSP3)
> +			for_each_child_of_node_scoped(child, child1) {
> +				ret = qps615_pwrctl_parse_device_dt(ctx, child1, port++);
> +				if (ret)
> +					break;
> +			}
> +	}
> +	if (ret) {
> +		dev_err(dev, "failed to parse device tree properties: %d\n", ret);
> +		goto remove_i2c;
> +	}
> +
> +	if (bridge->ops->stop_link)
> +		bridge->ops->stop_link(to_pci_dev(dev->parent)->bus);
> +
> +	ret = qps615_pwrctl_power_on(ctx);
> +	if (ret)
> +		goto remove_i2c;
> +
> +	if (bridge->ops->start_link) {
> +		ret = bridge->ops->start_link(to_pci_dev(dev->parent)->bus);
> +		if (ret)
> +			goto power_off;
> +	}
> +
> +	ret = devm_pci_pwrctl_device_set_ready(dev, &ctx->pwrctl);
> +	if (ret)
> +		goto power_off;
> +
> +	return 0;
> +
> +power_off:
> +	qps615_pwrctl_power_off(ctx);
> +remove_i2c:
> +	i2c_unregister_device(ctx->client);
> +	i2c_put_adapter(ctx->adapter);
> +	return ret;
> +}
> +
> +static void qps615_pwrctl_remove(struct platform_device *pdev)
> +{
> +	struct qps615_pwrctl_ctx *ctx = platform_get_drvdata(pdev);
> +
> +	qps615_pwrctl_power_off(ctx);
> +	i2c_unregister_device(ctx->client);
> +	i2c_put_adapter(ctx->adapter);
> +}
> +
> +static const struct of_device_id qps615_pwrctl_of_match[] = {
> +	{ .compatible = "pci1179,0623"},
> +	{ }
> +};
> +MODULE_DEVICE_TABLE(of, qps615_pwrctl_of_match);
> +
> +static struct platform_driver qps615_pwrctl_driver = {
> +	.driver = {
> +		.name = "pwrctl-qps615",
> +		.of_match_table = qps615_pwrctl_of_match,
> +		.probe_type = PROBE_PREFER_ASYNCHRONOUS,
> +	},
> +	.probe = qps615_pwrctl_probe,
> +	.remove_new = qps615_pwrctl_remove,
> +};
> +module_platform_driver(qps615_pwrctl_driver);
> +
> +MODULE_AUTHOR("Krishna chaitanya chundru <quic_krichai@quicinc.com>");
> +MODULE_DESCRIPTION("Qualcomm QPS615 power control driver");
> +MODULE_LICENSE("GPL");
> 
> -- 
> 2.34.1
> 

Re: [PATCH v3 6/6] PCI: pwrctl: Add power control driver for qps615

[Bjorn Andersson]

On Tue, Nov 12, 2024 at 09:51:42AM -0600, Bjorn Andersson wrote:
> On Tue, Nov 12, 2024 at 08:31:38PM +0530, Krishna chaitanya chundru wrote:
> > QPS615 is the PCIe switch which has one upstream and three downstream
> > ports. To one of the downstream ports ethernet MAC is connected as endpoint
> > device. Other two downstream ports are supposed to connect to external
> > device. One Host can connect to QPS615 by upstream port. QPS615 switch
> > needs to be configured after powering on and before PCIe link was up.
> > 
> > The PCIe controller driver already enables link training at the host side
> > even before qps615 driver probe happens, due to this when driver enables
> > power to the switch it participates in the link training and PCIe link
> > may come up before configuring the switch through i2c. To prevent the
> > host from participating in link training, disable link training on the
> > host side to ensure the link does not come up before the switch is
> > configured via I2C.
> > 
> > Based up on dt property and type of the port, qps615 is configured
> > through i2c.
> 
> Reviewed-by: Bjorn Andersson <andersson@kernel.org>
> 

Sorry, while I think this looks okay, this patch still does not compile.

Trying to compile this code with either clang 14 or 17 I still get the
following error:

  CC [M]  drivers/pci/pwrctl/pci-pwrctl-qps615.o
In file included from drivers/pci/pwrctl/pci-pwrctl-qps615.c:6:
In file included from ./include/linux/delay.h:13:
In file included from ./include/linux/sched.h:13:
In file included from ./arch/arm64/include/asm/processor.h:29:
In file included from ./include/linux/cache.h:6:
In file included from ./arch/arm64/include/asm/cache.h:43:
In file included from ./arch/arm64/include/asm/cputype.h:228:
In file included from ./arch/arm64/include/asm/sysreg.h:1129:
./include/linux/bitfield.h:166:3: error: call to '__bad_mask' declared with 'error' attribute: bad bitfield mask
  166 |                 __bad_mask();
      |                 ^
./include/linux/bitfield.h:166:3: error: call to '__bad_mask' declared with 'error' attribute: bad bitfield mask
2 errors generated.
make[5]: *** [scripts/Makefile.build:229: drivers/pci/pwrctl/pci-pwrctl-qps615.o] Error 1
make[4]: *** [scripts/Makefile.build:478: drivers/pci/pwrctl] Error 2
make[3]: *** [scripts/Makefile.build:478: drivers/pci] Error 2
make[2]: *** [scripts/Makefile.build:478: drivers] Error 2
make[1]: *** [/home/bjorn/sandbox/kernel/sm8150/Makefile:1946: .] Error 2
make: *** [Makefile:224: __sub-make] Error 2

This is caused by the way you invoke u32_replace_bits()

Regards,
Bjorn

Re: [PATCH v3 4/6] PCI: dwc: Add support for new pci function op

[Bjorn Helgaas]

On Tue, Nov 12, 2024 at 08:31:36PM +0530, Krishna chaitanya chundru wrote:
> Add the support for stop_link() and  start_link() function op.

When you update the series for the build issue, also update the
subject line here so it's more useful by itself, e.g.,

  PCI: dwc: Implement .start_link(), .stop_link() hooks

Seems like the .host_start_link() bits might be a separate patch?
They're not mentioned in this commit log and don't look directly
related.

> Signed-off-by: Krishna chaitanya chundru <quic_krichai@quicinc.com>
> ---
>  drivers/pci/controller/dwc/pcie-designware-host.c | 18 ++++++++++++++++++
>  drivers/pci/controller/dwc/pcie-designware.h      | 16 ++++++++++++++++
>  2 files changed, 34 insertions(+)
> 
> diff --git a/drivers/pci/controller/dwc/pcie-designware-host.c b/drivers/pci/controller/dwc/pcie-designware-host.c
> index 3e41865c7290..d7e7f782390a 100644
> --- a/drivers/pci/controller/dwc/pcie-designware-host.c
> +++ b/drivers/pci/controller/dwc/pcie-designware-host.c
> @@ -691,10 +691,28 @@ void __iomem *dw_pcie_own_conf_map_bus(struct pci_bus *bus, unsigned int devfn,
>  }
>  EXPORT_SYMBOL_GPL(dw_pcie_own_conf_map_bus);
>  
> +static int dw_pcie_op_start_link(struct pci_bus *bus)
> +{
> +	struct dw_pcie_rp *pp = bus->sysdata;
> +	struct dw_pcie *pci = to_dw_pcie_from_pp(pp);
> +
> +	return dw_pcie_host_start_link(pci);
> +}
> +
> +static void dw_pcie_op_stop_link(struct pci_bus *bus)
> +{
> +	struct dw_pcie_rp *pp = bus->sysdata;
> +	struct dw_pcie *pci = to_dw_pcie_from_pp(pp);
> +
> +	dw_pcie_host_stop_link(pci);
> +}
> +
>  static struct pci_ops dw_pcie_ops = {
>  	.map_bus = dw_pcie_own_conf_map_bus,
>  	.read = pci_generic_config_read,
>  	.write = pci_generic_config_write,
> +	.start_link = dw_pcie_op_start_link,
> +	.stop_link = dw_pcie_op_stop_link,
>  };
>  
>  static int dw_pcie_iatu_setup(struct dw_pcie_rp *pp)
> diff --git a/drivers/pci/controller/dwc/pcie-designware.h b/drivers/pci/controller/dwc/pcie-designware.h
> index 347ab74ac35a..b88b4edafcc3 100644
> --- a/drivers/pci/controller/dwc/pcie-designware.h
> +++ b/drivers/pci/controller/dwc/pcie-designware.h
> @@ -433,6 +433,8 @@ struct dw_pcie_ops {
>  	enum dw_pcie_ltssm (*get_ltssm)(struct dw_pcie *pcie);
>  	int	(*start_link)(struct dw_pcie *pcie);
>  	void	(*stop_link)(struct dw_pcie *pcie);
> +	int	(*host_start_link)(struct dw_pcie *pcie);
> +	void	(*host_stop_link)(struct dw_pcie *pcie);
>  };
>  
>  struct dw_pcie {
> @@ -665,6 +667,20 @@ static inline void dw_pcie_stop_link(struct dw_pcie *pci)
>  		pci->ops->stop_link(pci);
>  }
>  
> +static inline int dw_pcie_host_start_link(struct dw_pcie *pci)
> +{
> +	if (pci->ops && pci->ops->host_start_link)
> +		return pci->ops->host_start_link(pci);
> +
> +	return 0;
> +}
> +
> +static inline void dw_pcie_host_stop_link(struct dw_pcie *pci)
> +{
> +	if (pci->ops && pci->ops->host_stop_link)
> +		pci->ops->host_stop_link(pci);
> +}
> +
>  static inline enum dw_pcie_ltssm dw_pcie_get_ltssm(struct dw_pcie *pci)
>  {
>  	u32 val;
> 
> -- 
> 2.34.1
> 

Re: [PATCH v3 5/6] PCI: qcom: Add support for host_stop_link() & host_start_link()

[Bjorn Helgaas]

On Tue, Nov 12, 2024 at 08:31:37PM +0530, Krishna chaitanya chundru wrote:
> For the switches like QPS615 which needs to configure it before
> the PCIe link is established.
> 
> If the link is up, the boatloader might powered and configured the
> endpoint/switch already. In that case don't touch PCIe link else
> assert the PERST# and disable LTSSM bit so that PCIe controller
> will not participate in the link training as part of host_stop_link().

s/boatloader/bootloader/
s/might powered/might have powered/ ?

> De-assert the PERST# and enable LTSSM bit back in host_start_link().
> 
> Introduce ltssm_disable function op to stop the link training.

Re: [PATCH v3 3/6] PCI: Add new start_link() & stop_link function ops

[Bjorn Helgaas]

On Tue, Nov 12, 2024 at 08:31:35PM +0530, Krishna chaitanya chundru wrote:
> Certain devices like QPS615 which uses PCI pwrctl framework
> needs to configure the device before PCI link is up.
> 
> If the controller driver already enables link training as part of
> its probe, after the device is powered on, controller and device
> participates in the link training and link can come up immediately
> and maynot have time to configure the device.
> 
> So we need to stop the link training by using stop_link() and enable
> them back after device is configured by using start_link().

s/maynot/may not/

I think I'm missing the point here.  My assumption is this:

  - device starts as powered off
  - pwrctl turns on the power
  - link trains automatically
  - qcom driver claims device
  - qcom needs to configure things that need to happen before link
    train

but that can't be quite right because you wouldn't be able to fix it
by changing the qcom driver because it's not in the picture until the
link is already trained.

So maybe you can add a little more context here?

> Signed-off-by: Krishna chaitanya chundru <quic_krichai@quicinc.com>
> ---
>  include/linux/pci.h | 2 ++
>  1 file changed, 2 insertions(+)
> 
> diff --git a/include/linux/pci.h b/include/linux/pci.h
> index 573b4c4c2be6..fe6a9b4b22ee 100644
> --- a/include/linux/pci.h
> +++ b/include/linux/pci.h
> @@ -806,6 +806,8 @@ struct pci_ops {
>  	void __iomem *(*map_bus)(struct pci_bus *bus, unsigned int devfn, int where);
>  	int (*read)(struct pci_bus *bus, unsigned int devfn, int where, int size, u32 *val);
>  	int (*write)(struct pci_bus *bus, unsigned int devfn, int where, int size, u32 val);
> +	int (*start_link)(struct pci_bus *bus);
> +	void (*stop_link)(struct pci_bus *bus);
>  };
>  
>  /*
> 
> -- 
> 2.34.1
> 

Re: [PATCH v3 3/6] PCI: Add new start_link() & stop_link function ops

[Krishna Chaitanya Chundru]

On 11/13/2024 5:11 AM, Bjorn Helgaas wrote:
> On Tue, Nov 12, 2024 at 08:31:35PM +0530, Krishna chaitanya chundru wrote:
>> Certain devices like QPS615 which uses PCI pwrctl framework
>> needs to configure the device before PCI link is up.
>>
>> If the controller driver already enables link training as part of
>> its probe, after the device is powered on, controller and device
>> participates in the link training and link can come up immediately
>> and maynot have time to configure the device.
>>
>> So we need to stop the link training by using stop_link() and enable
>> them back after device is configured by using start_link().
> 
> s/maynot/may not/
> 
> I think I'm missing the point here.  My assumption is this:
> 
>    - device starts as powered off
>    - pwrctl turns on the power
>    - link trains automatically
>    - qcom driver claims device
>    - qcom needs to configure things that need to happen before link
>      train
> The flow is this way
      - device starts as powered off
      - qcom controller driver probes
      - qcom controller driver enables resources and starts link training
      - As device is powered off link will not be up
      - qcom/dwc driver starts enumeration even if the link is not up
      - pci detects root complex device and creates pci_dev for it
      - As part of pci_dev creation pwrctl frameworks comes into picture
      - pwrctl turns on the power.

The pwrctl driver is coming up only after qcom driver enables link
training. Due to this flow we are trying add these stop_link() &
start_link() so that before powering on the device stop the link
training so that hw will not participate in the link training.
Then power on the device do the required configurations and again start
the link training.

- Krishna Chaitanya.
> but that can't be quite right because you wouldn't be able to fix it
> by changing the qcom driver because it's not in the picture until the
> link is already trained.
> 
> So maybe you can add a little more context here?
>  >> Signed-off-by: Krishna chaitanya chundru <quic_krichai@quicinc.com>
>> ---
>>   include/linux/pci.h | 2 ++
>>   1 file changed, 2 insertions(+)
>>
>> diff --git a/include/linux/pci.h b/include/linux/pci.h
>> index 573b4c4c2be6..fe6a9b4b22ee 100644
>> --- a/include/linux/pci.h
>> +++ b/include/linux/pci.h
>> @@ -806,6 +806,8 @@ struct pci_ops {
>>   	void __iomem *(*map_bus)(struct pci_bus *bus, unsigned int devfn, int where);
>>   	int (*read)(struct pci_bus *bus, unsigned int devfn, int where, int size, u32 *val);
>>   	int (*write)(struct pci_bus *bus, unsigned int devfn, int where, int size, u32 val);
>> +	int (*start_link)(struct pci_bus *bus);
>> +	void (*stop_link)(struct pci_bus *bus);
>>   };
>>   
>>   /*
>>
>> -- 
>> 2.34.1
>>

Re: [PATCH v3 6/6] PCI: pwrctl: Add power control driver for qps615

[Bartosz Golaszewski]

On Tue, Nov 12, 2024 at 4:02 PM Krishna chaitanya chundru
<quic_krichai@quicinc.com> wrote:
>
> QPS615 is the PCIe switch which has one upstream and three downstream
> ports. To one of the downstream ports ethernet MAC is connected as endpoint
> device. Other two downstream ports are supposed to connect to external
> device. One Host can connect to QPS615 by upstream port. QPS615 switch
> needs to be configured after powering on and before PCIe link was up.
>
> The PCIe controller driver already enables link training at the host side
> even before qps615 driver probe happens, due to this when driver enables
> power to the switch it participates in the link training and PCIe link
> may come up before configuring the switch through i2c. To prevent the
> host from participating in link training, disable link training on the
> host side to ensure the link does not come up before the switch is
> configured via I2C.
>
> Based up on dt property and type of the port, qps615 is configured
> through i2c.
>
> Signed-off-by: Krishna chaitanya chundru <quic_krichai@quicinc.com>
> ---

Krishna,

This looks really good thanks.

One nit: I'd rename qps615_pwrctl_power_on() to something else as most
of its code does configure the switch, not power it up. Maybe
qps615_pwrctl_bring_up()?

With that and the build issue fixed:

Reviewed-by: Bartosz Golaszewski <bartosz.golaszewski@linaro.org>

I'll test it once it compiles.

Bart

Re: [PATCH v3 2/6] arm64: dts: qcom: qcs6490-rb3gen2: Add node for qps615

[Manivannan Sadhasivam]

On Tue, Nov 12, 2024 at 08:31:34PM +0530, Krishna chaitanya chundru wrote:
> Add QPS615 PCIe switch node which has 3 downstream ports and in one
> downstream port two embedded ethernet devices are present.
> 
> Power to the QPS615 is supplied through two LDO regulators, controlled
> by two GPIOs, these are added as fixed regulators. And the QPS615 is
> configured through i2c.
> 
> Signed-off-by: Krishna chaitanya chundru <quic_krichai@quicinc.com>

Acked-by: Manivannan Sadhasivam <manivannan.sadhasivam@linaro.org>

One comment below.

> ---
>  arch/arm64/boot/dts/qcom/qcs6490-rb3gen2.dts | 115 +++++++++++++++++++++++++++
>  arch/arm64/boot/dts/qcom/sc7280.dtsi         |   2 +-
>  2 files changed, 116 insertions(+), 1 deletion(-)
> 
> diff --git a/arch/arm64/boot/dts/qcom/qcs6490-rb3gen2.dts b/arch/arm64/boot/dts/qcom/qcs6490-rb3gen2.dts
> index 0d45662b8028..0e890841b600 100644
> --- a/arch/arm64/boot/dts/qcom/qcs6490-rb3gen2.dts
> +++ b/arch/arm64/boot/dts/qcom/qcs6490-rb3gen2.dts
> @@ -202,6 +202,30 @@ vph_pwr: vph-pwr-regulator {
>  		regulator-min-microvolt = <3700000>;
>  		regulator-max-microvolt = <3700000>;
>  	};
> +
> +	vdd_ntn_0p9: regulator-vdd-ntn-0p9 {
> +		compatible = "regulator-fixed";
> +		regulator-name = "VDD_NTN_0P9";
> +		gpio = <&pm8350c_gpios 2 GPIO_ACTIVE_HIGH>;
> +		regulator-min-microvolt = <899400>;
> +		regulator-max-microvolt = <899400>;
> +		enable-active-high;
> +		pinctrl-0 = <&ntn_0p9_en>;
> +		pinctrl-names = "default";
> +		regulator-enable-ramp-delay = <4300>;
> +	};
> +
> +	vdd_ntn_1p8: regulator-vdd-ntn-1p8 {
> +		compatible = "regulator-fixed";
> +		regulator-name = "VDD_NTN_1P8";
> +		gpio = <&pm8350c_gpios 3 GPIO_ACTIVE_HIGH>;
> +		regulator-min-microvolt = <1800000>;
> +		regulator-max-microvolt = <1800000>;
> +		enable-active-high;
> +		pinctrl-0 = <&ntn_1p8_en>;
> +		pinctrl-names = "default";
> +		regulator-enable-ramp-delay = <10000>;
> +	};
>  };
>  
>  &apps_rsc {
> @@ -684,6 +708,75 @@ &mdss_edp_phy {
>  	status = "okay";
>  };
>  
> +&pcie1_port {
> +	pcie@0,0 {
> +		compatible = "pci1179,0623";
> +		reg = <0x10000 0x0 0x0 0x0 0x0>;
> +		#address-cells = <3>;
> +		#size-cells = <2>;
> +
> +		device_type = "pci";
> +		ranges;
> +		bus-range = <0x2 0xff>;
> +
> +		vddc-supply = <&vdd_ntn_0p9>;
> +		vdd18-supply = <&vdd_ntn_1p8>;
> +		vdd09-supply = <&vdd_ntn_0p9>;
> +		vddio1-supply = <&vdd_ntn_1p8>;
> +		vddio2-supply = <&vdd_ntn_1p8>;
> +		vddio18-supply = <&vdd_ntn_1p8>;
> +
> +		i2c-parent = <&i2c0 0x77>;
> +
> +		reset-gpios = <&pm8350c_gpios 1 GPIO_ACTIVE_LOW>;
> +
> +		pcie@1,0 {
> +			reg = <0x20800 0x0 0x0 0x0 0x0>;
> +			#address-cells = <3>;
> +			#size-cells = <2>;
> +
> +			device_type = "pci";
> +			ranges;
> +			bus-range = <0x3 0xff>;
> +		};
> +
> +		pcie@2,0 {
> +			reg = <0x21000 0x0 0x0 0x0 0x0>;
> +			#address-cells = <3>;
> +			#size-cells = <2>;
> +
> +			device_type = "pci";
> +			ranges;
> +			bus-range = <0x4 0xff>;
> +		};
> +
> +		pcie@3,0 {
> +			reg = <0x21800 0x0 0x0 0x0 0x0>;
> +			#address-cells = <3>;
> +			#size-cells = <2>;
> +			device_type = "pci";
> +			ranges;
> +			bus-range = <0x5 0xff>;
> +

You haven't added any additional properties (dfe etc...) to any of the
downstream port nodes. Does this mean that this board doesn't need any of them?

- Mani

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

Re: [PATCH v3 3/6] PCI: Add new start_link() & stop_link function ops

[Manivannan Sadhasivam]

On Tue, Nov 12, 2024 at 05:41:49PM -0600, Bjorn Helgaas wrote:
> On Tue, Nov 12, 2024 at 08:31:35PM +0530, Krishna chaitanya chundru wrote:
> > Certain devices like QPS615 which uses PCI pwrctl framework
> > needs to configure the device before PCI link is up.
> > 
> > If the controller driver already enables link training as part of
> > its probe, after the device is powered on, controller and device
> > participates in the link training and link can come up immediately
> > and maynot have time to configure the device.
> > 
> > So we need to stop the link training by using stop_link() and enable
> > them back after device is configured by using start_link().
> 
> s/maynot/may not/
> 
> I think I'm missing the point here.  My assumption is this:
> 

First controller driver probes, enables link training and scans the bus. When
the PCI bridge is found, its child DT nodes will be scanned and pwrctl devices
will be created if needed.

>   - device starts as powered off
>   - pwrctl turns on the power
>   - link trains automatically
>   - qcom driver claims device

QPS615 driver will claim this device not controller driver.

>   - qcom needs to configure things that need to happen before link
>     train
> 

QPS615 driver needs to configure the switch before link training. So at this
point, it stops the link training, configures the switch and starts it again.

Patch description could be improved.

- Mani

> but that can't be quite right because you wouldn't be able to fix it
> by changing the qcom driver because it's not in the picture until the
> link is already trained.
> 
> So maybe you can add a little more context here?
> 
> > Signed-off-by: Krishna chaitanya chundru <quic_krichai@quicinc.com>
> > ---
> >  include/linux/pci.h | 2 ++
> >  1 file changed, 2 insertions(+)
> > 
> > diff --git a/include/linux/pci.h b/include/linux/pci.h
> > index 573b4c4c2be6..fe6a9b4b22ee 100644
> > --- a/include/linux/pci.h
> > +++ b/include/linux/pci.h
> > @@ -806,6 +806,8 @@ struct pci_ops {
> >  	void __iomem *(*map_bus)(struct pci_bus *bus, unsigned int devfn, int where);
> >  	int (*read)(struct pci_bus *bus, unsigned int devfn, int where, int size, u32 *val);
> >  	int (*write)(struct pci_bus *bus, unsigned int devfn, int where, int size, u32 val);
> > +	int (*start_link)(struct pci_bus *bus);
> > +	void (*stop_link)(struct pci_bus *bus);
> >  };
> >  
> >  /*
> > 
> > -- 
> > 2.34.1
> > 

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

Re: [PATCH v3 5/6] PCI: qcom: Add support for host_stop_link() & host_start_link()

[Manivannan Sadhasivam]

On Tue, Nov 12, 2024 at 08:31:37PM +0530, Krishna chaitanya chundru wrote:
> For the switches like QPS615 which needs to configure it before
> the PCIe link is established.
> 
> If the link is up, the boatloader might powered and configured the
> endpoint/switch already. In that case don't touch PCIe link else
> assert the PERST# and disable LTSSM bit so that PCIe controller
> will not participate in the link training as part of host_stop_link().
> 
> De-assert the PERST# and enable LTSSM bit back in host_start_link().
> 
> Introduce ltssm_disable function op to stop the link training.
> 
> Signed-off-by: Krishna chaitanya chundru <quic_krichai@quicinc.com>
> ---
>  drivers/pci/controller/dwc/pcie-qcom.c | 39 ++++++++++++++++++++++++++++++++++
>  1 file changed, 39 insertions(+)
> 
> diff --git a/drivers/pci/controller/dwc/pcie-qcom.c b/drivers/pci/controller/dwc/pcie-qcom.c
> index ef44a82be058..048aea94e319 100644
> --- a/drivers/pci/controller/dwc/pcie-qcom.c
> +++ b/drivers/pci/controller/dwc/pcie-qcom.c
> @@ -246,6 +246,7 @@ struct qcom_pcie_ops {
>  	void (*host_post_init)(struct qcom_pcie *pcie);
>  	void (*deinit)(struct qcom_pcie *pcie);
>  	void (*ltssm_enable)(struct qcom_pcie *pcie);
> +	void (*ltssm_disable)(struct qcom_pcie *pcie);
>  	int (*config_sid)(struct qcom_pcie *pcie);
>  };
>  
> @@ -617,6 +618,41 @@ static int qcom_pcie_post_init_1_0_0(struct qcom_pcie *pcie)
>  	return 0;
>  }
>  
> +static int qcom_pcie_host_start_link(struct dw_pcie *pci)
> +{
> +	struct qcom_pcie *pcie = to_qcom_pcie(pci);
> +
> +	if (!dw_pcie_link_up(pcie->pci))  {

I don't think the controller driver should worry about the bootloader
initialization. You should export dw_pcie_link_up() as a callback and call
start/stop link if only required (link not up) from the pwrctl driver.

- Mani

> +		qcom_ep_reset_deassert(pcie);
> +
> +		if (pcie->cfg->ops->ltssm_enable)
> +			pcie->cfg->ops->ltssm_enable(pcie);
> +	}
> +
> +	return 0;
> +}
> +
> +static void qcom_pcie_host_stop_link(struct dw_pcie *pci)
> +{
> +	struct qcom_pcie *pcie = to_qcom_pcie(pci);
> +
> +	if (!dw_pcie_link_up(pcie->pci))  {
> +		qcom_ep_reset_assert(pcie);
> +
> +		if (pcie->cfg->ops->ltssm_disable)
> +			pcie->cfg->ops->ltssm_disable(pcie);
> +	}
> +}
> +
> +static void qcom_pcie_2_3_2_ltssm_disable(struct qcom_pcie *pcie)
> +{
> +	u32 val;
> +
> +	val = readl(pcie->parf + PARF_LTSSM);
> +	val &= ~LTSSM_EN;
> +	writel(val, pcie->parf + PARF_LTSSM);
> +}
> +
>  static void qcom_pcie_2_3_2_ltssm_enable(struct qcom_pcie *pcie)
>  {
>  	u32 val;
> @@ -1361,6 +1397,7 @@ static const struct qcom_pcie_ops ops_1_9_0 = {
>  	.host_post_init = qcom_pcie_host_post_init_2_7_0,
>  	.deinit = qcom_pcie_deinit_2_7_0,
>  	.ltssm_enable = qcom_pcie_2_3_2_ltssm_enable,
> +	.ltssm_disable = qcom_pcie_2_3_2_ltssm_disable,
>  	.config_sid = qcom_pcie_config_sid_1_9_0,
>  };
>  
> @@ -1418,6 +1455,8 @@ static const struct qcom_pcie_cfg cfg_sc8280xp = {
>  static const struct dw_pcie_ops dw_pcie_ops = {
>  	.link_up = qcom_pcie_link_up,
>  	.start_link = qcom_pcie_start_link,
> +	.host_start_link = qcom_pcie_host_start_link,
> +	.host_stop_link = qcom_pcie_host_stop_link,
>  };
>  
>  static int qcom_pcie_icc_init(struct qcom_pcie *pcie)
> 
> -- 
> 2.34.1
> 

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

Re: [PATCH v3 6/6] PCI: pwrctl: Add power control driver for qps615

[Manivannan Sadhasivam]

On Tue, Nov 12, 2024 at 08:31:38PM +0530, Krishna chaitanya chundru wrote:
> QPS615 is the PCIe switch which has one upstream and three downstream
> ports. To one of the downstream ports ethernet MAC is connected as endpoint
> device. Other two downstream ports are supposed to connect to external
> device. One Host can connect to QPS615 by upstream port. QPS615 switch
> needs to be configured after powering on and before PCIe link was up.
> 
> The PCIe controller driver already enables link training at the host side
> even before qps615 driver probe happens, due to this when driver enables
> power to the switch it participates in the link training and PCIe link
> may come up before configuring the switch through i2c. To prevent the

State the reason why the i2c config needs to be done before link up.

> host from participating in link training, disable link training on the
> host side to ensure the link does not come up before the switch is
> configured via I2C.
> 
> Based up on dt property and type of the port, qps615 is configured
> through i2c.
> 
> Signed-off-by: Krishna chaitanya chundru <quic_krichai@quicinc.com>
> ---
>  drivers/pci/pwrctl/Kconfig             |   8 +
>  drivers/pci/pwrctl/Makefile            |   1 +
>  drivers/pci/pwrctl/pci-pwrctl-qps615.c | 630 +++++++++++++++++++++++++++++++++
>  3 files changed, 639 insertions(+)
> 
> diff --git a/drivers/pci/pwrctl/Kconfig b/drivers/pci/pwrctl/Kconfig
> index 54589bb2403b..fe945d176b8b 100644
> --- a/drivers/pci/pwrctl/Kconfig
> +++ b/drivers/pci/pwrctl/Kconfig
> @@ -10,3 +10,11 @@ config PCI_PWRCTL_PWRSEQ
>  	tristate
>  	select POWER_SEQUENCING
>  	select PCI_PWRCTL
> +
> +config PCI_PWRCTL_QPS615
> +	tristate "PCI Power Control driver for QPS615"

QPS615 PCIe switch

> +	select PCI_PWRCTL
> +	help
> +	  Say Y here to enable the pwrctl driver for Qualcomm
> +	  QPS615 PCIe switch which enables and configures it
> +	  through i2c.
> diff --git a/drivers/pci/pwrctl/Makefile b/drivers/pci/pwrctl/Makefile
> index d308aae4800c..ac563a70c023 100644
> --- a/drivers/pci/pwrctl/Makefile
> +++ b/drivers/pci/pwrctl/Makefile
> @@ -4,3 +4,4 @@ obj-$(CONFIG_PCI_PWRCTL)		+= pci-pwrctl-core.o
>  pci-pwrctl-core-y			:= core.o
>  
>  obj-$(CONFIG_PCI_PWRCTL_PWRSEQ)		+= pci-pwrctl-pwrseq.o
> +obj-$(CONFIG_PCI_PWRCTL_QPS615)		+= pci-pwrctl-qps615.o
> diff --git a/drivers/pci/pwrctl/pci-pwrctl-qps615.c b/drivers/pci/pwrctl/pci-pwrctl-qps615.c
> new file mode 100644
> index 000000000000..c338e35c9083
> --- /dev/null
> +++ b/drivers/pci/pwrctl/pci-pwrctl-qps615.c
> @@ -0,0 +1,630 @@
> +// SPDX-License-Identifier: GPL-2.0-only
> +/*
> + * Copyright (c) 2024 Qualcomm Innovation Center, Inc. All rights reserved.
> + */
> +
> +#include <linux/delay.h>
> +#include <linux/device.h>
> +#include <linux/i2c.h>
> +#include <linux/mod_devicetable.h>
> +#include <linux/module.h>
> +#include <linux/of.h>
> +#include <linux/of_platform.h>
> +#include <linux/pci.h>
> +#include <linux/pci-pwrctl.h>
> +#include <linux/platform_device.h>
> +#include <linux/regulator/consumer.h>
> +#include <linux/string.h>
> +#include <linux/types.h>
> +#include <linux/unaligned.h>
> +
> +#include "../pci.h"
> +
> +#define QPS615_GPIO_CONFIG		0x801208
> +#define QPS615_RESET_GPIO		0x801210
> +
> +#define QPS615_BUS_CONTROL		0x801014
> +
> +#define QPS615_PORT_L0S_DELAY		0x82496c
> +#define QPS615_PORT_L1_DELAY		0x824970
> +
> +#define QPS615_EMBEDDED_ETH_DELAY	0x8200d8
> +#define QPS615_ETH_L1_DELAY_MASK	GENMASK(27, 18)
> +#define QPS615_ETH_L1_DELAY_VALUE(x)	FIELD_PREP(QPS615_ETH_L1_DELAY_MASK, x)
> +#define QPS615_ETH_L0S_DELAY_MASK	GENMASK(17, 13)
> +#define QPS615_ETH_L0S_DELAY_VALUE(x)	FIELD_PREP(QPS615_ETH_L0S_DELAY_MASK, x)
> +
> +#define QPS615_NFTS_2_5_GT		0x824978
> +#define QPS615_NFTS_5_GT		0x82497c
> +
> +#define QPS615_PORT_LANE_ACCESS_ENABLE	0x828000
> +
> +#define QPS615_PHY_RATE_CHANGE_OVERRIDE	0x828040
> +#define QPS615_PHY_RATE_CHANGE		0x828050
> +
> +#define QPS615_TX_MARGIN		0x828234
> +
> +#define QPS615_DFE_ENABLE		0x828a04
> +#define QPS615_DFE_EQ0_MODE		0x828a08
> +#define QPS615_DFE_EQ1_MODE		0x828a0c
> +#define QPS615_DFE_EQ2_MODE		0x828a14
> +#define QPS615_DFE_PD_MASK		0x828254
> +
> +#define QPS615_PORT_SELECT		0x82c02c
> +#define QPS615_PORT_ACCESS_ENABLE	0x82c030
> +
> +#define QPS615_POWER_CONTROL		0x82b09c
> +#define QPS615_POWER_CONTROL_OVREN	0x82b2c8
> +
> +#define QPS615_FREQ_125_MHZ		125000000
> +#define QPS615_FREQ_250_MHZ		250000000
> +
> +#define QPS615_GPIO_MASK		0xfffffff3
> +
> +struct qps615_pwrctl_reg_setting {
> +	unsigned int offset;
> +	unsigned int val;
> +};
> +
> +enum qps615_pwrctl_ports {
> +	QPS615_USP,
> +	QPS615_DSP1,
> +	QPS615_DSP2,
> +	QPS615_DSP3,
> +	QPS615_ETHERNET,
> +	QPS615_MAX
> +};
> +
> +struct qps615_pwrctl_cfg {
> +	u32 l0s_delay;
> +	u32 l1_delay;
> +	u32 tx_amp;
> +	u32 nfts;
> +	bool disable_dfe;
> +	bool disable_port;
> +	bool axi_freq_125;
> +};
> +
> +#define QPS615_PWRCTL_MAX_SUPPLY	6
> +
> +struct qps615_pwrctl_ctx {
> +	struct regulator_bulk_data supplies[QPS615_PWRCTL_MAX_SUPPLY];
> +	struct qps615_pwrctl_cfg cfg[QPS615_MAX];
> +	struct gpio_desc *reset_gpio;
> +	struct i2c_adapter *adapter;
> +	struct i2c_client *client;
> +	struct pci_pwrctl pwrctl;
> +};
> +
> +/*
> + * downstream port power off sequence, hardcoding the address
> + * as we don't know register names for these register offsets.
> + */
> +static const struct qps615_pwrctl_reg_setting common_pwroff_seq[] = {
> +	{0x82900c, 0x1},
> +	{0x829010, 0x1},
> +	{0x829018, 0x0},
> +	{0x829020, 0x1},
> +	{0x82902c, 0x1},
> +	{0x829030, 0x1},
> +	{0x82903c, 0x1},
> +	{0x829058, 0x0},
> +	{0x82905c, 0x1},
> +	{0x829060, 0x1},
> +	{0x8290cc, 0x1},
> +	{0x8290d0, 0x1},
> +	{0x8290d8, 0x1},
> +	{0x8290e0, 0x1},
> +	{0x8290e8, 0x1},
> +	{0x8290ec, 0x1},
> +	{0x8290f4, 0x1},
> +	{0x82910c, 0x1},
> +	{0x829110, 0x1},
> +	{0x829114, 0x1},
> +};
> +
> +static const struct qps615_pwrctl_reg_setting dsp1_pwroff_seq[] = {
> +	{QPS615_PORT_ACCESS_ENABLE, 0x2},
> +	{QPS615_PORT_LANE_ACCESS_ENABLE, 0x3},
> +	{QPS615_POWER_CONTROL, 0x014f4804},
> +	{QPS615_POWER_CONTROL_OVREN, 0x1},
> +	{QPS615_PORT_ACCESS_ENABLE, 0x4},
> +};
> +
> +static const struct qps615_pwrctl_reg_setting dsp2_pwroff_seq[] = {
> +	{QPS615_PORT_ACCESS_ENABLE, 0x8},
> +	{QPS615_PORT_LANE_ACCESS_ENABLE, 0x1},
> +	{QPS615_POWER_CONTROL, 0x014f4804},
> +	{QPS615_POWER_CONTROL_OVREN, 0x1},
> +	{QPS615_PORT_ACCESS_ENABLE, 0x8},
> +};
> +
> +/*
> + * Since all transfers are initiated by the probe, no locks are necessary,
> + * ensuring there are no concurrent calls.

'ensuring there are no concurrent calls' is not quite right here.

> + */
> +static int qps615_pwrctl_i2c_write(struct i2c_client *client,
> +				   u32 reg_addr, u32 reg_val)
> +{
> +	struct i2c_msg msg;
> +	u8 msg_buf[7];
> +	int ret;
> +
> +	msg.addr = client->addr;
> +	msg.len = 7;
> +	msg.flags = 0;
> +
> +	/* Big Endian for reg addr */
> +	put_unaligned_be24(reg_addr, &msg_buf[0]);
> +
> +	/* Little Endian for reg val */
> +	put_unaligned_le32(reg_val, &msg_buf[3]);
> +
> +	msg.buf = msg_buf;
> +	ret = i2c_transfer(client->adapter, &msg, 1);
> +	return ret == 1 ? 0 : ret;
> +}
> +
> +static int qps615_pwrctl_i2c_read(struct i2c_client *client,
> +				  u32 reg_addr, u32 *reg_val)
> +{
> +	struct i2c_msg msg[2];
> +	u8 wr_data[3];
> +	u32 rd_data;
> +	int ret;
> +
> +	msg[0].addr = client->addr;
> +	msg[0].len = 3;
> +	msg[0].flags = 0;
> +
> +	/* Big Endian for reg addr */
> +	put_unaligned_be24(reg_addr, &wr_data[0]);
> +
> +	msg[0].buf = wr_data;
> +
> +	msg[1].addr = client->addr;
> +	msg[1].len = 4;
> +	msg[1].flags = I2C_M_RD;
> +
> +	msg[1].buf = (u8 *)&rd_data;
> +
> +	ret = i2c_transfer(client->adapter, &msg[0], 2);
> +	if (ret == 2) {
> +		*reg_val = get_unaligned_le32(&rd_data);
> +		return 0;
> +	}
> +
> +	/* If only one message successfully completed, return -ENODEV */

EIO?

> +	return ret == 1 ? -ENODEV : ret;
> +}
> +

[...]

> +static int qps615_pwrctl_set_nfts(struct qps615_pwrctl_ctx *ctx,
> +				  enum qps615_pwrctl_ports port, u32 nfts)
> +{
> +	int ret;
> +	struct qps615_pwrctl_reg_setting nfts_seq[] = {
> +		{QPS615_NFTS_2_5_GT, nfts},
> +		{QPS615_NFTS_5_GT, nfts},
> +	};

Reverse Xmas order.

> +
> +	ret =  qps615_pwrctl_i2c_write(ctx->client, QPS615_PORT_SELECT, BIT(port));
> +	if (ret)
> +		return ret;
> +
> +	return qps615_pwrctl_i2c_bulk_write(ctx->client, nfts_seq, ARRAY_SIZE(nfts_seq));
> +}
> +
> +static int qps615_pwrctl_assert_deassert_reset(struct qps615_pwrctl_ctx *ctx, bool deassert)
> +{
> +	int ret, val;
> +
> +	ret = qps615_pwrctl_i2c_write(ctx->client, QPS615_GPIO_CONFIG, QPS615_GPIO_MASK);
> +	if (ret)
> +		return ret;
> +
> +	val = deassert ? 0xc : 0;
> +
> +	return qps615_pwrctl_i2c_write(ctx->client, QPS615_RESET_GPIO, val);
> +}
> +
> +static int qps615_pwrctl_parse_device_dt(struct qps615_pwrctl_ctx *ctx, struct device_node *node,
> +					 enum qps615_pwrctl_ports port)
> +{
> +	struct qps615_pwrctl_cfg *cfg;
> +	u32 axi_freq = 0;
> +	int ret;
> +
> +	cfg = &ctx->cfg[port];
> +

It'd be better to add a comment here about disabling ports.

> +	if (!of_device_is_available(node)) {
> +		cfg->disable_port = true;
> +		return 0;
> +	};
> +
> +	ret = of_property_read_u32(node, "qcom,axi-clk-freq-hz", &axi_freq);
> +	if (ret && ret != -EINVAL)
> +		return ret;
> +	else if (axi_freq && (axi_freq != QPS615_FREQ_125_MHZ || axi_freq != QPS615_FREQ_250_MHZ))
> +		return -EINVAL;

Add a dev_err() to print the reason.

> +	else if (axi_freq == QPS615_FREQ_125_MHZ)
> +		cfg->axi_freq_125 = true;
> +
> +	ret = of_property_read_u32(node, "qcom,l0s-entry-delay-ns", &cfg->l0s_delay);
> +	if (ret && ret != -EINVAL)
> +		return ret;
> +
> +	ret = of_property_read_u32(node, "qcom,l1-entry-delay-ns", &cfg->l1_delay);
> +	if (ret && ret != -EINVAL)
> +		return ret;
> +
> +	ret = of_property_read_u32(node, "qcom,tx-amplitude-millivolt", &cfg->tx_amp);
> +	if (ret && ret != -EINVAL)
> +		return ret;
> +
> +	ret = of_property_read_u32(node, "qcom,nfts", &cfg->nfts);
> +	if (ret && ret != -EINVAL)
> +		return ret;
> +
> +	cfg->disable_dfe = of_property_read_bool(node, "qcom,no-dfe-support");
> +
> +	return 0;
> +}
> +
> +static void qps615_pwrctl_power_off(struct qps615_pwrctl_ctx *ctx)
> +{
> +	gpiod_set_value(ctx->reset_gpio, 1);
> +
> +	regulator_bulk_disable(ARRAY_SIZE(ctx->supplies), ctx->supplies);
> +}
> +
> +static int qps615_pwrctl_power_on(struct qps615_pwrctl_ctx *ctx)
> +{
> +	struct qps615_pwrctl_cfg *cfg;
> +	int ret, i;
> +
> +	ret = regulator_bulk_enable(ARRAY_SIZE(ctx->supplies), ctx->supplies);
> +	if (ret < 0)
> +		return dev_err_probe(ctx->pwrctl.dev, ret, "cannot enable regulators\n");
> +
> +	gpiod_set_value(ctx->reset_gpio, 0);
> +
> +	 /* wait for the internal osc frequency to stablise */
> +	usleep_range(10000, 10500);
> +
> +	ret = qps615_pwrctl_assert_deassert_reset(ctx, false);
> +	if (ret)
> +		goto out;

goto power_off;

> +
> +	if (ctx->cfg[QPS615_USP].axi_freq_125) {
> +		ret = qps615_pwrctl_i2c_write(ctx->client, QPS615_BUS_CONTROL, BIT(16));
> +		if (ret)
> +			dev_err(ctx->pwrctl.dev, "Setting AXI clk freq failed %d\n", ret);
> +	}
> +
> +	for (i = 0; i < QPS615_MAX; i++) {
> +		cfg = &ctx->cfg[i];
> +		if (cfg->disable_port) {
> +			ret = qps615_pwrctl_disable_port(ctx, i);
> +			if (ret) {
> +				dev_err(ctx->pwrctl.dev, "Disabling port failed\n");
> +				goto out;
> +			}
> +		}
> +
> +		if (cfg->l0s_delay) {
> +			ret = qps615_pwrctl_set_l0s_l1_entry_delay(ctx, i, false, cfg->l0s_delay);
> +			if (ret) {
> +				dev_err(ctx->pwrctl.dev, "Setting L0s entry delay failed\n");
> +				goto out;
> +			}
> +		}
> +
> +		if (cfg->l1_delay) {
> +			ret = qps615_pwrctl_set_l0s_l1_entry_delay(ctx, i, true, cfg->l1_delay);
> +			if (ret) {
> +				dev_err(ctx->pwrctl.dev, "Setting L1 entry delay failed\n");
> +				goto out;
> +			}
> +		}
> +
> +		if (cfg->tx_amp) {
> +			ret = qps615_pwrctl_set_tx_amplitude(ctx, i, cfg->tx_amp);
> +			if (ret) {
> +				dev_err(ctx->pwrctl.dev, "Setting Tx amplitube failed\n");
> +				goto out;
> +			}
> +		}
> +
> +		if (cfg->nfts) {
> +			ret = qps615_pwrctl_set_nfts(ctx, i, cfg->nfts);
> +			if (ret) {
> +				dev_err(ctx->pwrctl.dev, "Setting nfts failed\n");
> +				goto out;
> +			}
> +		}
> +
> +		if (cfg->disable_dfe) {
> +			ret = qps615_pwrctl_disable_dfe(ctx, i);
> +			if (ret) {
> +				dev_err(ctx->pwrctl.dev, "Disabling DFE failed\n");
> +				goto out;
> +			}
> +		}
> +	}
> +
> +	ret = qps615_pwrctl_assert_deassert_reset(ctx, true);
> +	if (!ret)
> +		return 0;
> +
> +out:
> +	qps615_pwrctl_power_off(ctx);
> +	return ret;
> +}
> +
> +static int qps615_pwrctl_probe(struct platform_device *pdev)
> +{
> +	struct device *dev = &pdev->dev;
> +	struct pci_host_bridge *bridge;
> +	enum qps615_pwrctl_ports port;
> +	struct qps615_pwrctl_ctx *ctx;
> +	int ret, addr;
> +
> +	bridge = pci_find_host_bridge(to_pci_dev(dev->parent)->bus);

You can initialize it at the declaration itself.

> +
> +	ctx = devm_kzalloc(dev, sizeof(*ctx), GFP_KERNEL);
> +	if (!ctx)
> +		return -ENOMEM;
> +
> +	ret = of_property_read_u32_index(pdev->dev.of_node, "i2c-parent", 1, &addr);
> +	if (ret)
> +		return dev_err_probe(dev, ret, "Failed to read i2c-parent property\n");
> +
> +	ctx->adapter = of_find_i2c_adapter_by_node(of_parse_phandle(dev->of_node, "i2c-parent", 0));
> +	of_node_put(dev->of_node);
> +	if (!ctx->adapter)
> +		return dev_err_probe(dev, -EPROBE_DEFER, "Failed to find I2C adapter\n");
> +
> +	ctx->client = i2c_new_dummy_device(ctx->adapter, addr);
> +	if (IS_ERR(ctx->client)) {
> +		dev_err(dev, "Failed to create I2C client\n");
> +		i2c_put_adapter(ctx->adapter);
> +		return PTR_ERR(ctx->client);
> +	}
> +
> +	ctx->supplies[0].supply = "vddc";
> +	ctx->supplies[1].supply = "vdd18";
> +	ctx->supplies[2].supply = "vdd09";
> +	ctx->supplies[3].supply = "vddio1";
> +	ctx->supplies[4].supply = "vddio2";
> +	ctx->supplies[5].supply = "vddio18";
> +	ret = devm_regulator_bulk_get(dev, ARRAY_SIZE(ctx->supplies), ctx->supplies);
> +	if (ret) {
> +		dev_err_probe(dev, ret,
> +			      "failed to get supply regulator\n");
> +		goto remove_i2c;
> +	}
> +
> +	ctx->reset_gpio = devm_gpiod_get(dev, "reset", GPIOD_ASIS);

Do not request GPIO with ASIS, always specify the polarity.

- Mani

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

Re: [PATCH v3 1/6] dt-bindings: PCI: Add binding for qps615

[Rob Herring]

On Tue, Nov 12, 2024 at 08:31:33PM +0530, Krishna chaitanya chundru wrote:
> Add binding describing the Qualcomm PCIe switch, QPS615,
> which provides Ethernet MAC integrated to the 3rd downstream port
> and two downstream PCIe ports.
> 
> Signed-off-by: Krishna chaitanya chundru <quic_krichai@quicinc.com>
> ---
>  .../devicetree/bindings/pci/qcom,qps615.yaml       | 205 +++++++++++++++++++++
>  1 file changed, 205 insertions(+)
> 
> diff --git a/Documentation/devicetree/bindings/pci/qcom,qps615.yaml b/Documentation/devicetree/bindings/pci/qcom,qps615.yaml
> new file mode 100644
> index 000000000000..e6a63a0bb0f3
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/pci/qcom,qps615.yaml
> @@ -0,0 +1,205 @@
> +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
> +%YAML 1.2
> +---
> +$id: http://devicetree.org/schemas/pci/qcom,qps615.yaml#
> +$schema: http://devicetree.org/meta-schemas/core.yaml#
> +
> +title: Qualcomm QPS615 PCIe switch
> +
> +maintainers:
> +  - Krishna chaitanya chundru <quic_krichai@quicinc.com>
> +
> +description: |
> +  Qualcomm QPS615 PCIe switch has one upstream and three downstream
> +  ports. The 3rd downstream port has integrated endpoint device of
> +  Ethernet MAC. Other two downstream ports are supposed to connect
> +  to external device.
> +
> +  The QPS615 PCIe switch can be configured through I2C interface before
> +  PCIe link is established to change FTS, ASPM related entry delays,
> +  tx amplitude etc for better power efficiency and functionality.
> +
> +properties:
> +  compatible:
> +    enum:
> +      - pci1179,0623
> +
> +  reg:
> +    maxItems: 1
> +
> +  i2c-parent:
> +    $ref: /schemas/types.yaml#/definitions/phandle-array
> +    description: |

Don't need '|' if no formatting to preserve.

> +      A phandle to the parent I2C node and the slave address of the device
> +      used to do configure qps615 to change FTS, tx amplitude etc.
> +    items:
> +      - description: Phandle to the I2C controller node
> +      - description: I2C slave address
> +
> +  vdd18-supply: true
> +
> +  vdd09-supply: true
> +
> +  vddc-supply: true
> +
> +  vddio1-supply: true
> +
> +  vddio2-supply: true
> +
> +  vddio18-supply: true
> +
> +  reset-gpios:
> +    maxItems: 1
> +    description:
> +      GPIO controlling the RESX# pin.

Is the PERST# or something else?

> +
> +  qps615,axi-clk-freq-hz:

qps615 is not a vendor prefix.

> +    description:
> +      AXI clock rate which is internal bus of the switch
> +      The switch only runs in two frequencies i.e 250MHz and 125MHz.
> +    enum: [125000000, 250000000]
> +
> +allOf:
> +  - $ref: "#/$defs/qps615-node"
> +
> +patternProperties:
> +  "@1?[0-9a-f](,[0-7])?$":

You have 3 ports. So isn't this fixed and limited to 0-2?

> +    description: child nodes describing the internal downstream ports
> +      the qps615 switch.

Please be consistent with starting after the ':' or on the next line.

And start with capital C.


> +    type: object
> +    $ref: "#/$defs/qps615-node"
> +    unevaluatedProperties: false
> +
> +$defs:
> +  qps615-node:
> +    type: object
> +
> +    properties:
> +      qcom,l0s-entry-delay-ns:
> +        description: Aspm l0s entry delay.
> +
> +      qcom,l1-entry-delay-ns:
> +        description: Aspm l1 entry delay.

These should probably be common being standard PCIe things. Though, why 
are they needed? I'm sure the timing is defined by the PCIe spec, so 
they are not compliant?

> +
> +      qcom,tx-amplitude-millivolt:
> +        $ref: /schemas/types.yaml#/definitions/uint32
> +        description: Change Tx Margin setting for low power consumption.
> +
> +      qcom,no-dfe-support:
> +        type: boolean
> +        description: Disable DFE (Decision Feedback Equalizer), which mitigates
> +          intersymbol interference and some reflections caused by impedance mismatches.
> +
> +      qcom,nfts:
> +        $ref: /schemas/types.yaml#/definitions/uint32
> +        description:
> +          Number of Fast Training Sequence (FTS) used during L0s to L0 exit
> +          for bit and Symbol lock.

Also something common.

The problem I have with all these properties is you are using them on 
both the upstream and downstream sides of the PCIe links. They belong in 
either the device's node (downstream) or the bus's node (upstream). 

> +
> +    allOf:
> +      - $ref: /schemas/pci/pci-bus.yaml#

pci-pci-bridge.yaml is more specific and closer to what this device is.

> +
> +unevaluatedProperties: false
> +
> +required:
> +  - vdd18-supply
> +  - vdd09-supply
> +  - vddc-supply
> +  - vddio1-supply
> +  - vddio2-supply
> +  - vddio18-supply
> +  - i2c-parent
> +  - reset-gpios
> +
> +examples:
> +  - |
> +
> +    #include <dt-bindings/gpio/gpio.h>
> +
> +    pcie {
> +        #address-cells = <3>;
> +        #size-cells = <2>;
> +
> +        pcie@0 {
> +            device_type = "pci";
> +            reg = <0x0 0x0 0x0 0x0 0x0>;
> +
> +            #address-cells = <3>;
> +            #size-cells = <2>;
> +            ranges;
> +            bus-range = <0x01 0xff>;
> +
> +            pcie@0,0 {
> +                compatible = "pci1179,0623";
> +                reg = <0x10000 0x0 0x0 0x0 0x0>;
> +                device_type = "pci";
> +                #address-cells = <3>;
> +                #size-cells = <2>;
> +                ranges;
> +                bus-range = <0x02 0xff>;
> +
> +                i2c-parent = <&qup_i2c 0x77>;
> +
> +                vdd18-supply = <&vdd>;
> +                vdd09-supply = <&vdd>;
> +                vddc-supply = <&vdd>;
> +                vddio1-supply = <&vdd>;
> +                vddio2-supply = <&vdd>;
> +                vddio18-supply = <&vdd>;
> +
> +                reset-gpios = <&gpio 1 GPIO_ACTIVE_LOW>;
> +
> +                pcie@1,0 {
> +                    reg = <0x20800 0x0 0x0 0x0 0x0>;
> +                    #address-cells = <3>;
> +                    #size-cells = <2>;
> +                    device_type = "pci";
> +                    ranges;
> +                    bus-range = <0x03 0xff>;
> +
> +                    qcom,no-dfe-support;
> +                };
> +
> +                pcie@2,0 {
> +                    reg = <0x21000 0x0 0x0 0x0 0x0>;
> +                    #address-cells = <3>;
> +                    #size-cells = <2>;
> +                    device_type = "pci";
> +                    ranges;
> +                    bus-range = <0x04 0xff>;
> +
> +                    qcom,nfts = <10>;
> +                };
> +
> +                pcie@3,0 {
> +                    reg = <0x21800 0x0 0x0 0x0 0x0>;
> +                    #address-cells = <3>;
> +                    #size-cells = <2>;
> +                    device_type = "pci";
> +                    ranges;
> +                    bus-range = <0x05 0xff>;
> +
> +                    qcom,tx-amplitude-millivolt = <10>;
> +                    pcie@0,0 {
> +                        reg = <0x50000 0x0 0x0 0x0 0x0>;
> +                        #address-cells = <3>;
> +                        #size-cells = <2>;
> +                        device_type = "pci";

There's a 2nd PCI-PCI bridge?

> +                        ranges;
> +
> +                        qcom,l1-entry-delay-ns = <10>;
> +                    };
> +
> +                    pcie@0,1 {
> +                        reg = <0x50100 0x0 0x0 0x0 0x0>;
> +                        #address-cells = <3>;
> +                        #size-cells = <2>;
> +                        device_type = "pci";
> +                        ranges;
> +
> +                        qcom,l0s-entry-delay-ns = <10>;
> +                    };
> +                };
> +            };
> +        };
> +    };
> 
> -- 
> 2.34.1
> 

Re: [PATCH v3 1/6] dt-bindings: PCI: Add binding for qps615

[Krzysztof Kozlowski]

On Tue, Nov 12, 2024 at 08:31:33PM +0530, Krishna chaitanya chundru wrote:
> Add binding describing the Qualcomm PCIe switch, QPS615,
> which provides Ethernet MAC integrated to the 3rd downstream port
> and two downstream PCIe ports.
> 
> Signed-off-by: Krishna chaitanya chundru <quic_krichai@quicinc.com>
> ---
>  .../devicetree/bindings/pci/qcom,qps615.yaml       | 205 +++++++++++++++++++++
>  1 file changed, 205 insertions(+)
> 
> diff --git a/Documentation/devicetree/bindings/pci/qcom,qps615.yaml b/Documentation/devicetree/bindings/pci/qcom,qps615.yaml
> new file mode 100644
> index 000000000000..e6a63a0bb0f3
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/pci/qcom,qps615.yaml

Isn't "qcom,qps615" a SoC name? This is supposed to be matching
compatible, in your case probably qcom,qps615-whatever-this-is?

...

> +  qps615,axi-clk-freq-hz:

That's a downstream code you send us.

Anyway, why assigned clock rates do not work for you? You are
re-implementing legacy property now under different name :/


> +    description:
> +      AXI clock rate which is internal bus of the switch
> +      The switch only runs in two frequencies i.e 250MHz and 125MHz.
> +    enum: [125000000, 250000000]
> +
> +allOf:
> +  - $ref: "#/$defs/qps615-node"
> +
> +patternProperties:
> +  "@1?[0-9a-f](,[0-7])?$":
> +    description: child nodes describing the internal downstream ports
> +      the qps615 switch.
> +    type: object
> +    $ref: "#/$defs/qps615-node"
> +    unevaluatedProperties: false
> +
> +$defs:
> +  qps615-node:
> +    type: object
> +
> +    properties:
> +      qcom,l0s-entry-delay-ns:
> +        description: Aspm l0s entry delay.
> +
> +      qcom,l1-entry-delay-ns:
> +        description: Aspm l1 entry delay.
> +
> +      qcom,tx-amplitude-millivolt:

-microvolt does not work for you?

> +        $ref: /schemas/types.yaml#/definitions/uint32
> +        description: Change Tx Margin setting for low power consumption.
> +
> +      qcom,no-dfe-support:
> +        type: boolean
> +        description: Disable DFE (Decision Feedback Equalizer), which mitigates
> +          intersymbol interference and some reflections caused by impedance mismatches.
> +
> +      qcom,nfts:
> +        $ref: /schemas/types.yaml#/definitions/uint32
> +        description:
> +          Number of Fast Training Sequence (FTS) used during L0s to L0 exit
> +          for bit and Symbol lock.

Use some of these properties in the example. I saw only one.

> +
> +    allOf:
> +      - $ref: /schemas/pci/pci-bus.yaml#
> +
> +unevaluatedProperties: false
> +
> +required:
> +  - vdd18-supply
> +  - vdd09-supply
> +  - vddc-supply
> +  - vddio1-supply
> +  - vddio2-supply
> +  - vddio18-supply
> +  - i2c-parent
> +  - reset-gpios
> +
> +examples:
> +  - |
> +

Drop blank line

> +    #include <dt-bindings/gpio/gpio.h>
> +
> +    pcie {
> +        #address-cells = <3>;
> +        #size-cells = <2>;
> +
> +        pcie@0 {
> +            device_type = "pci";
> +            reg = <0x0 0x0 0x0 0x0 0x0>;

Best regards,
Krzysztof

Re: [PATCH v3 2/6] arm64: dts: qcom: qcs6490-rb3gen2: Add node for qps615

[Krzysztof Kozlowski]

On Tue, Nov 12, 2024 at 08:31:34PM +0530, Krishna chaitanya chundru wrote:
> Add QPS615 PCIe switch node which has 3 downstream ports and in one
> downstream port two embedded ethernet devices are present.
> 
> Power to the QPS615 is supplied through two LDO regulators, controlled
> by two GPIOs, these are added as fixed regulators. And the QPS615 is
> configured through i2c.
> 
> Signed-off-by: Krishna chaitanya chundru <quic_krichai@quicinc.com>
> ---
>  arch/arm64/boot/dts/qcom/qcs6490-rb3gen2.dts | 115 +++++++++++++++++++++++++++
>  arch/arm64/boot/dts/qcom/sc7280.dtsi         |   2 +-
>  2 files changed, 116 insertions(+), 1 deletion(-)
> 
> diff --git a/arch/arm64/boot/dts/qcom/qcs6490-rb3gen2.dts b/arch/arm64/boot/dts/qcom/qcs6490-rb3gen2.dts
> index 0d45662b8028..0e890841b600 100644
> --- a/arch/arm64/boot/dts/qcom/qcs6490-rb3gen2.dts
> +++ b/arch/arm64/boot/dts/qcom/qcs6490-rb3gen2.dts
> @@ -202,6 +202,30 @@ vph_pwr: vph-pwr-regulator {
>  		regulator-min-microvolt = <3700000>;
>  		regulator-max-microvolt = <3700000>;
>  	};
> +
> +	vdd_ntn_0p9: regulator-vdd-ntn-0p9 {
> +		compatible = "regulator-fixed";
> +		regulator-name = "VDD_NTN_0P9";
> +		gpio = <&pm8350c_gpios 2 GPIO_ACTIVE_HIGH>;
> +		regulator-min-microvolt = <899400>;
> +		regulator-max-microvolt = <899400>;
> +		enable-active-high;
> +		pinctrl-0 = <&ntn_0p9_en>;
> +		pinctrl-names = "default";
> +		regulator-enable-ramp-delay = <4300>;
> +	};
> +
> +	vdd_ntn_1p8: regulator-vdd-ntn-1p8 {
> +		compatible = "regulator-fixed";
> +		regulator-name = "VDD_NTN_1P8";
> +		gpio = <&pm8350c_gpios 3 GPIO_ACTIVE_HIGH>;
> +		regulator-min-microvolt = <1800000>;
> +		regulator-max-microvolt = <1800000>;
> +		enable-active-high;
> +		pinctrl-0 = <&ntn_1p8_en>;
> +		pinctrl-names = "default";
> +		regulator-enable-ramp-delay = <10000>;
> +	};
>  };
>  
>  &apps_rsc {
> @@ -684,6 +708,75 @@ &mdss_edp_phy {
>  	status = "okay";
>  };
>  
> +&pcie1_port {
> +	pcie@0,0 {
> +		compatible = "pci1179,0623";

The switch is part of SoC or board? This is confusing, I thought QPS615
is the SoC.

> +		reg = <0x10000 0x0 0x0 0x0 0x0>;
> +		#address-cells = <3>;
> +		#size-cells = <2>;

Best regards,
Krzysztof

Re: [PATCH v3 2/6] arm64: dts: qcom: qcs6490-rb3gen2: Add node for qps615

[Dmitry Baryshkov]

On Wed, Nov 20, 2024 at 09:06:03AM +0100, Krzysztof Kozlowski wrote:
> On Tue, Nov 12, 2024 at 08:31:34PM +0530, Krishna chaitanya chundru wrote:
> > Add QPS615 PCIe switch node which has 3 downstream ports and in one
> > downstream port two embedded ethernet devices are present.
> > 
> > Power to the QPS615 is supplied through two LDO regulators, controlled
> > by two GPIOs, these are added as fixed regulators. And the QPS615 is
> > configured through i2c.
> > 
> > Signed-off-by: Krishna chaitanya chundru <quic_krichai@quicinc.com>
> > ---
> >  arch/arm64/boot/dts/qcom/qcs6490-rb3gen2.dts | 115 +++++++++++++++++++++++++++
> >  arch/arm64/boot/dts/qcom/sc7280.dtsi         |   2 +-
> >  2 files changed, 116 insertions(+), 1 deletion(-)
> > 
> > diff --git a/arch/arm64/boot/dts/qcom/qcs6490-rb3gen2.dts b/arch/arm64/boot/dts/qcom/qcs6490-rb3gen2.dts
> > index 0d45662b8028..0e890841b600 100644
> > --- a/arch/arm64/boot/dts/qcom/qcs6490-rb3gen2.dts
> > +++ b/arch/arm64/boot/dts/qcom/qcs6490-rb3gen2.dts
> > @@ -202,6 +202,30 @@ vph_pwr: vph-pwr-regulator {
> >  		regulator-min-microvolt = <3700000>;
> >  		regulator-max-microvolt = <3700000>;
> >  	};
> > +
> > +	vdd_ntn_0p9: regulator-vdd-ntn-0p9 {
> > +		compatible = "regulator-fixed";
> > +		regulator-name = "VDD_NTN_0P9";
> > +		gpio = <&pm8350c_gpios 2 GPIO_ACTIVE_HIGH>;
> > +		regulator-min-microvolt = <899400>;
> > +		regulator-max-microvolt = <899400>;
> > +		enable-active-high;
> > +		pinctrl-0 = <&ntn_0p9_en>;
> > +		pinctrl-names = "default";
> > +		regulator-enable-ramp-delay = <4300>;
> > +	};
> > +
> > +	vdd_ntn_1p8: regulator-vdd-ntn-1p8 {
> > +		compatible = "regulator-fixed";
> > +		regulator-name = "VDD_NTN_1P8";
> > +		gpio = <&pm8350c_gpios 3 GPIO_ACTIVE_HIGH>;
> > +		regulator-min-microvolt = <1800000>;
> > +		regulator-max-microvolt = <1800000>;
> > +		enable-active-high;
> > +		pinctrl-0 = <&ntn_1p8_en>;
> > +		pinctrl-names = "default";
> > +		regulator-enable-ramp-delay = <10000>;
> > +	};
> >  };
> >  
> >  &apps_rsc {
> > @@ -684,6 +708,75 @@ &mdss_edp_phy {
> >  	status = "okay";
> >  };
> >  
> > +&pcie1_port {
> > +	pcie@0,0 {
> > +		compatible = "pci1179,0623";
> 
> The switch is part of SoC or board? This is confusing, I thought QPS615
> is the SoC.

QCS615 is the SoC, QPS615 is a switch.

> 
> > +		reg = <0x10000 0x0 0x0 0x0 0x0>;
> > +		#address-cells = <3>;
> > +		#size-cells = <2>;
> 
> Best regards,
> Krzysztof
> 

-- 
With best wishes
Dmitry

Re: [PATCH v3 2/6] arm64: dts: qcom: qcs6490-rb3gen2: Add node for qps615

[Krzysztof Kozlowski]

On 20/11/2024 12:03, Dmitry Baryshkov wrote:
>>>  
>>>  &apps_rsc {
>>> @@ -684,6 +708,75 @@ &mdss_edp_phy {
>>>  	status = "okay";
>>>  };
>>>  
>>> +&pcie1_port {
>>> +	pcie@0,0 {
>>> +		compatible = "pci1179,0623";
>>
>> The switch is part of SoC or board? This is confusing, I thought QPS615
>> is the SoC.
> 
> QCS615 is the SoC, QPS615 is a switch.
OK, thanks for confirming. Just to be clear, I understand above as: it
is only the switch, nothing else.

Best regards,
Krzysztof

Re: [PATCH v3 6/6] PCI: pwrctl: Add power control driver for qps615

[Uwe Kleine-König]

[-- Attachment #1: Type: text/plain, Size: 251 bytes --]

Hello,

On Tue, Nov 12, 2024 at 08:31:38PM +0530, Krishna chaitanya chundru wrote:
> +static struct platform_driver qps615_pwrctl_driver = {
> [...]
> +	.remove_new = qps615_pwrctl_remove,

Please use .remove instead of .remove_new.

Best regards
Uwe

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 488 bytes --]

Re: [PATCH v3 2/6] arm64: dts: qcom: qcs6490-rb3gen2: Add node for qps615

[Dmitry Baryshkov]

On Wed, Nov 20, 2024 at 02:28:29PM +0100, Krzysztof Kozlowski wrote:
> On 20/11/2024 12:03, Dmitry Baryshkov wrote:
> >>>  
> >>>  &apps_rsc {
> >>> @@ -684,6 +708,75 @@ &mdss_edp_phy {
> >>>  	status = "okay";
> >>>  };
> >>>  
> >>> +&pcie1_port {
> >>> +	pcie@0,0 {
> >>> +		compatible = "pci1179,0623";
> >>
> >> The switch is part of SoC or board? This is confusing, I thought QPS615
> >> is the SoC.
> > 
> > QCS615 is the SoC, QPS615 is a switch.
> OK, thanks for confirming. Just to be clear, I understand above as: it
> is only the switch, nothing else.

PCIe switch, networking interface, but not the SoC (and not a part of
the SoC).

> 
> Best regards,
> Krzysztof

-- 
With best wishes
Dmitry

Re: [PATCH v3 1/6] dt-bindings: PCI: Add binding for qps615

[Krishna Chaitanya Chundru]

On 11/15/2024 9:48 PM, Rob Herring wrote:
> On Tue, Nov 12, 2024 at 08:31:33PM +0530, Krishna chaitanya chundru wrote:
>> Add binding describing the Qualcomm PCIe switch, QPS615,
>> which provides Ethernet MAC integrated to the 3rd downstream port
>> and two downstream PCIe ports.
>>
>> Signed-off-by: Krishna chaitanya chundru <quic_krichai@quicinc.com>
>> ---
>>   .../devicetree/bindings/pci/qcom,qps615.yaml       | 205 +++++++++++++++++++++
>>   1 file changed, 205 insertions(+)
>>
>> diff --git a/Documentation/devicetree/bindings/pci/qcom,qps615.yaml b/Documentation/devicetree/bindings/pci/qcom,qps615.yaml
>> new file mode 100644
>> index 000000000000..e6a63a0bb0f3
>> --- /dev/null
>> +++ b/Documentation/devicetree/bindings/pci/qcom,qps615.yaml
>> @@ -0,0 +1,205 @@
>> +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
>> +%YAML 1.2
>> +---
>> +$id: http://devicetree.org/schemas/pci/qcom,qps615.yaml#
>> +$schema: http://devicetree.org/meta-schemas/core.yaml#
>> +
>> +title: Qualcomm QPS615 PCIe switch
>> +
>> +maintainers:
>> +  - Krishna chaitanya chundru <quic_krichai@quicinc.com>
>> +
>> +description: |
>> +  Qualcomm QPS615 PCIe switch has one upstream and three downstream
>> +  ports. The 3rd downstream port has integrated endpoint device of
>> +  Ethernet MAC. Other two downstream ports are supposed to connect
>> +  to external device.
>> +
>> +  The QPS615 PCIe switch can be configured through I2C interface before
>> +  PCIe link is established to change FTS, ASPM related entry delays,
>> +  tx amplitude etc for better power efficiency and functionality.
>> +
>> +properties:
>> +  compatible:
>> +    enum:
>> +      - pci1179,0623
>> +
>> +  reg:
>> +    maxItems: 1
>> +
>> +  i2c-parent:
>> +    $ref: /schemas/types.yaml#/definitions/phandle-array
>> +    description: |
> 
> Don't need '|' if no formatting to preserve.
> 
ack
>> +      A phandle to the parent I2C node and the slave address of the device
>> +      used to do configure qps615 to change FTS, tx amplitude etc.
>> +    items:
>> +      - description: Phandle to the I2C controller node
>> +      - description: I2C slave address
>> +
>> +  vdd18-supply: true
>> +
>> +  vdd09-supply: true
>> +
>> +  vddc-supply: true
>> +
>> +  vddio1-supply: true
>> +
>> +  vddio2-supply: true
>> +
>> +  vddio18-supply: true
>> +
>> +  reset-gpios:
>> +    maxItems: 1
>> +    description:
>> +      GPIO controlling the RESX# pin.
> 
> Is the PERST# or something else?
> 
it is not PERST GPIO, it is similar to PERST in terms
of functionality which brings switch out from reset.
>> +
>> +  qps615,axi-clk-freq-hz:
> 
> qps615 is not a vendor prefix.
> 
>> +    description:
>> +      AXI clock rate which is internal bus of the switch
>> +      The switch only runs in two frequencies i.e 250MHz and 125MHz.
>> +    enum: [125000000, 250000000]
>> +
>> +allOf:
>> +  - $ref: "#/$defs/qps615-node"
>> +
>> +patternProperties:
>> +  "@1?[0-9a-f](,[0-7])?$":
> 
> You have 3 ports. So isn't this fixed and limited to 0-2?
> 
sure I will change it to below as suggested
"@1?[0-3](,[0-1])?$"
>> +    description: child nodes describing the internal downstream ports
>> +      the qps615 switch.
> 
> Please be consistent with starting after the ':' or on the next line.
> 
> And start with capital C.
> 
>
ack

>> +    type: object
>> +    $ref: "#/$defs/qps615-node"
>> +    unevaluatedProperties: false
>> +
>> +$defs:
>> +  qps615-node:
>> +    type: object
>> +
>> +    properties:
>> +      qcom,l0s-entry-delay-ns:
>> +        description: Aspm l0s entry delay.
>> +
>> +      qcom,l1-entry-delay-ns:
>> +        description: Aspm l1 entry delay.
> 
> These should probably be common being standard PCIe things. Though, why
> are they needed? I'm sure the timing is defined by the PCIe spec, so
> they are not compliant?
> 
Usually the firmware in the endpoints/switches should do this these
configurations. But the qps615 PCIe switch doesn't have any firmware
running to configure these. So the hardware exposes i2c interface to
configure these before link training.
>> +
>> +      qcom,tx-amplitude-millivolt:
>> +        $ref: /schemas/types.yaml#/definitions/uint32
>> +        description: Change Tx Margin setting for low power consumption.
>> +
>> +      qcom,no-dfe-support:
>> +        type: boolean
>> +        description: Disable DFE (Decision Feedback Equalizer), which mitigates
>> +          intersymbol interference and some reflections caused by impedance mismatches.
>> +
>> +      qcom,nfts:
>> +        $ref: /schemas/types.yaml#/definitions/uint32
>> +        description:
>> +          Number of Fast Training Sequence (FTS) used during L0s to L0 exit
>> +          for bit and Symbol lock.
> 
> Also something common.
> 
> The problem I have with all these properties is you are using them on
> both the upstream and downstream sides of the PCIe links. They belong in
> either the device's node (downstream) or the bus's node (upstream).
> 
This switch allows us to configure both upstream, downstream ports and
also embedded Ethernet port which is internal to the switch. These
properties are applicable for all of those.
>> +
>> +    allOf:
>> +      - $ref: /schemas/pci/pci-bus.yaml#
> 
> pci-pci-bridge.yaml is more specific and closer to what this device is.
> 
I tried this now, I was getting warning saying the compatible
/local/mnt/workspace/skales/kobj/Documentation/devicetree/bindings/pci/qcom,qps615.example.dtb: 
pcie@0,0: compatible: ['pci1179,0623'] does not contain items matching 
the given schema
         from schema $id: 
http://devicetree.org/schemas/pci/qcom,qps615.yaml#
/local/mnt/workspace/skales/kobj/Documentation/devicetree/bindings/pci/qcom,qps615.example.dtb: 
pcie@0,0: Unevaluated properties are not allowed ('#address-cells', 
'#size-cells', 'bus-range', 'device_type', 'ranges' were unexpected)

I think pci-pci-bridge is expecting the compatible string in this format
only "pciclass,0604".

>> +
>> +unevaluatedProperties: false
>> +
>> +required:
>> +  - vdd18-supply
>> +  - vdd09-supply
>> +  - vddc-supply
>> +  - vddio1-supply
>> +  - vddio2-supply
>> +  - vddio18-supply
>> +  - i2c-parent
>> +  - reset-gpios
>> +
>> +examples:
>> +  - |
>> +
>> +    #include <dt-bindings/gpio/gpio.h>
>> +
>> +    pcie {
>> +        #address-cells = <3>;
>> +        #size-cells = <2>;
>> +
>> +        pcie@0 {
>> +            device_type = "pci";
>> +            reg = <0x0 0x0 0x0 0x0 0x0>;
>> +
>> +            #address-cells = <3>;
>> +            #size-cells = <2>;
>> +            ranges;
>> +            bus-range = <0x01 0xff>;
>> +
>> +            pcie@0,0 {
>> +                compatible = "pci1179,0623";
>> +                reg = <0x10000 0x0 0x0 0x0 0x0>;
>> +                device_type = "pci";
>> +                #address-cells = <3>;
>> +                #size-cells = <2>;
>> +                ranges;
>> +                bus-range = <0x02 0xff>;
>> +
>> +                i2c-parent = <&qup_i2c 0x77>;
>> +
>> +                vdd18-supply = <&vdd>;
>> +                vdd09-supply = <&vdd>;
>> +                vddc-supply = <&vdd>;
>> +                vddio1-supply = <&vdd>;
>> +                vddio2-supply = <&vdd>;
>> +                vddio18-supply = <&vdd>;
>> +
>> +                reset-gpios = <&gpio 1 GPIO_ACTIVE_LOW>;
>> +
>> +                pcie@1,0 {
>> +                    reg = <0x20800 0x0 0x0 0x0 0x0>;
>> +                    #address-cells = <3>;
>> +                    #size-cells = <2>;
>> +                    device_type = "pci";
>> +                    ranges;
>> +                    bus-range = <0x03 0xff>;
>> +
>> +                    qcom,no-dfe-support;
>> +                };
>> +
>> +                pcie@2,0 {
>> +                    reg = <0x21000 0x0 0x0 0x0 0x0>;
>> +                    #address-cells = <3>;
>> +                    #size-cells = <2>;
>> +                    device_type = "pci";
>> +                    ranges;
>> +                    bus-range = <0x04 0xff>;
>> +
>> +                    qcom,nfts = <10>;
>> +                };
>> +
>> +                pcie@3,0 {
>> +                    reg = <0x21800 0x0 0x0 0x0 0x0>;
>> +                    #address-cells = <3>;
>> +                    #size-cells = <2>;
>> +                    device_type = "pci";
>> +                    ranges;
>> +                    bus-range = <0x05 0xff>;
>> +
>> +                    qcom,tx-amplitude-millivolt = <10>;
>> +                    pcie@0,0 {
>> +                        reg = <0x50000 0x0 0x0 0x0 0x0>;
>> +                        #address-cells = <3>;
>> +                        #size-cells = <2>;
>> +                        device_type = "pci";
> 
> There's a 2nd PCI-PCI bridge?
This the embedded ethernet port which is as part of DSP3.

- Krishna Chaitanya.
> 
>> +                        ranges;
>> +
>> +                        qcom,l1-entry-delay-ns = <10>;
>> +                    };
>> +
>> +                    pcie@0,1 {
>> +                        reg = <0x50100 0x0 0x0 0x0 0x0>;
>> +                        #address-cells = <3>;
>> +                        #size-cells = <2>;
>> +                        device_type = "pci";
>> +                        ranges;
>> +
>> +                        qcom,l0s-entry-delay-ns = <10>;
>> +                    };
>> +                };
>> +            };
>> +        };
>> +    };
>>
>> -- 
>> 2.34.1
>>

Re: [PATCH v3 1/6] dt-bindings: PCI: Add binding for qps615

[Krishna Chaitanya Chundru]

On 11/20/2024 1:34 PM, Krzysztof Kozlowski wrote:
> On Tue, Nov 12, 2024 at 08:31:33PM +0530, Krishna chaitanya chundru wrote:
>> Add binding describing the Qualcomm PCIe switch, QPS615,
>> which provides Ethernet MAC integrated to the 3rd downstream port
>> and two downstream PCIe ports.
>>
>> Signed-off-by: Krishna chaitanya chundru <quic_krichai@quicinc.com>
>> ---
>>   .../devicetree/bindings/pci/qcom,qps615.yaml       | 205 +++++++++++++++++++++
>>   1 file changed, 205 insertions(+)
>>
>> diff --git a/Documentation/devicetree/bindings/pci/qcom,qps615.yaml b/Documentation/devicetree/bindings/pci/qcom,qps615.yaml
>> new file mode 100644
>> index 000000000000..e6a63a0bb0f3
>> --- /dev/null
>> +++ b/Documentation/devicetree/bindings/pci/qcom,qps615.yaml
> 
> Isn't "qcom,qps615" a SoC name? This is supposed to be matching
> compatible, in your case probably qcom,qps615-whatever-this-is?
>
qcom,qcs615 is a soc name, qcom,qps615 is the pcie switch.

ack I will change it to qcom,qps615-pcie

> ...
> 
>> +  qps615,axi-clk-freq-hz:
> 
> That's a downstream code you send us.
> 
> Anyway, why assigned clock rates do not work for you? You are
> re-implementing legacy property now under different name :/
> 
> The assigned clock rates comes in to the picture when we are using clock
framework to control the clocks. For this switch there are no clocks 
needs to be control, the moment we power on the switch clocks are
enabled by default. This switch provides a mechanism to control the
frequency using i2c. And switch supports only two frequencies i.e
125MHz and 250MHZ by default it runs on 250MHz, we can do one i2c
write with which switch runs in 125MHz.
>> +    description:
>> +      AXI clock rate which is internal bus of the switch
>> +      The switch only runs in two frequencies i.e 250MHz and 125MHz.
>> +    enum: [125000000, 250000000]
>> +
>> +allOf:
>> +  - $ref: "#/$defs/qps615-node"
>> +
>> +patternProperties:
>> +  "@1?[0-9a-f](,[0-7])?$":
>> +    description: child nodes describing the internal downstream ports
>> +      the qps615 switch.
>> +    type: object
>> +    $ref: "#/$defs/qps615-node"
>> +    unevaluatedProperties: false
>> +
>> +$defs:
>> +  qps615-node:
>> +    type: object
>> +
>> +    properties:
>> +      qcom,l0s-entry-delay-ns:
>> +        description: Aspm l0s entry delay.
>> +
>> +      qcom,l1-entry-delay-ns:
>> +        description: Aspm l1 entry delay.
>> +
>> +      qcom,tx-amplitude-millivolt:
> 
> -microvolt does not work for you?
> 
let me check this if it is applicable we will change it to microvolt.
>> +        $ref: /schemas/types.yaml#/definitions/uint32
>> +        description: Change Tx Margin setting for low power consumption.
>> +
>> +      qcom,no-dfe-support:
>> +        type: boolean
>> +        description: Disable DFE (Decision Feedback Equalizer), which mitigates
>> +          intersymbol interference and some reflections caused by impedance mismatches.
>> +
>> +      qcom,nfts:
>> +        $ref: /schemas/types.yaml#/definitions/uint32
>> +        description:
>> +          Number of Fast Training Sequence (FTS) used during L0s to L0 exit
>> +          for bit and Symbol lock.
> 
> Use some of these properties in the example. I saw only one.
> 
In the next patch I will try to use all the properties as suggested.
>> +
>> +    allOf:
>> +      - $ref: /schemas/pci/pci-bus.yaml#
>> +
>> +unevaluatedProperties: false
>> +
>> +required:
>> +  - vdd18-supply
>> +  - vdd09-supply
>> +  - vddc-supply
>> +  - vddio1-supply
>> +  - vddio2-supply
>> +  - vddio18-supply
>> +  - i2c-parent
>> +  - reset-gpios
>> +
>> +examples:
>> +  - |
>> +
> 
> Drop blank line
> 
ack.

- Krishna Chaitanya.
>> +    #include <dt-bindings/gpio/gpio.h>
>> +
>> +    pcie {
>> +        #address-cells = <3>;
>> +        #size-cells = <2>;
>> +
>> +        pcie@0 {
>> +            device_type = "pci";
>> +            reg = <0x0 0x0 0x0 0x0 0x0>;
> 
> Best regards,
> Krzysztof
> 

Re: [PATCH v3 5/6] PCI: qcom: Add support for host_stop_link() & host_start_link()

[Krishna Chaitanya Chundru]

On 11/15/2024 5:27 PM, Manivannan Sadhasivam wrote:
> On Tue, Nov 12, 2024 at 08:31:37PM +0530, Krishna chaitanya chundru wrote:
>> For the switches like QPS615 which needs to configure it before
>> the PCIe link is established.
>>
>> If the link is up, the boatloader might powered and configured the
>> endpoint/switch already. In that case don't touch PCIe link else
>> assert the PERST# and disable LTSSM bit so that PCIe controller
>> will not participate in the link training as part of host_stop_link().
>>
>> De-assert the PERST# and enable LTSSM bit back in host_start_link().
>>
>> Introduce ltssm_disable function op to stop the link training.
>>
>> Signed-off-by: Krishna chaitanya chundru <quic_krichai@quicinc.com>
>> ---
>>   drivers/pci/controller/dwc/pcie-qcom.c | 39 ++++++++++++++++++++++++++++++++++
>>   1 file changed, 39 insertions(+)
>>
>> diff --git a/drivers/pci/controller/dwc/pcie-qcom.c b/drivers/pci/controller/dwc/pcie-qcom.c
>> index ef44a82be058..048aea94e319 100644
>> --- a/drivers/pci/controller/dwc/pcie-qcom.c
>> +++ b/drivers/pci/controller/dwc/pcie-qcom.c
>> @@ -246,6 +246,7 @@ struct qcom_pcie_ops {
>>   	void (*host_post_init)(struct qcom_pcie *pcie);
>>   	void (*deinit)(struct qcom_pcie *pcie);
>>   	void (*ltssm_enable)(struct qcom_pcie *pcie);
>> +	void (*ltssm_disable)(struct qcom_pcie *pcie);
>>   	int (*config_sid)(struct qcom_pcie *pcie);
>>   };
>>   
>> @@ -617,6 +618,41 @@ static int qcom_pcie_post_init_1_0_0(struct qcom_pcie *pcie)
>>   	return 0;
>>   }
>>   
>> +static int qcom_pcie_host_start_link(struct dw_pcie *pci)
>> +{
>> +	struct qcom_pcie *pcie = to_qcom_pcie(pci);
>> +
>> +	if (!dw_pcie_link_up(pcie->pci))  {
> 
> I don't think the controller driver should worry about the bootloader
> initialization. You should export dw_pcie_link_up() as a callback and call
> start/stop link if only required (link not up) from the pwrctl driver.
>
Instead of exporting this API, I will try to read config space and see 
if the link is up or not. if it is not up then will call these.

- Krishna Chaitanya.

> - Mani
> 
>> +		qcom_ep_reset_deassert(pcie);
>> +
>> +		if (pcie->cfg->ops->ltssm_enable)
>> +			pcie->cfg->ops->ltssm_enable(pcie);
>> +	}
>> +
>> +	return 0;
>> +}
>> +
>> +static void qcom_pcie_host_stop_link(struct dw_pcie *pci)
>> +{
>> +	struct qcom_pcie *pcie = to_qcom_pcie(pci);
>> +
>> +	if (!dw_pcie_link_up(pcie->pci))  {
>> +		qcom_ep_reset_assert(pcie);
>> +
>> +		if (pcie->cfg->ops->ltssm_disable)
>> +			pcie->cfg->ops->ltssm_disable(pcie);
>> +	}
>> +}
>> +
>> +static void qcom_pcie_2_3_2_ltssm_disable(struct qcom_pcie *pcie)
>> +{
>> +	u32 val;
>> +
>> +	val = readl(pcie->parf + PARF_LTSSM);
>> +	val &= ~LTSSM_EN;
>> +	writel(val, pcie->parf + PARF_LTSSM);
>> +}
>> +
>>   static void qcom_pcie_2_3_2_ltssm_enable(struct qcom_pcie *pcie)
>>   {
>>   	u32 val;
>> @@ -1361,6 +1397,7 @@ static const struct qcom_pcie_ops ops_1_9_0 = {
>>   	.host_post_init = qcom_pcie_host_post_init_2_7_0,
>>   	.deinit = qcom_pcie_deinit_2_7_0,
>>   	.ltssm_enable = qcom_pcie_2_3_2_ltssm_enable,
>> +	.ltssm_disable = qcom_pcie_2_3_2_ltssm_disable,
>>   	.config_sid = qcom_pcie_config_sid_1_9_0,
>>   };
>>   
>> @@ -1418,6 +1455,8 @@ static const struct qcom_pcie_cfg cfg_sc8280xp = {
>>   static const struct dw_pcie_ops dw_pcie_ops = {
>>   	.link_up = qcom_pcie_link_up,
>>   	.start_link = qcom_pcie_start_link,
>> +	.host_start_link = qcom_pcie_host_start_link,
>> +	.host_stop_link = qcom_pcie_host_stop_link,
>>   };
>>   
>>   static int qcom_pcie_icc_init(struct qcom_pcie *pcie)
>>
>> -- 
>> 2.34.1
>>
> 

Re: [PATCH v3 1/6] dt-bindings: PCI: Add binding for qps615

[Krzysztof Kozlowski]

On 24/11/2024 02:41, Krishna Chaitanya Chundru wrote:
>> ...
>>
>>> +  qps615,axi-clk-freq-hz:
>>
>> That's a downstream code you send us.
>>
>> Anyway, why assigned clock rates do not work for you? You are
>> re-implementing legacy property now under different name :/
>>
>> The assigned clock rates comes in to the picture when we are using clock
> framework to control the clocks. For this switch there are no clocks 
> needs to be control, the moment we power on the switch clocks are
> enabled by default. This switch provides a mechanism to control the
> frequency using i2c. And switch supports only two frequencies i.e


frequency of what, since there are no clocks?

> 125MHz and 250MHZ by default it runs on 250MHz, we can do one i2c
> write with which switch runs in 125MHz.

How doing a write is relevant? Or you want to say you can control clock?



Best regards,
Krzysztof

Re: [PATCH v3 1/6] dt-bindings: PCI: Add binding for qps615

[Krishna Chaitanya Chundru]

On 11/25/2024 1:10 PM, Krzysztof Kozlowski wrote:
> On 24/11/2024 02:41, Krishna Chaitanya Chundru wrote:
>>> ...
>>> 
>>>> +  qps615,axi-clk-freq-hz:
>>> 
>>> That's a downstream code you send us.
>>> 
>>> Anyway, why assigned clock rates do not work for you? You are 
>>> re-implementing legacy property now under different name :/
>>> 
>>> The assigned clock rates comes in to the picture when we are 
>>> using clock
>> framework to control the clocks. For this switch there are no 
>> clocks needs to be control, the moment we power on the switch 
>> clocks are enabled by default. This switch provides a mechanism to 
>> control the frequency using i2c. And switch supports only two 
>> frequencies i.e
> 
> 
> frequency of what, since there are no clocks?
> 
The axi clock frequency internal to the switch, host can't control
the enablement of the clocks it can control only the frequency.

we already had a discussion on this on v2[1], and we taught you agreed
on this property.

[1] 
https://lore.kernel.org/netdev/d1af1eac-f9bd-7a8e-586b-5c2a76445145@codeaurora.org/T/#m3d5864c758f2e05fa15ba522aad6a37e3417bd9f

- Krishna Chaitanya.
>> 125MHz and 250MHZ by default it runs on 250MHz, we can do one i2c 
>> write with which switch runs in 125MHz.
> 
> How doing a write is relevant? Or you want to say you can control 
> clock?
> 
> 
> 
> Best regards, Krzysztof

Re: [PATCH v3 1/6] dt-bindings: PCI: Add binding for qps615

[Krzysztof Kozlowski]

On 26/11/2024 07:50, Krishna Chaitanya Chundru wrote:
> 
> 
> On 11/25/2024 1:10 PM, Krzysztof Kozlowski wrote:
>> On 24/11/2024 02:41, Krishna Chaitanya Chundru wrote:
>>>> ...
>>>>
>>>>> +  qps615,axi-clk-freq-hz:
>>>>
>>>> That's a downstream code you send us.
>>>>
>>>> Anyway, why assigned clock rates do not work for you? You are 
>>>> re-implementing legacy property now under different name :/
>>>>
>>>> The assigned clock rates comes in to the picture when we are 
>>>> using clock
>>> framework to control the clocks. For this switch there are no 
>>> clocks needs to be control, the moment we power on the switch 
>>> clocks are enabled by default. This switch provides a mechanism to 
>>> control the frequency using i2c. And switch supports only two 
>>> frequencies i.e
>>
>>
>> frequency of what, since there are no clocks?
>>
> The axi clock frequency internal to the switch, host can't control
> the enablement of the clocks it can control only the frequency.
> 
> we already had a discussion on this on v2[1], and we taught you agreed
> on this property.
> 
> [1] 
> https://lore.kernel.org/netdev/d1af1eac-f9bd-7a8e-586b-5c2a76445145@codeaurora.org/T/#m3d5864c758f2e05fa15ba522aad6a37e3417bd9f
> 

This points something else. I diged v2 and found many unanswered
questions and unfinished discussion:

https://lore.kernel.org/r/linux-arm-msm/20240803-qps615-v2-0-9560b7c71369@quicinc.com/T/#m7074ab9e5f89e29faf430c82f769e67d0e4072cf

The property description did not improve, actually it got worse: you
repeat constraints in free form text.

Best regards,
Krzysztof

Re: [PATCH v3 1/6] dt-bindings: PCI: Add binding for qps615

[Manivannan Sadhasivam]

On Tue, Nov 26, 2024 at 07:58:16AM +0100, Krzysztof Kozlowski wrote:
> On 26/11/2024 07:50, Krishna Chaitanya Chundru wrote:
> > 
> > 
> > On 11/25/2024 1:10 PM, Krzysztof Kozlowski wrote:
> >> On 24/11/2024 02:41, Krishna Chaitanya Chundru wrote:
> >>>> ...
> >>>>
> >>>>> +  qps615,axi-clk-freq-hz:
> >>>>
> >>>> That's a downstream code you send us.
> >>>>
> >>>> Anyway, why assigned clock rates do not work for you? You are 
> >>>> re-implementing legacy property now under different name :/
> >>>>
> >>>> The assigned clock rates comes in to the picture when we are 
> >>>> using clock
> >>> framework to control the clocks. For this switch there are no 
> >>> clocks needs to be control, the moment we power on the switch 
> >>> clocks are enabled by default. This switch provides a mechanism to 
> >>> control the frequency using i2c. And switch supports only two 
> >>> frequencies i.e
> >>
> >>
> >> frequency of what, since there are no clocks?
> >>
> > The axi clock frequency internal to the switch, host can't control
> > the enablement of the clocks it can control only the frequency.
> > 
> > we already had a discussion on this on v2[1], and we taught you agreed
> > on this property.
> > 
> > [1] 
> > https://lore.kernel.org/netdev/d1af1eac-f9bd-7a8e-586b-5c2a76445145@codeaurora.org/T/#m3d5864c758f2e05fa15ba522aad6a37e3417bd9f
> > 
> 
> This points something else. I diged v2 and found many unanswered
> questions and unfinished discussion:
> 

The conversation is here:
https://lore.kernel.org/linux-arm-msm/20240823094028.7xul4eoiexey5xjm@thinkpad/

But there was no explicit agreement on the usage of 'qps615,axi-clk-freq-hz'.

If describing the PCI device's internal clock frequency is not applicable, then
I'd recommend to change the clock rate in the driver itself based on the number
of DSPs enabled (or based on other configuration).

- Mani

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

Re: [PATCH v3 1/6] dt-bindings: PCI: Add binding for qps615

[Dmitry Baryshkov]

On Thu, Nov 28, 2024 at 06:54:32PM +0530, Manivannan Sadhasivam wrote:
> On Tue, Nov 26, 2024 at 07:58:16AM +0100, Krzysztof Kozlowski wrote:
> > On 26/11/2024 07:50, Krishna Chaitanya Chundru wrote:
> > > 
> > > 
> > > On 11/25/2024 1:10 PM, Krzysztof Kozlowski wrote:
> > >> On 24/11/2024 02:41, Krishna Chaitanya Chundru wrote:
> > >>>> ...
> > >>>>
> > >>>>> +  qps615,axi-clk-freq-hz:
> > >>>>
> > >>>> That's a downstream code you send us.
> > >>>>
> > >>>> Anyway, why assigned clock rates do not work for you? You are 
> > >>>> re-implementing legacy property now under different name :/
> > >>>>
> > >>>> The assigned clock rates comes in to the picture when we are 
> > >>>> using clock
> > >>> framework to control the clocks. For this switch there are no 
> > >>> clocks needs to be control, the moment we power on the switch 
> > >>> clocks are enabled by default. This switch provides a mechanism to 
> > >>> control the frequency using i2c. And switch supports only two 
> > >>> frequencies i.e
> > >>
> > >>
> > >> frequency of what, since there are no clocks?
> > >>
> > > The axi clock frequency internal to the switch, host can't control
> > > the enablement of the clocks it can control only the frequency.
> > > 
> > > we already had a discussion on this on v2[1], and we taught you agreed
> > > on this property.
> > > 
> > > [1] 
> > > https://lore.kernel.org/netdev/d1af1eac-f9bd-7a8e-586b-5c2a76445145@codeaurora.org/T/#m3d5864c758f2e05fa15ba522aad6a37e3417bd9f
> > > 
> > 
> > This points something else. I diged v2 and found many unanswered
> > questions and unfinished discussion:
> > 
> 
> The conversation is here:
> https://lore.kernel.org/linux-arm-msm/20240823094028.7xul4eoiexey5xjm@thinkpad/
> 
> But there was no explicit agreement on the usage of 'qps615,axi-clk-freq-hz'.
> 
> If describing the PCI device's internal clock frequency is not applicable, then
> I'd recommend to change the clock rate in the driver itself based on the number
> of DSPs enabled (or based on other configuration).

Sounds like the best approach. Otherwise it's not obvious, what is the
criteria for selecting this or that clock value.

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

-- 
With best wishes
Dmitry

Re: [PATCH v3 1/6] dt-bindings: PCI: Add binding for qps615

[Krishna Chaitanya Chundru]

On 11/28/2024 7:38 PM, Dmitry Baryshkov wrote:
> On Thu, Nov 28, 2024 at 06:54:32PM +0530, Manivannan Sadhasivam wrote:
>> On Tue, Nov 26, 2024 at 07:58:16AM +0100, Krzysztof Kozlowski wrote:
>>> On 26/11/2024 07:50, Krishna Chaitanya Chundru wrote:
>>>>
>>>>
>>>> On 11/25/2024 1:10 PM, Krzysztof Kozlowski wrote:
>>>>> On 24/11/2024 02:41, Krishna Chaitanya Chundru wrote:
>>>>>>> ...
>>>>>>>
>>>>>>>> +  qps615,axi-clk-freq-hz:
>>>>>>>
>>>>>>> That's a downstream code you send us.
>>>>>>>
>>>>>>> Anyway, why assigned clock rates do not work for you? You are
>>>>>>> re-implementing legacy property now under different name :/
>>>>>>>
>>>>>>> The assigned clock rates comes in to the picture when we are
>>>>>>> using clock
>>>>>> framework to control the clocks. For this switch there are no
>>>>>> clocks needs to be control, the moment we power on the switch
>>>>>> clocks are enabled by default. This switch provides a mechanism to
>>>>>> control the frequency using i2c. And switch supports only two
>>>>>> frequencies i.e
>>>>>
>>>>>
>>>>> frequency of what, since there are no clocks?
>>>>>
>>>> The axi clock frequency internal to the switch, host can't control
>>>> the enablement of the clocks it can control only the frequency.
>>>>
>>>> we already had a discussion on this on v2[1], and we taught you agreed
>>>> on this property.
>>>>
>>>> [1]
>>>> https://lore.kernel.org/netdev/d1af1eac-f9bd-7a8e-586b-5c2a76445145@codeaurora.org/T/#m3d5864c758f2e05fa15ba522aad6a37e3417bd9f
>>>>
>>>
>>> This points something else. I diged v2 and found many unanswered
>>> questions and unfinished discussion:
>>>
>>
>> The conversation is here:
>> https://lore.kernel.org/linux-arm-msm/20240823094028.7xul4eoiexey5xjm@thinkpad/
>>
>> But there was no explicit agreement on the usage of 'qps615,axi-clk-freq-hz'.
>>
>> If describing the PCI device's internal clock frequency is not applicable, then
>> I'd recommend to change the clock rate in the driver itself based on the number
>> of DSPs enabled (or based on other configuration).
> 
> Sounds like the best approach. Otherwise it's not obvious, what is the
> criteria for selecting this or that clock value.
> 
I will remove this property in next patch and driver code to set this 
frequency in the next patch, we will try to come up with some logic later.

- Krishna chaitanya.
>>
>> - Mani
>>
>> -- 
>> மணிவண்ணன் சதாசிவம்
> 

Re: [PATCH v3 1/6] dt-bindings: PCI: Add binding for qps615

[Krishna Chaitanya Chundru]

On 11/24/2024 7:02 AM, Krishna Chaitanya Chundru wrote:
> 
> 
> On 11/15/2024 9:48 PM, Rob Herring wrote:
>> On Tue, Nov 12, 2024 at 08:31:33PM +0530, Krishna chaitanya chundru 
>> wrote:
>>> Add binding describing the Qualcomm PCIe switch, QPS615,
>>> which provides Ethernet MAC integrated to the 3rd downstream port
>>> and two downstream PCIe ports.
>>>
>>> Signed-off-by: Krishna chaitanya chundru <quic_krichai@quicinc.com>
>>> ---
>>>   .../devicetree/bindings/pci/qcom,qps615.yaml       | 205 
>>> +++++++++++++++++++++
>>>   1 file changed, 205 insertions(+)
>>>
>>> diff --git a/Documentation/devicetree/bindings/pci/qcom,qps615.yaml 
>>> b/Documentation/devicetree/bindings/pci/qcom,qps615.yaml
>>> new file mode 100644
>>> index 000000000000..e6a63a0bb0f3
>>> --- /dev/null
>>> +++ b/Documentation/devicetree/bindings/pci/qcom,qps615.yaml
>>> @@ -0,0 +1,205 @@
>>> +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
>>> +%YAML 1.2
>>> +---
>>> +$id: http://devicetree.org/schemas/pci/qcom,qps615.yaml#
>>> +$schema: http://devicetree.org/meta-schemas/core.yaml#
>>> +
>>> +title: Qualcomm QPS615 PCIe switch
>>> +
>>> +maintainers:
>>> +  - Krishna chaitanya chundru <quic_krichai@quicinc.com>
>>> +
>>> +description: |
>>> +  Qualcomm QPS615 PCIe switch has one upstream and three downstream
>>> +  ports. The 3rd downstream port has integrated endpoint device of
>>> +  Ethernet MAC. Other two downstream ports are supposed to connect
>>> +  to external device.
>>> +
>>> +  The QPS615 PCIe switch can be configured through I2C interface before
>>> +  PCIe link is established to change FTS, ASPM related entry delays,
>>> +  tx amplitude etc for better power efficiency and functionality.
>>> +
>>> +properties:
>>> +  compatible:
>>> +    enum:
>>> +      - pci1179,0623
>>> +
>>> +  reg:
>>> +    maxItems: 1
>>> +
>>> +  i2c-parent:
>>> +    $ref: /schemas/types.yaml#/definitions/phandle-array
>>> +    description: |
>>
>> Don't need '|' if no formatting to preserve.
>>
> ack
>>> +      A phandle to the parent I2C node and the slave address of the 
>>> device
>>> +      used to do configure qps615 to change FTS, tx amplitude etc.
>>> +    items:
>>> +      - description: Phandle to the I2C controller node
>>> +      - description: I2C slave address
>>> +
>>> +  vdd18-supply: true
>>> +
>>> +  vdd09-supply: true
>>> +
>>> +  vddc-supply: true
>>> +
>>> +  vddio1-supply: true
>>> +
>>> +  vddio2-supply: true
>>> +
>>> +  vddio18-supply: true
>>> +
>>> +  reset-gpios:
>>> +    maxItems: 1
>>> +    description:
>>> +      GPIO controlling the RESX# pin.
>>
>> Is the PERST# or something else?
>>
> it is not PERST GPIO, it is similar to PERST in terms
> of functionality which brings switch out from reset.
>>> +
>>> +  qps615,axi-clk-freq-hz:
>>
>> qps615 is not a vendor prefix.
>>
>>> +    description:
>>> +      AXI clock rate which is internal bus of the switch
>>> +      The switch only runs in two frequencies i.e 250MHz and 125MHz.
>>> +    enum: [125000000, 250000000]
>>> +
>>> +allOf:
>>> +  - $ref: "#/$defs/qps615-node"
>>> +
>>> +patternProperties:
>>> +  "@1?[0-9a-f](,[0-7])?$":
>>
>> You have 3 ports. So isn't this fixed and limited to 0-2?
>>
> sure I will change it to below as suggested
> "@1?[0-3](,[0-1])?$"
>>> +    description: child nodes describing the internal downstream ports
>>> +      the qps615 switch.
>>
>> Please be consistent with starting after the ':' or on the next line.
>>
>> And start with capital C.
>>
>>
> ack
> 
>>> +    type: object
>>> +    $ref: "#/$defs/qps615-node"
>>> +    unevaluatedProperties: false
>>> +
>>> +$defs:
>>> +  qps615-node:
>>> +    type: object
>>> +
>>> +    properties:
>>> +      qcom,l0s-entry-delay-ns:
>>> +        description: Aspm l0s entry delay.
>>> +
>>> +      qcom,l1-entry-delay-ns:
>>> +        description: Aspm l1 entry delay.
>>
>> These should probably be common being standard PCIe things. Though, why
>> are they needed? I'm sure the timing is defined by the PCIe spec, so
>> they are not compliant?
>>
> Usually the firmware in the endpoints/switches should do this these
> configurations. But the qps615 PCIe switch doesn't have any firmware
> running to configure these. So the hardware exposes i2c interface to
> configure these before link training.
>>> +
>>> +      qcom,tx-amplitude-millivolt:
>>> +        $ref: /schemas/types.yaml#/definitions/uint32
>>> +        description: Change Tx Margin setting for low power 
>>> consumption.
>>> +
>>> +      qcom,no-dfe-support:
>>> +        type: boolean
>>> +        description: Disable DFE (Decision Feedback Equalizer), 
>>> which mitigates
>>> +          intersymbol interference and some reflections caused by 
>>> impedance mismatches.
>>> +
>>> +      qcom,nfts:
>>> +        $ref: /schemas/types.yaml#/definitions/uint32
>>> +        description:
>>> +          Number of Fast Training Sequence (FTS) used during L0s to 
>>> L0 exit
>>> +          for bit and Symbol lock.
>>
>> Also something common.
>>
>> The problem I have with all these properties is you are using them on
>> both the upstream and downstream sides of the PCIe links. They belong in
>> either the device's node (downstream) or the bus's node (upstream).
>>
> This switch allows us to configure both upstream, downstream ports and
> also embedded Ethernet port which is internal to the switch. These
> properties are applicable for all of those.
>>> +
>>> +    allOf:
>>> +      - $ref: /schemas/pci/pci-bus.yaml#
>>
>> pci-pci-bridge.yaml is more specific and closer to what this device is.
>>
> I tried this now, I was getting warning saying the compatible
> /local/mnt/workspace/skales/kobj/Documentation/devicetree/bindings/pci/qcom,qps615.example.dtb: pcie@0,0: compatible: ['pci1179,0623'] does not contain items matching the given schema
>          from schema $id: 
> http://devicetree.org/schemas/pci/qcom,qps615.yaml#
> /local/mnt/workspace/skales/kobj/Documentation/devicetree/bindings/pci/qcom,qps615.example.dtb: pcie@0,0: Unevaluated properties are not allowed ('#address-cells', '#size-cells', 'bus-range', 'device_type', 'ranges' were unexpected)
> 
> I think pci-pci-bridge is expecting the compatible string in this format
> only "pciclass,0604".
> 
>>> +
>>> +unevaluatedProperties: false
>>> +
>>> +required:
>>> +  - vdd18-supply
>>> +  - vdd09-supply
>>> +  - vddc-supply
>>> +  - vddio1-supply
>>> +  - vddio2-supply
>>> +  - vddio18-supply
>>> +  - i2c-parent
>>> +  - reset-gpios
>>> +
>>> +examples:
>>> +  - |
>>> +
>>> +    #include <dt-bindings/gpio/gpio.h>
>>> +
>>> +    pcie {
>>> +        #address-cells = <3>;
>>> +        #size-cells = <2>;
>>> +
>>> +        pcie@0 {
>>> +            device_type = "pci";
>>> +            reg = <0x0 0x0 0x0 0x0 0x0>;
>>> +
>>> +            #address-cells = <3>;
>>> +            #size-cells = <2>;
>>> +            ranges;
>>> +            bus-range = <0x01 0xff>;
>>> +
>>> +            pcie@0,0 {
>>> +                compatible = "pci1179,0623";
>>> +                reg = <0x10000 0x0 0x0 0x0 0x0>;
>>> +                device_type = "pci";
>>> +                #address-cells = <3>;
>>> +                #size-cells = <2>;
>>> +                ranges;
>>> +                bus-range = <0x02 0xff>;
>>> +
>>> +                i2c-parent = <&qup_i2c 0x77>;
>>> +
>>> +                vdd18-supply = <&vdd>;
>>> +                vdd09-supply = <&vdd>;
>>> +                vddc-supply = <&vdd>;
>>> +                vddio1-supply = <&vdd>;
>>> +                vddio2-supply = <&vdd>;
>>> +                vddio18-supply = <&vdd>;
>>> +
>>> +                reset-gpios = <&gpio 1 GPIO_ACTIVE_LOW>;
>>> +
>>> +                pcie@1,0 {
>>> +                    reg = <0x20800 0x0 0x0 0x0 0x0>;
>>> +                    #address-cells = <3>;
>>> +                    #size-cells = <2>;
>>> +                    device_type = "pci";
>>> +                    ranges;
>>> +                    bus-range = <0x03 0xff>;
>>> +
>>> +                    qcom,no-dfe-support;
>>> +                };
>>> +
>>> +                pcie@2,0 {
>>> +                    reg = <0x21000 0x0 0x0 0x0 0x0>;
>>> +                    #address-cells = <3>;
>>> +                    #size-cells = <2>;
>>> +                    device_type = "pci";
>>> +                    ranges;
>>> +                    bus-range = <0x04 0xff>;
>>> +
>>> +                    qcom,nfts = <10>;
>>> +                };
>>> +
>>> +                pcie@3,0 {
>>> +                    reg = <0x21800 0x0 0x0 0x0 0x0>;
>>> +                    #address-cells = <3>;
>>> +                    #size-cells = <2>;
>>> +                    device_type = "pci";
>>> +                    ranges;
>>> +                    bus-range = <0x05 0xff>;
>>> +
>>> +                    qcom,tx-amplitude-millivolt = <10>;
>>> +                    pcie@0,0 {
>>> +                        reg = <0x50000 0x0 0x0 0x0 0x0>;
>>> +                        #address-cells = <3>;
>>> +                        #size-cells = <2>;
>>> +                        device_type = "pci";
>>
>> There's a 2nd PCI-PCI bridge?
> This the embedded ethernet port which is as part of DSP3.
> 
Hi Rob,

Can you please check my response on your queries, if you need
any extra information, we can provide to sort this out.

- Krishna Chaitanya.
> - Krishna Chaitanya.
>>
>>> +                        ranges;
>>> +
>>> +                        qcom,l1-entry-delay-ns = <10>;
>>> +                    };
>>> +
>>> +                    pcie@0,1 {
>>> +                        reg = <0x50100 0x0 0x0 0x0 0x0>;
>>> +                        #address-cells = <3>;
>>> +                        #size-cells = <2>;
>>> +                        device_type = "pci";
>>> +                        ranges;
>>> +
>>> +                        qcom,l0s-entry-delay-ns = <10>;
>>> +                    };
>>> +                };
>>> +            };
>>> +        };
>>> +    };
>>>
>>> -- 
>>> 2.34.1
>>>
> 

Re: [PATCH v3 6/6] PCI: pwrctl: Add power control driver for qps615

[Bjorn Helgaas]

On Tue, Nov 12, 2024 at 08:31:38PM +0530, Krishna chaitanya chundru wrote:
> QPS615 is the PCIe switch which has one upstream and three downstream
> ports. To one of the downstream ports ethernet MAC is connected as endpoint
> device. Other two downstream ports are supposed to connect to external
> device. One Host can connect to QPS615 by upstream port. QPS615 switch
> needs to be configured after powering on and before PCIe link was up.

s/is the/is a/

> The PCIe controller driver already enables link training at the host side
> even before qps615 driver probe happens, due to this when driver enables
> power to the switch it participates in the link training and PCIe link
> may come up before configuring the switch through i2c. To prevent the
> host from participating in link training, disable link training on the
> host side to ensure the link does not come up before the switch is
> configured via I2C.
> 
> Based up on dt property and type of the port, qps615 is configured
> through i2c.

> +config PCI_PWRCTL_QPS615
> +	tristate "PCI Power Control driver for QPS615"
> +	select PCI_PWRCTL
> +	help
> +	  Say Y here to enable the pwrctl driver for Qualcomm
> +	  QPS615 PCIe switch which enables and configures it
> +	  through i2c.

Does this work if build as a module?  I guess maybe the QPS615 doesn't
even get powered on without this, so it would be configured and then
powered on after module-load time?

s/pwrctl/pwrctrl/ (also in filename, code, variables, etc below)

Will need to be rebased to account for the pwrctl -> pwrctrl rename in
v6.13-rc1.

> +static int qps615_pwrctl_power_on(struct qps615_pwrctl_ctx *ctx)
> +{
> +	struct qps615_pwrctl_cfg *cfg;
> +	int ret, i;
> +
> +	ret = regulator_bulk_enable(ARRAY_SIZE(ctx->supplies), ctx->supplies);
> +	if (ret < 0)
> +		return dev_err_probe(ctx->pwrctl.dev, ret, "cannot enable regulators\n");
> +
> +	gpiod_set_value(ctx->reset_gpio, 0);
> +
> +	 /* wait for the internal osc frequency to stablise */

s/stablise/stabilise/

> +	usleep_range(10000, 10500);
> +
> +	ret = qps615_pwrctl_assert_deassert_reset(ctx, false);
> +	if (ret)
> +		goto out;
> +
> +	if (ctx->cfg[QPS615_USP].axi_freq_125) {
> +		ret = qps615_pwrctl_i2c_write(ctx->client, QPS615_BUS_CONTROL, BIT(16));
> +		if (ret)
> +			dev_err(ctx->pwrctl.dev, "Setting AXI clk freq failed %d\n", ret);
> +	}
> +
> +	for (i = 0; i < QPS615_MAX; i++) {
> +		cfg = &ctx->cfg[i];
> +		if (cfg->disable_port) {
> +			ret = qps615_pwrctl_disable_port(ctx, i);
> +			if (ret) {
> +				dev_err(ctx->pwrctl.dev, "Disabling port failed\n");
> +				goto out;
> +			}
> +		}

A helper function could remove a level of indentation for the body of
this loop.

> +static int qps615_pwrctl_probe(struct platform_device *pdev)
> +{
> +	struct device *dev = &pdev->dev;
> +	struct pci_host_bridge *bridge;
> +	enum qps615_pwrctl_ports port;
> +	struct qps615_pwrctl_ctx *ctx;
> +	int ret, addr;
> +
> +	bridge = pci_find_host_bridge(to_pci_dev(dev->parent)->bus);

Move to where "bridge" is used.

> +	platform_set_drvdata(pdev, ctx);

Can this be moved to the point where we know we won't return an error?

Bjorn

Re: [PATCH v3 1/6] dt-bindings: PCI: Add binding for qps615

[Bjorn Helgaas]

On Tue, Nov 12, 2024 at 08:31:33PM +0530, Krishna chaitanya chundru wrote:
> Add binding describing the Qualcomm PCIe switch, QPS615,
> which provides Ethernet MAC integrated to the 3rd downstream port
> and two downstream PCIe ports.

> +$defs:
> +  qps615-node:
> +    type: object
> +
> +    properties:
> +      qcom,l0s-entry-delay-ns:
> +        description: Aspm l0s entry delay.
> +
> +      qcom,l1-entry-delay-ns:
> +        description: Aspm l1 entry delay.

To match spec usage:
s/Aspm/ASPM/
s/l0s/L0s/
s/l1/L1/

Other than the fact that qps615 needs the driver to configure these,
there's nothing qcom-specific here, so I suggest the names should omit
"qcom" and include "aspm".

> +    pcie {
> +        #address-cells = <3>;
> +        #size-cells = <2>;
> +
> +        pcie@0 {
> +            device_type = "pci";
> +            reg = <0x0 0x0 0x0 0x0 0x0>;
> +
> +            #address-cells = <3>;
> +            #size-cells = <2>;
> +            ranges;
> +            bus-range = <0x01 0xff>;
> +
> +            pcie@0,0 {
> +                compatible = "pci1179,0623";
> +                reg = <0x10000 0x0 0x0 0x0 0x0>;
> +                device_type = "pci";
> +                #address-cells = <3>;
> +                #size-cells = <2>;
> +                ranges;
> +                bus-range = <0x02 0xff>;

This binding describes a switch.  I don't think bus-range should
appear here at all because it is not a feature of the hardware (unless
the switch ports are broken and their Secondary/Subordinate Bus
Numbers are hard-wired).

The Primary/Secondary/Subordinate Bus Numbers of all switch ports
should be writable and the PCI core knows how to manage them.

Bjorn

Re: [PATCH v3 1/6] dt-bindings: PCI: Add binding for qps615

[Manivannan Sadhasivam]

On Wed, Dec 04, 2024 at 03:25:59PM -0600, Bjorn Helgaas wrote:
> On Tue, Nov 12, 2024 at 08:31:33PM +0530, Krishna chaitanya chundru wrote:
> > Add binding describing the Qualcomm PCIe switch, QPS615,
> > which provides Ethernet MAC integrated to the 3rd downstream port
> > and two downstream PCIe ports.
> 
> > +$defs:
> > +  qps615-node:
> > +    type: object
> > +
> > +    properties:
> > +      qcom,l0s-entry-delay-ns:
> > +        description: Aspm l0s entry delay.
> > +
> > +      qcom,l1-entry-delay-ns:
> > +        description: Aspm l1 entry delay.
> 
> To match spec usage:
> s/Aspm/ASPM/
> s/l0s/L0s/
> s/l1/L1/
> 
> Other than the fact that qps615 needs the driver to configure these,
> there's nothing qcom-specific here, so I suggest the names should omit
> "qcom" and include "aspm".
> 

In that case, these properties should be documented in dt-schema:
https://github.com/devicetree-org/dt-schema/blob/main/dtschema/schemas/pci/pci-bus-common.yaml

- Mani

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

Re: [PATCH v3 1/6] dt-bindings: PCI: Add binding for qps615

[Krishna Chaitanya Chundru]

On 12/4/2024 2:19 PM, Krishna Chaitanya Chundru wrote:
> 
> 
> On 11/24/2024 7:02 AM, Krishna Chaitanya Chundru wrote:
>>
>>
>> On 11/15/2024 9:48 PM, Rob Herring wrote:
>>> On Tue, Nov 12, 2024 at 08:31:33PM +0530, Krishna chaitanya chundru 
>>> wrote:
>>>> Add binding describing the Qualcomm PCIe switch, QPS615,
>>>> which provides Ethernet MAC integrated to the 3rd downstream port
>>>> and two downstream PCIe ports.
>>>>
>>>> Signed-off-by: Krishna chaitanya chundru <quic_krichai@quicinc.com>
>>>> ---
>>>>   .../devicetree/bindings/pci/qcom,qps615.yaml       | 205 
>>>> +++++++++++++++++++++
>>>>   1 file changed, 205 insertions(+)
>>>>
>>>> diff --git a/Documentation/devicetree/bindings/pci/qcom,qps615.yaml 
>>>> b/Documentation/devicetree/bindings/pci/qcom,qps615.yaml
>>>> new file mode 100644
>>>> index 000000000000..e6a63a0bb0f3
>>>> --- /dev/null
>>>> +++ b/Documentation/devicetree/bindings/pci/qcom,qps615.yaml
>>>> @@ -0,0 +1,205 @@
>>>> +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
>>>> +%YAML 1.2
>>>> +---
>>>> +$id: http://devicetree.org/schemas/pci/qcom,qps615.yaml#
>>>> +$schema: http://devicetree.org/meta-schemas/core.yaml#
>>>> +
>>>> +title: Qualcomm QPS615 PCIe switch
>>>> +
>>>> +maintainers:
>>>> +  - Krishna chaitanya chundru <quic_krichai@quicinc.com>
>>>> +
>>>> +description: |
>>>> +  Qualcomm QPS615 PCIe switch has one upstream and three downstream
>>>> +  ports. The 3rd downstream port has integrated endpoint device of
>>>> +  Ethernet MAC. Other two downstream ports are supposed to connect
>>>> +  to external device.
>>>> +
>>>> +  The QPS615 PCIe switch can be configured through I2C interface 
>>>> before
>>>> +  PCIe link is established to change FTS, ASPM related entry delays,
>>>> +  tx amplitude etc for better power efficiency and functionality.
>>>> +
>>>> +properties:
>>>> +  compatible:
>>>> +    enum:
>>>> +      - pci1179,0623
>>>> +
>>>> +  reg:
>>>> +    maxItems: 1
>>>> +
>>>> +  i2c-parent:
>>>> +    $ref: /schemas/types.yaml#/definitions/phandle-array
>>>> +    description: |
>>>
>>> Don't need '|' if no formatting to preserve.
>>>
>> ack
>>>> +      A phandle to the parent I2C node and the slave address of the 
>>>> device
>>>> +      used to do configure qps615 to change FTS, tx amplitude etc.
>>>> +    items:
>>>> +      - description: Phandle to the I2C controller node
>>>> +      - description: I2C slave address
>>>> +
>>>> +  vdd18-supply: true
>>>> +
>>>> +  vdd09-supply: true
>>>> +
>>>> +  vddc-supply: true
>>>> +
>>>> +  vddio1-supply: true
>>>> +
>>>> +  vddio2-supply: true
>>>> +
>>>> +  vddio18-supply: true
>>>> +
>>>> +  reset-gpios:
>>>> +    maxItems: 1
>>>> +    description:
>>>> +      GPIO controlling the RESX# pin.
>>>
>>> Is the PERST# or something else?
>>>
>> it is not PERST GPIO, it is similar to PERST in terms
>> of functionality which brings switch out from reset.
>>>> +
>>>> +  qps615,axi-clk-freq-hz:
>>>
>>> qps615 is not a vendor prefix.
>>>
>>>> +    description:
>>>> +      AXI clock rate which is internal bus of the switch
>>>> +      The switch only runs in two frequencies i.e 250MHz and 125MHz.
>>>> +    enum: [125000000, 250000000]
>>>> +
>>>> +allOf:
>>>> +  - $ref: "#/$defs/qps615-node"
>>>> +
>>>> +patternProperties:
>>>> +  "@1?[0-9a-f](,[0-7])?$":
>>>
>>> You have 3 ports. So isn't this fixed and limited to 0-2?
>>>
>> sure I will change it to below as suggested
>> "@1?[0-3](,[0-1])?$"
>>>> +    description: child nodes describing the internal downstream ports
>>>> +      the qps615 switch.
>>>
>>> Please be consistent with starting after the ':' or on the next line.
>>>
>>> And start with capital C.
>>>
>>>
>> ack
>>
>>>> +    type: object
>>>> +    $ref: "#/$defs/qps615-node"
>>>> +    unevaluatedProperties: false
>>>> +
>>>> +$defs:
>>>> +  qps615-node:
>>>> +    type: object
>>>> +
>>>> +    properties:
>>>> +      qcom,l0s-entry-delay-ns:
>>>> +        description: Aspm l0s entry delay.
>>>> +
>>>> +      qcom,l1-entry-delay-ns:
>>>> +        description: Aspm l1 entry delay.
>>>
>>> These should probably be common being standard PCIe things. Though, why
>>> are they needed? I'm sure the timing is defined by the PCIe spec, so
>>> they are not compliant?
>>>
>> Usually the firmware in the endpoints/switches should do this these
>> configurations. But the qps615 PCIe switch doesn't have any firmware
>> running to configure these. So the hardware exposes i2c interface to
>> configure these before link training.
>>>> +
>>>> +      qcom,tx-amplitude-millivolt:
>>>> +        $ref: /schemas/types.yaml#/definitions/uint32
>>>> +        description: Change Tx Margin setting for low power 
>>>> consumption.
>>>> +
>>>> +      qcom,no-dfe-support:
>>>> +        type: boolean
>>>> +        description: Disable DFE (Decision Feedback Equalizer), 
>>>> which mitigates
>>>> +          intersymbol interference and some reflections caused by 
>>>> impedance mismatches.
>>>> +
>>>> +      qcom,nfts:
>>>> +        $ref: /schemas/types.yaml#/definitions/uint32
>>>> +        description:
>>>> +          Number of Fast Training Sequence (FTS) used during L0s to 
>>>> L0 exit
>>>> +          for bit and Symbol lock.
>>>
>>> Also something common.
>>>
>>> The problem I have with all these properties is you are using them on
>>> both the upstream and downstream sides of the PCIe links. They belong in
>>> either the device's node (downstream) or the bus's node (upstream).
>>>
>> This switch allows us to configure both upstream, downstream ports and
>> also embedded Ethernet port which is internal to the switch. These
>> properties are applicable for all of those.
>>>> +
>>>> +    allOf:
>>>> +      - $ref: /schemas/pci/pci-bus.yaml#
>>>
>>> pci-pci-bridge.yaml is more specific and closer to what this device is.
>>>
>> I tried this now, I was getting warning saying the compatible
>> /local/mnt/workspace/skales/kobj/Documentation/devicetree/bindings/pci/qcom,qps615.example.dtb: pcie@0,0: compatible: ['pci1179,0623'] does not contain items matching the given schema
>>          from schema $id: 
>> http://devicetree.org/schemas/pci/qcom,qps615.yaml#
>> /local/mnt/workspace/skales/kobj/Documentation/devicetree/bindings/pci/qcom,qps615.example.dtb: pcie@0,0: Unevaluated properties are not allowed ('#address-cells', '#size-cells', 'bus-range', 'device_type', 'ranges' were unexpected)
>>
>> I think pci-pci-bridge is expecting the compatible string in this format
>> only "pciclass,0604".
>>
>>>> +
>>>> +unevaluatedProperties: false
>>>> +
>>>> +required:
>>>> +  - vdd18-supply
>>>> +  - vdd09-supply
>>>> +  - vddc-supply
>>>> +  - vddio1-supply
>>>> +  - vddio2-supply
>>>> +  - vddio18-supply
>>>> +  - i2c-parent
>>>> +  - reset-gpios
>>>> +
>>>> +examples:
>>>> +  - |
>>>> +
>>>> +    #include <dt-bindings/gpio/gpio.h>
>>>> +
>>>> +    pcie {
>>>> +        #address-cells = <3>;
>>>> +        #size-cells = <2>;
>>>> +
>>>> +        pcie@0 {
>>>> +            device_type = "pci";
>>>> +            reg = <0x0 0x0 0x0 0x0 0x0>;
>>>> +
>>>> +            #address-cells = <3>;
>>>> +            #size-cells = <2>;
>>>> +            ranges;
>>>> +            bus-range = <0x01 0xff>;
>>>> +
>>>> +            pcie@0,0 {
>>>> +                compatible = "pci1179,0623";
>>>> +                reg = <0x10000 0x0 0x0 0x0 0x0>;
>>>> +                device_type = "pci";
>>>> +                #address-cells = <3>;
>>>> +                #size-cells = <2>;
>>>> +                ranges;
>>>> +                bus-range = <0x02 0xff>;
>>>> +
>>>> +                i2c-parent = <&qup_i2c 0x77>;
>>>> +
>>>> +                vdd18-supply = <&vdd>;
>>>> +                vdd09-supply = <&vdd>;
>>>> +                vddc-supply = <&vdd>;
>>>> +                vddio1-supply = <&vdd>;
>>>> +                vddio2-supply = <&vdd>;
>>>> +                vddio18-supply = <&vdd>;
>>>> +
>>>> +                reset-gpios = <&gpio 1 GPIO_ACTIVE_LOW>;
>>>> +
>>>> +                pcie@1,0 {
>>>> +                    reg = <0x20800 0x0 0x0 0x0 0x0>;
>>>> +                    #address-cells = <3>;
>>>> +                    #size-cells = <2>;
>>>> +                    device_type = "pci";
>>>> +                    ranges;
>>>> +                    bus-range = <0x03 0xff>;
>>>> +
>>>> +                    qcom,no-dfe-support;
>>>> +                };
>>>> +
>>>> +                pcie@2,0 {
>>>> +                    reg = <0x21000 0x0 0x0 0x0 0x0>;
>>>> +                    #address-cells = <3>;
>>>> +                    #size-cells = <2>;
>>>> +                    device_type = "pci";
>>>> +                    ranges;
>>>> +                    bus-range = <0x04 0xff>;
>>>> +
>>>> +                    qcom,nfts = <10>;
>>>> +                };
>>>> +
>>>> +                pcie@3,0 {
>>>> +                    reg = <0x21800 0x0 0x0 0x0 0x0>;
>>>> +                    #address-cells = <3>;
>>>> +                    #size-cells = <2>;
>>>> +                    device_type = "pci";
>>>> +                    ranges;
>>>> +                    bus-range = <0x05 0xff>;
>>>> +
>>>> +                    qcom,tx-amplitude-millivolt = <10>;
>>>> +                    pcie@0,0 {
>>>> +                        reg = <0x50000 0x0 0x0 0x0 0x0>;
>>>> +                        #address-cells = <3>;
>>>> +                        #size-cells = <2>;
>>>> +                        device_type = "pci";
>>>
>>> There's a 2nd PCI-PCI bridge?
>> This the embedded ethernet port which is as part of DSP3.
>>
> Hi Rob,
> 
> Can you please check my response on your queries, if you need
> any extra information, we can provide to sort this out.
> 
> - Krishna Chaitanya.
>> - Krishna Chaitanya

A gentle ping as its been more than 2 weeks.

- Krishna Chaitanya.
.
>>>
>>>> +                        ranges;
>>>> +
>>>> +                        qcom,l1-entry-delay-ns = <10>;
>>>> +                    };
>>>> +
>>>> +                    pcie@0,1 {
>>>> +                        reg = <0x50100 0x0 0x0 0x0 0x0>;
>>>> +                        #address-cells = <3>;
>>>> +                        #size-cells = <2>;
>>>> +                        device_type = "pci";
>>>> +                        ranges;
>>>> +
>>>> +                        qcom,l0s-entry-delay-ns = <10>;
>>>> +                    };
>>>> +                };
>>>> +            };
>>>> +        };
>>>> +    };
>>>>
>>>> -- 
>>>> 2.34.1
>>>>
>>
> 

Re: [PATCH v3 1/6] dt-bindings: PCI: Add binding for qps615

[Krishna Chaitanya Chundru]

On 12/11/2024 11:30 AM, Manivannan Sadhasivam wrote:
> On Wed, Dec 04, 2024 at 03:25:59PM -0600, Bjorn Helgaas wrote:
>> On Tue, Nov 12, 2024 at 08:31:33PM +0530, Krishna chaitanya chundru wrote:
>>> Add binding describing the Qualcomm PCIe switch, QPS615,
>>> which provides Ethernet MAC integrated to the 3rd downstream port
>>> and two downstream PCIe ports.
>>
>>> +$defs:
>>> +  qps615-node:
>>> +    type: object
>>> +
>>> +    properties:
>>> +      qcom,l0s-entry-delay-ns:
>>> +        description: Aspm l0s entry delay.
>>> +
>>> +      qcom,l1-entry-delay-ns:
>>> +        description: Aspm l1 entry delay.
>>
>> To match spec usage:
>> s/Aspm/ASPM/
>> s/l0s/L0s/
>> s/l1/L1/
>>
>> Other than the fact that qps615 needs the driver to configure these,
>> there's nothing qcom-specific here, so I suggest the names should omit
>> "qcom" and include "aspm".
>>
> 
> In that case, these properties should be documented in dt-schema:
> https://github.com/devicetree-org/dt-schema/blob/main/dtschema/schemas/pci/pci-bus-common.yaml
> 
> - Mani
I am fine to move to pci-bus-common.yaml but currently these are being 
used by qps615 only I hope that is fine.

- Krishna Chaitanya.
> 

Re: [PATCH v3 1/6] dt-bindings: PCI: Add binding for qps615

[Dmitry Baryshkov]

On Sun, Nov 24, 2024 at 07:02:48AM +0530, Krishna Chaitanya Chundru wrote:
> 
> 
> On 11/15/2024 9:48 PM, Rob Herring wrote:
> > On Tue, Nov 12, 2024 at 08:31:33PM +0530, Krishna chaitanya chundru wrote:
> > > Add binding describing the Qualcomm PCIe switch, QPS615,
> > > which provides Ethernet MAC integrated to the 3rd downstream port
> > > and two downstream PCIe ports.
> > > 
> > > Signed-off-by: Krishna chaitanya chundru <quic_krichai@quicinc.com>
> > > ---
> > >   .../devicetree/bindings/pci/qcom,qps615.yaml       | 205 +++++++++++++++++++++
> > >   1 file changed, 205 insertions(+)
> > > 
> > > diff --git a/Documentation/devicetree/bindings/pci/qcom,qps615.yaml b/Documentation/devicetree/bindings/pci/qcom,qps615.yaml
> > > new file mode 100644
> > > index 000000000000..e6a63a0bb0f3
> > > --- /dev/null
> > > +++ b/Documentation/devicetree/bindings/pci/qcom,qps615.yaml
> > > @@ -0,0 +1,205 @@
> > > +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
> > > +%YAML 1.2
> > > +---
> > > +$id: http://devicetree.org/schemas/pci/qcom,qps615.yaml#
> > > +$schema: http://devicetree.org/meta-schemas/core.yaml#
> > > +
> > > +title: Qualcomm QPS615 PCIe switch
> > > +
> > > +maintainers:
> > > +  - Krishna chaitanya chundru <quic_krichai@quicinc.com>
> > > +
> > > +description: |
> > > +  Qualcomm QPS615 PCIe switch has one upstream and three downstream
> > > +  ports. The 3rd downstream port has integrated endpoint device of
> > > +  Ethernet MAC. Other two downstream ports are supposed to connect
> > > +  to external device.
> > > +
> > > +  The QPS615 PCIe switch can be configured through I2C interface before
> > > +  PCIe link is established to change FTS, ASPM related entry delays,
> > > +  tx amplitude etc for better power efficiency and functionality.
> > > +
> > > +properties:
> > > +  compatible:
> > > +    enum:
> > > +      - pci1179,0623
> > > +
> > > +  reg:
> > > +    maxItems: 1
> > > +
> > > +  i2c-parent:
> > > +    $ref: /schemas/types.yaml#/definitions/phandle-array
> > > +    description: |
> > 
> > Don't need '|' if no formatting to preserve.
> > 
> ack
> > > +      A phandle to the parent I2C node and the slave address of the device
> > > +      used to do configure qps615 to change FTS, tx amplitude etc.
> > > +    items:
> > > +      - description: Phandle to the I2C controller node
> > > +      - description: I2C slave address
> > > +
> > > +  vdd18-supply: true
> > > +
> > > +  vdd09-supply: true
> > > +
> > > +  vddc-supply: true
> > > +
> > > +  vddio1-supply: true
> > > +
> > > +  vddio2-supply: true
> > > +
> > > +  vddio18-supply: true
> > > +
> > > +  reset-gpios:
> > > +    maxItems: 1
> > > +    description:
> > > +      GPIO controlling the RESX# pin.
> > 
> > Is the PERST# or something else?
> > 
> it is not PERST GPIO, it is similar to PERST in terms
> of functionality which brings switch out from reset.

Do you have an actual PERST# on upstream facing port? Is it a separate
wire? Judging by the RB3 Gen2 this line is being used as PERST#

> > > +
> > > +  qps615,axi-clk-freq-hz:
> > 
> > qps615 is not a vendor prefix.
> > 
> > > +    description:
> > > +      AXI clock rate which is internal bus of the switch
> > > +      The switch only runs in two frequencies i.e 250MHz and 125MHz.
> > > +    enum: [125000000, 250000000]
> > > +
> > > +allOf:
> > > +  - $ref: "#/$defs/qps615-node"
> > > +
> > > +patternProperties:
> > > +  "@1?[0-9a-f](,[0-7])?$":
> > 
> > You have 3 ports. So isn't this fixed and limited to 0-2?
> > 
> sure I will change it to below as suggested
> "@1?[0-3](,[0-1])?$"

Why do you still need '1?' ?

> > > +    description: child nodes describing the internal downstream ports
> > > +      the qps615 switch.
> > 
> > Please be consistent with starting after the ':' or on the next line.
> > 
> > And start with capital C.
> > 
> > 
> ack
> 
> > > +    type: object
> > > +    $ref: "#/$defs/qps615-node"
> > > +    unevaluatedProperties: false
> > > +
> > > +$defs:
> > > +  qps615-node:
> > > +    type: object
> > > +
> > > +    properties:
> > > +      qcom,l0s-entry-delay-ns:
> > > +        description: Aspm l0s entry delay.
> > > +
> > > +      qcom,l1-entry-delay-ns:
> > > +        description: Aspm l1 entry delay.
> > 
> > These should probably be common being standard PCIe things. Though, why
> > are they needed? I'm sure the timing is defined by the PCIe spec, so
> > they are not compliant?
> > 
> Usually the firmware in the endpoints/switches should do this these
> configurations. But the qps615 PCIe switch doesn't have any firmware
> running to configure these. So the hardware exposes i2c interface to
> configure these before link training.

If they are following the standard, why do you need to have them in the
DT? Can you hardcode thos evalues in the driver?

> > > +
> > > +      qcom,tx-amplitude-millivolt:
> > > +        $ref: /schemas/types.yaml#/definitions/uint32
> > > +        description: Change Tx Margin setting for low power consumption.
> > > +
> > > +      qcom,no-dfe-support:
> > > +        type: boolean
> > > +        description: Disable DFE (Decision Feedback Equalizer), which mitigates
> > > +          intersymbol interference and some reflections caused by impedance mismatches.
> > > +
> > > +      qcom,nfts:
> > > +        $ref: /schemas/types.yaml#/definitions/uint32
> > > +        description:
> > > +          Number of Fast Training Sequence (FTS) used during L0s to L0 exit
> > > +          for bit and Symbol lock.
> > 
> > Also something common.
> > 
> > The problem I have with all these properties is you are using them on
> > both the upstream and downstream sides of the PCIe links. They belong in
> > either the device's node (downstream) or the bus's node (upstream).
> > 
> This switch allows us to configure both upstream, downstream ports and
> also embedded Ethernet port which is internal to the switch. These
> properties are applicable for all of those.
> > > +
> > > +    allOf:
> > > +      - $ref: /schemas/pci/pci-bus.yaml#
> > 
> > pci-pci-bridge.yaml is more specific and closer to what this device is.
> > 
> I tried this now, I was getting warning saying the compatible
> /local/mnt/workspace/skales/kobj/Documentation/devicetree/bindings/pci/qcom,qps615.example.dtb:
> pcie@0,0: compatible: ['pci1179,0623'] does not contain items matching the
> given schema
>         from schema $id: http://devicetree.org/schemas/pci/qcom,qps615.yaml#
> /local/mnt/workspace/skales/kobj/Documentation/devicetree/bindings/pci/qcom,qps615.example.dtb:
> pcie@0,0: Unevaluated properties are not allowed ('#address-cells',
> '#size-cells', 'bus-range', 'device_type', 'ranges' were unexpected)
> 
> I think pci-pci-bridge is expecting the compatible string in this format
> only "pciclass,0604".

I think the pci-pci-bridge schema requires to have "pciclass,0604" among
other compatibles. So you should be able to do something like:

compatible = "pci1179,0623", "pciclass,0604";

At least if follows PCI Bus Binding to Open Firmware document.

> 
> > > +
> > > +unevaluatedProperties: false
> > > +
> > > +required:
> > > +  - vdd18-supply
> > > +  - vdd09-supply
> > > +  - vddc-supply
> > > +  - vddio1-supply
> > > +  - vddio2-supply
> > > +  - vddio18-supply
> > > +  - i2c-parent
> > > +  - reset-gpios
> > > +
> > > +examples:
> > > +  - |
> > > +
> > > +    #include <dt-bindings/gpio/gpio.h>
> > > +
> > > +    pcie {
> > > +        #address-cells = <3>;
> > > +        #size-cells = <2>;
> > > +
> > > +        pcie@0 {
> > > +            device_type = "pci";
> > > +            reg = <0x0 0x0 0x0 0x0 0x0>;
> > > +
> > > +            #address-cells = <3>;
> > > +            #size-cells = <2>;
> > > +            ranges;
> > > +            bus-range = <0x01 0xff>;
> > > +
> > > +            pcie@0,0 {
> > > +                compatible = "pci1179,0623";
> > > +                reg = <0x10000 0x0 0x0 0x0 0x0>;
> > > +                device_type = "pci";
> > > +                #address-cells = <3>;
> > > +                #size-cells = <2>;
> > > +                ranges;
> > > +                bus-range = <0x02 0xff>;
> > > +
> > > +                i2c-parent = <&qup_i2c 0x77>;
> > > +
> > > +                vdd18-supply = <&vdd>;
> > > +                vdd09-supply = <&vdd>;
> > > +                vddc-supply = <&vdd>;
> > > +                vddio1-supply = <&vdd>;
> > > +                vddio2-supply = <&vdd>;
> > > +                vddio18-supply = <&vdd>;
> > > +
> > > +                reset-gpios = <&gpio 1 GPIO_ACTIVE_LOW>;
> > > +
> > > +                pcie@1,0 {
> > > +                    reg = <0x20800 0x0 0x0 0x0 0x0>;
> > > +                    #address-cells = <3>;
> > > +                    #size-cells = <2>;
> > > +                    device_type = "pci";
> > > +                    ranges;
> > > +                    bus-range = <0x03 0xff>;
> > > +
> > > +                    qcom,no-dfe-support;
> > > +                };
> > > +
> > > +                pcie@2,0 {
> > > +                    reg = <0x21000 0x0 0x0 0x0 0x0>;
> > > +                    #address-cells = <3>;
> > > +                    #size-cells = <2>;
> > > +                    device_type = "pci";
> > > +                    ranges;
> > > +                    bus-range = <0x04 0xff>;
> > > +
> > > +                    qcom,nfts = <10>;
> > > +                };
> > > +
> > > +                pcie@3,0 {
> > > +                    reg = <0x21800 0x0 0x0 0x0 0x0>;
> > > +                    #address-cells = <3>;
> > > +                    #size-cells = <2>;
> > > +                    device_type = "pci";
> > > +                    ranges;
> > > +                    bus-range = <0x05 0xff>;
> > > +
> > > +                    qcom,tx-amplitude-millivolt = <10>;
> > > +                    pcie@0,0 {
> > > +                        reg = <0x50000 0x0 0x0 0x0 0x0>;
> > > +                        #address-cells = <3>;
> > > +                        #size-cells = <2>;
> > > +                        device_type = "pci";
> > 
> > There's a 2nd PCI-PCI bridge?
> This the embedded ethernet port which is as part of DSP3.

So is there an adidtional bus for that ethernet device?

> 
> - Krishna Chaitanya.
> > 
> > > +                        ranges;
> > > +
> > > +                        qcom,l1-entry-delay-ns = <10>;
> > > +                    };
> > > +
> > > +                    pcie@0,1 {
> > > +                        reg = <0x50100 0x0 0x0 0x0 0x0>;
> > > +                        #address-cells = <3>;
> > > +                        #size-cells = <2>;
> > > +                        device_type = "pci";
> > > +                        ranges;
> > > +
> > > +                        qcom,l0s-entry-delay-ns = <10>;
> > > +                    };

What is this?

> > > +                };
> > > +            };
> > > +        };
> > > +    };
> > > 
> > > -- 
> > > 2.34.1
> > > 

-- 
With best wishes
Dmitry

Re: [PATCH v3 1/6] dt-bindings: PCI: Add binding for qps615

[Dmitry Baryshkov]

On Mon, Dec 23, 2024 at 10:18:24PM +0530, Krishna Chaitanya Chundru wrote:
> 
> 
> On 12/11/2024 11:30 AM, Manivannan Sadhasivam wrote:
> > On Wed, Dec 04, 2024 at 03:25:59PM -0600, Bjorn Helgaas wrote:
> > > On Tue, Nov 12, 2024 at 08:31:33PM +0530, Krishna chaitanya chundru wrote:
> > > > Add binding describing the Qualcomm PCIe switch, QPS615,
> > > > which provides Ethernet MAC integrated to the 3rd downstream port
> > > > and two downstream PCIe ports.
> > > 
> > > > +$defs:
> > > > +  qps615-node:
> > > > +    type: object
> > > > +
> > > > +    properties:
> > > > +      qcom,l0s-entry-delay-ns:
> > > > +        description: Aspm l0s entry delay.
> > > > +
> > > > +      qcom,l1-entry-delay-ns:
> > > > +        description: Aspm l1 entry delay.
> > > 
> > > To match spec usage:
> > > s/Aspm/ASPM/
> > > s/l0s/L0s/
> > > s/l1/L1/
> > > 
> > > Other than the fact that qps615 needs the driver to configure these,
> > > there's nothing qcom-specific here, so I suggest the names should omit
> > > "qcom" and include "aspm".
> > > 
> > 
> > In that case, these properties should be documented in dt-schema:
> > https://github.com/devicetree-org/dt-schema/blob/main/dtschema/schemas/pci/pci-bus-common.yaml
> > 
> > - Mani
> I am fine to move to pci-bus-common.yaml but currently these are being used
> by qps615 only I hope that is fine.

With bindings there is no such thing as "currently". Once defined they
become an ABI and must not be changed.

-- 
With best wishes
Dmitry

Re: [PATCH v3 1/6] dt-bindings: PCI: Add binding for qps615

[Krishna Chaitanya Chundru]

On 12/24/2024 12:27 AM, Dmitry Baryshkov wrote:
> On Sun, Nov 24, 2024 at 07:02:48AM +0530, Krishna Chaitanya Chundru wrote:
>>
>>
>> On 11/15/2024 9:48 PM, Rob Herring wrote:
>>> On Tue, Nov 12, 2024 at 08:31:33PM +0530, Krishna chaitanya chundru wrote:
>>>> Add binding describing the Qualcomm PCIe switch, QPS615,
>>>> which provides Ethernet MAC integrated to the 3rd downstream port
>>>> and two downstream PCIe ports.
>>>>
>>>> Signed-off-by: Krishna chaitanya chundru <quic_krichai@quicinc.com>
>>>> ---
>>>>    .../devicetree/bindings/pci/qcom,qps615.yaml       | 205 +++++++++++++++++++++
>>>>    1 file changed, 205 insertions(+)
>>>>
>>>> diff --git a/Documentation/devicetree/bindings/pci/qcom,qps615.yaml b/Documentation/devicetree/bindings/pci/qcom,qps615.yaml
>>>> new file mode 100644
>>>> index 000000000000..e6a63a0bb0f3
>>>> --- /dev/null
>>>> +++ b/Documentation/devicetree/bindings/pci/qcom,qps615.yaml
>>>> @@ -0,0 +1,205 @@
>>>> +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
>>>> +%YAML 1.2
>>>> +---
>>>> +$id: http://devicetree.org/schemas/pci/qcom,qps615.yaml#
>>>> +$schema: http://devicetree.org/meta-schemas/core.yaml#
>>>> +
>>>> +title: Qualcomm QPS615 PCIe switch
>>>> +
>>>> +maintainers:
>>>> +  - Krishna chaitanya chundru <quic_krichai@quicinc.com>
>>>> +
>>>> +description: |
>>>> +  Qualcomm QPS615 PCIe switch has one upstream and three downstream
>>>> +  ports. The 3rd downstream port has integrated endpoint device of
>>>> +  Ethernet MAC. Other two downstream ports are supposed to connect
>>>> +  to external device.
>>>> +
>>>> +  The QPS615 PCIe switch can be configured through I2C interface before
>>>> +  PCIe link is established to change FTS, ASPM related entry delays,
>>>> +  tx amplitude etc for better power efficiency and functionality.
>>>> +
>>>> +properties:
>>>> +  compatible:
>>>> +    enum:
>>>> +      - pci1179,0623
>>>> +
>>>> +  reg:
>>>> +    maxItems: 1
>>>> +
>>>> +  i2c-parent:
>>>> +    $ref: /schemas/types.yaml#/definitions/phandle-array
>>>> +    description: |
>>>
>>> Don't need '|' if no formatting to preserve.
>>>
>> ack
>>>> +      A phandle to the parent I2C node and the slave address of the device
>>>> +      used to do configure qps615 to change FTS, tx amplitude etc.
>>>> +    items:
>>>> +      - description: Phandle to the I2C controller node
>>>> +      - description: I2C slave address
>>>> +
>>>> +  vdd18-supply: true
>>>> +
>>>> +  vdd09-supply: true
>>>> +
>>>> +  vddc-supply: true
>>>> +
>>>> +  vddio1-supply: true
>>>> +
>>>> +  vddio2-supply: true
>>>> +
>>>> +  vddio18-supply: true
>>>> +
>>>> +  reset-gpios:
>>>> +    maxItems: 1
>>>> +    description:
>>>> +      GPIO controlling the RESX# pin.
>>>
>>> Is the PERST# or something else?
>>>
>> it is not PERST GPIO, it is similar to PERST in terms
>> of functionality which brings switch out from reset.
> 
> Do you have an actual PERST# on upstream facing port? Is it a separate
> wire? Judging by the RB3 Gen2 this line is being used as PERST#
> 
we had PERST# as a separate line. It has two inputs one is PERST# &
other one is RESX# gpio functionality wise both are similar.
>>>> +
>>>> +  qps615,axi-clk-freq-hz:
>>>
>>> qps615 is not a vendor prefix.
>>>
>>>> +    description:
>>>> +      AXI clock rate which is internal bus of the switch
>>>> +      The switch only runs in two frequencies i.e 250MHz and 125MHz.
>>>> +    enum: [125000000, 250000000]
>>>> +
>>>> +allOf:
>>>> +  - $ref: "#/$defs/qps615-node"
>>>> +
>>>> +patternProperties:
>>>> +  "@1?[0-9a-f](,[0-7])?$":
>>>
>>> You have 3 ports. So isn't this fixed and limited to 0-2?
>>>
>> sure I will change it to below as suggested
>> "@1?[0-3](,[0-1])?$"
> 
> Why do you still need '1?' ?
> 
we want to represent integrated ethernet MAC also here and to represent 
it we need '1' as it is multi function device. I will update the
description to reflect the same.
>>>> +    description: child nodes describing the internal downstream ports
>>>> +      the qps615 switch.
>>>
>>> Please be consistent with starting after the ':' or on the next line.
>>>
>>> And start with capital C.
>>>
>>>
>> ack
>>
>>>> +    type: object
>>>> +    $ref: "#/$defs/qps615-node"
>>>> +    unevaluatedProperties: false
>>>> +
>>>> +$defs:
>>>> +  qps615-node:
>>>> +    type: object
>>>> +
>>>> +    properties:
>>>> +      qcom,l0s-entry-delay-ns:
>>>> +        description: Aspm l0s entry delay.
>>>> +
>>>> +      qcom,l1-entry-delay-ns:
>>>> +        description: Aspm l1 entry delay.
>>>
>>> These should probably be common being standard PCIe things. Though, why
>>> are they needed? I'm sure the timing is defined by the PCIe spec, so
>>> they are not compliant?
>>>
>> Usually the firmware in the endpoints/switches should do this these
>> configurations. But the qps615 PCIe switch doesn't have any firmware
>> running to configure these. So the hardware exposes i2c interface to
>> configure these before link training.
> 
> If they are following the standard, why do you need to have them in the
> DT? Can you hardcode thos evalues in the driver?
> 
These values can be changed from platform to platform based upon the 
different power goals and latency requirements so we can't have hard 
coded values.

And even DWC controllers also provide provision to change these values 
currently we are not using them. As bjorn suggested if we move these to
common pcie bindings these can be used in future by controller drivers also.
>>>> +
>>>> +      qcom,tx-amplitude-millivolt:
>>>> +        $ref: /schemas/types.yaml#/definitions/uint32
>>>> +        description: Change Tx Margin setting for low power consumption.
>>>> +
>>>> +      qcom,no-dfe-support:
>>>> +        type: boolean
>>>> +        description: Disable DFE (Decision Feedback Equalizer), which mitigates
>>>> +          intersymbol interference and some reflections caused by impedance mismatches.
>>>> +
>>>> +      qcom,nfts:
>>>> +        $ref: /schemas/types.yaml#/definitions/uint32
>>>> +        description:
>>>> +          Number of Fast Training Sequence (FTS) used during L0s to L0 exit
>>>> +          for bit and Symbol lock.
>>>
>>> Also something common.
>>>
>>> The problem I have with all these properties is you are using them on
>>> both the upstream and downstream sides of the PCIe links. They belong in
>>> either the device's node (downstream) or the bus's node (upstream).
>>>
>> This switch allows us to configure both upstream, downstream ports and
>> also embedded Ethernet port which is internal to the switch. These
>> properties are applicable for all of those.
>>>> +
>>>> +    allOf:
>>>> +      - $ref: /schemas/pci/pci-bus.yaml#
>>>
>>> pci-pci-bridge.yaml is more specific and closer to what this device is.
>>>
>> I tried this now, I was getting warning saying the compatible
>> /local/mnt/workspace/skales/kobj/Documentation/devicetree/bindings/pci/qcom,qps615.example.dtb:
>> pcie@0,0: compatible: ['pci1179,0623'] does not contain items matching the
>> given schema
>>          from schema $id: http://devicetree.org/schemas/pci/qcom,qps615.yaml#
>> /local/mnt/workspace/skales/kobj/Documentation/devicetree/bindings/pci/qcom,qps615.example.dtb:
>> pcie@0,0: Unevaluated properties are not allowed ('#address-cells',
>> '#size-cells', 'bus-range', 'device_type', 'ranges' were unexpected)
>>
>> I think pci-pci-bridge is expecting the compatible string in this format
>> only "pciclass,0604".
> 
> I think the pci-pci-bridge schema requires to have "pciclass,0604" among
> other compatibles. So you should be able to do something like:
> 
> compatible = "pci1179,0623", "pciclass,0604";
> 
> At least if follows PCI Bus Binding to Open Firmware document.
> 
let us try this and come back.
>>
>>>> +
>>>> +unevaluatedProperties: false
>>>> +
>>>> +required:
>>>> +  - vdd18-supply
>>>> +  - vdd09-supply
>>>> +  - vddc-supply
>>>> +  - vddio1-supply
>>>> +  - vddio2-supply
>>>> +  - vddio18-supply
>>>> +  - i2c-parent
>>>> +  - reset-gpios
>>>> +
>>>> +examples:
>>>> +  - |
>>>> +
>>>> +    #include <dt-bindings/gpio/gpio.h>
>>>> +
>>>> +    pcie {
>>>> +        #address-cells = <3>;
>>>> +        #size-cells = <2>;
>>>> +
>>>> +        pcie@0 {
>>>> +            device_type = "pci";
>>>> +            reg = <0x0 0x0 0x0 0x0 0x0>;
>>>> +
>>>> +            #address-cells = <3>;
>>>> +            #size-cells = <2>;
>>>> +            ranges;
>>>> +            bus-range = <0x01 0xff>;
>>>> +
>>>> +            pcie@0,0 {
>>>> +                compatible = "pci1179,0623";
>>>> +                reg = <0x10000 0x0 0x0 0x0 0x0>;
>>>> +                device_type = "pci";
>>>> +                #address-cells = <3>;
>>>> +                #size-cells = <2>;
>>>> +                ranges;
>>>> +                bus-range = <0x02 0xff>;
>>>> +
>>>> +                i2c-parent = <&qup_i2c 0x77>;
>>>> +
>>>> +                vdd18-supply = <&vdd>;
>>>> +                vdd09-supply = <&vdd>;
>>>> +                vddc-supply = <&vdd>;
>>>> +                vddio1-supply = <&vdd>;
>>>> +                vddio2-supply = <&vdd>;
>>>> +                vddio18-supply = <&vdd>;
>>>> +
>>>> +                reset-gpios = <&gpio 1 GPIO_ACTIVE_LOW>;
>>>> +
>>>> +                pcie@1,0 {
>>>> +                    reg = <0x20800 0x0 0x0 0x0 0x0>;
>>>> +                    #address-cells = <3>;
>>>> +                    #size-cells = <2>;
>>>> +                    device_type = "pci";
>>>> +                    ranges;
>>>> +                    bus-range = <0x03 0xff>;
>>>> +
>>>> +                    qcom,no-dfe-support;
>>>> +                };
>>>> +
>>>> +                pcie@2,0 {
>>>> +                    reg = <0x21000 0x0 0x0 0x0 0x0>;
>>>> +                    #address-cells = <3>;
>>>> +                    #size-cells = <2>;
>>>> +                    device_type = "pci";
>>>> +                    ranges;
>>>> +                    bus-range = <0x04 0xff>;
>>>> +
>>>> +                    qcom,nfts = <10>;
>>>> +                };
>>>> +
>>>> +                pcie@3,0 {
>>>> +                    reg = <0x21800 0x0 0x0 0x0 0x0>;
>>>> +                    #address-cells = <3>;
>>>> +                    #size-cells = <2>;
>>>> +                    device_type = "pci";
>>>> +                    ranges;
>>>> +                    bus-range = <0x05 0xff>;
>>>> +
>>>> +                    qcom,tx-amplitude-millivolt = <10>;
>>>> +                    pcie@0,0 {
>>>> +                        reg = <0x50000 0x0 0x0 0x0 0x0>;
>>>> +                        #address-cells = <3>;
>>>> +                        #size-cells = <2>;
>>>> +                        device_type = "pci";
>>>
>>> There's a 2nd PCI-PCI bridge?
>> This the embedded ethernet port which is as part of DSP3.
> 
> So is there an adidtional bus for that ethernet device?
> 
yes for ethernet it has aditional bus assigned.

>>
>> - Krishna Chaitanya.
>>>
>>>> +                        ranges;
>>>> +
>>>> +                        qcom,l1-entry-delay-ns = <10>;
>>>> +                    };
>>>> +
>>>> +                    pcie@0,1 {
>>>> +                        reg = <0x50100 0x0 0x0 0x0 0x0>;
>>>> +                        #address-cells = <3>;
>>>> +                        #size-cells = <2>;
>>>> +                        device_type = "pci";
>>>> +                        ranges;
>>>> +
>>>> +                        qcom,l0s-entry-delay-ns = <10>;
>>>> +                    };
> 
> What is this?
>
Ethernet endpoint is a multi function device which has 2 functions
This node represents 2nd node. I will update the description to
reflect the same.

- Krishna Chaitanya.

>>>> +                };
>>>> +            };
>>>> +        };
>>>> +    };
>>>>
>>>> -- 
>>>> 2.34.1
>>>>
> 

Re: [PATCH v3 1/6] dt-bindings: PCI: Add binding for qps615

[Dmitry Baryshkov]

On Tue, Dec 24, 2024 at 11:34:10AM +0530, Krishna Chaitanya Chundru wrote:
> 
> 
> On 12/24/2024 12:27 AM, Dmitry Baryshkov wrote:
> > On Sun, Nov 24, 2024 at 07:02:48AM +0530, Krishna Chaitanya Chundru wrote:
> > > 
> > > 
> > > On 11/15/2024 9:48 PM, Rob Herring wrote:
> > > > On Tue, Nov 12, 2024 at 08:31:33PM +0530, Krishna chaitanya chundru wrote:
> > > > > Add binding describing the Qualcomm PCIe switch, QPS615,
> > > > > which provides Ethernet MAC integrated to the 3rd downstream port
> > > > > and two downstream PCIe ports.
> > > > > 
> > > > > Signed-off-by: Krishna chaitanya chundru <quic_krichai@quicinc.com>
> > > > > ---
> > > > >    .../devicetree/bindings/pci/qcom,qps615.yaml       | 205 +++++++++++++++++++++
> > > > >    1 file changed, 205 insertions(+)
> > > > > 
> > > > > diff --git a/Documentation/devicetree/bindings/pci/qcom,qps615.yaml b/Documentation/devicetree/bindings/pci/qcom,qps615.yaml
> > > > > new file mode 100644
> > > > > index 000000000000..e6a63a0bb0f3
> > > > > --- /dev/null
> > > > > +++ b/Documentation/devicetree/bindings/pci/qcom,qps615.yaml
> > > > > @@ -0,0 +1,205 @@
> > > > > +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
> > > > > +%YAML 1.2
> > > > > +---
> > > > > +$id: http://devicetree.org/schemas/pci/qcom,qps615.yaml#
> > > > > +$schema: http://devicetree.org/meta-schemas/core.yaml#
> > > > > +
> > > > > +title: Qualcomm QPS615 PCIe switch
> > > > > +
> > > > > +maintainers:
> > > > > +  - Krishna chaitanya chundru <quic_krichai@quicinc.com>
> > > > > +
> > > > > +description: |
> > > > > +  Qualcomm QPS615 PCIe switch has one upstream and three downstream
> > > > > +  ports. The 3rd downstream port has integrated endpoint device of
> > > > > +  Ethernet MAC. Other two downstream ports are supposed to connect
> > > > > +  to external device.
> > > > > +
> > > > > +  The QPS615 PCIe switch can be configured through I2C interface before
> > > > > +  PCIe link is established to change FTS, ASPM related entry delays,
> > > > > +  tx amplitude etc for better power efficiency and functionality.
> > > > > +
> > > > > +properties:
> > > > > +  compatible:
> > > > > +    enum:
> > > > > +      - pci1179,0623
> > > > > +
> > > > > +  reg:
> > > > > +    maxItems: 1
> > > > > +
> > > > > +  i2c-parent:
> > > > > +    $ref: /schemas/types.yaml#/definitions/phandle-array
> > > > > +    description: |
> > > > 
> > > > Don't need '|' if no formatting to preserve.
> > > > 
> > > ack
> > > > > +      A phandle to the parent I2C node and the slave address of the device
> > > > > +      used to do configure qps615 to change FTS, tx amplitude etc.
> > > > > +    items:
> > > > > +      - description: Phandle to the I2C controller node
> > > > > +      - description: I2C slave address
> > > > > +
> > > > > +  vdd18-supply: true
> > > > > +
> > > > > +  vdd09-supply: true
> > > > > +
> > > > > +  vddc-supply: true
> > > > > +
> > > > > +  vddio1-supply: true
> > > > > +
> > > > > +  vddio2-supply: true
> > > > > +
> > > > > +  vddio18-supply: true
> > > > > +
> > > > > +  reset-gpios:
> > > > > +    maxItems: 1
> > > > > +    description:
> > > > > +      GPIO controlling the RESX# pin.
> > > > 
> > > > Is the PERST# or something else?
> > > > 
> > > it is not PERST GPIO, it is similar to PERST in terms
> > > of functionality which brings switch out from reset.
> > 
> > Do you have an actual PERST# on upstream facing port? Is it a separate
> > wire? Judging by the RB3 Gen2 this line is being used as PERST#
> > 
> we had PERST# as a separate line. It has two inputs one is PERST# &
> other one is RESX# gpio functionality wise both are similar.

I don't think I follow. Are you describing the QPS615 side or the SoC side?

> > > > > +
> > > > > +  qps615,axi-clk-freq-hz:
> > > > 
> > > > qps615 is not a vendor prefix.
> > > > 
> > > > > +    description:
> > > > > +      AXI clock rate which is internal bus of the switch
> > > > > +      The switch only runs in two frequencies i.e 250MHz and 125MHz.
> > > > > +    enum: [125000000, 250000000]
> > > > > +
> > > > > +allOf:
> > > > > +  - $ref: "#/$defs/qps615-node"
> > > > > +
> > > > > +patternProperties:
> > > > > +  "@1?[0-9a-f](,[0-7])?$":
> > > > 
> > > > You have 3 ports. So isn't this fixed and limited to 0-2?
> > > > 
> > > sure I will change it to below as suggested
> > > "@1?[0-3](,[0-1])?$"
> > 
> > Why do you still need '1?' ?
> > 
> we want to represent integrated ethernet MAC also here and to represent it
> we need '1' as it is multi function device. I will update the
> description to reflect the same.

Note, I has asked about the '1?' part, not about the [0-1].

However as you've mentioned it, you are describing the first level
subnodes. Per your example, these subnodes are "pcie@1,0", "pcie@2,0"
and "pcie@3,0". Thus this patternProperties should have the regexp of
"^pcie@[1-3],0$". The multifunction devices for the ethernet node are
hidden under the pcie@3,0 and as such they are not being matched against
this regexp.

> > > > > +    description: child nodes describing the internal downstream ports
> > > > > +      the qps615 switch.
> > > > 
> > > > Please be consistent with starting after the ':' or on the next line.
> > > > 
> > > > And start with capital C.
> > > > 
> > > > 
> > > ack
> > > 
> > > > > +    type: object
> > > > > +    $ref: "#/$defs/qps615-node"
> > > > > +    unevaluatedProperties: false
> > > > > +
> > > > > +$defs:
> > > > > +  qps615-node:
> > > > > +    type: object
> > > > > +
> > > > > +    properties:
> > > > > +      qcom,l0s-entry-delay-ns:
> > > > > +        description: Aspm l0s entry delay.
> > > > > +
> > > > > +      qcom,l1-entry-delay-ns:
> > > > > +        description: Aspm l1 entry delay.
> > > > 
> > > > These should probably be common being standard PCIe things. Though, why
> > > > are they needed? I'm sure the timing is defined by the PCIe spec, so
> > > > they are not compliant?
> > > > 
> > > Usually the firmware in the endpoints/switches should do this these
> > > configurations. But the qps615 PCIe switch doesn't have any firmware
> > > running to configure these. So the hardware exposes i2c interface to
> > > configure these before link training.
> > 
> > If they are following the standard, why do you need to have them in the
> > DT? Can you hardcode thos evalues in the driver?
> > 
> These values can be changed from platform to platform based upon the
> different power goals and latency requirements so we can't have hard coded
> values.
> 
> And even DWC controllers also provide provision to change these values
> currently we are not using them. As bjorn suggested if we move these to
> common pcie bindings these can be used in future by controller drivers also.

Ack

> > > > > +
> > > > > +      qcom,tx-amplitude-millivolt:
> > > > > +        $ref: /schemas/types.yaml#/definitions/uint32
> > > > > +        description: Change Tx Margin setting for low power consumption.
> > > > > +
> > > > > +      qcom,no-dfe-support:
> > > > > +        type: boolean
> > > > > +        description: Disable DFE (Decision Feedback Equalizer), which mitigates
> > > > > +          intersymbol interference and some reflections caused by impedance mismatches.
> > > > > +
> > > > > +      qcom,nfts:
> > > > > +        $ref: /schemas/types.yaml#/definitions/uint32
> > > > > +        description:
> > > > > +          Number of Fast Training Sequence (FTS) used during L0s to L0 exit
> > > > > +          for bit and Symbol lock.
> > > > 
> > > > Also something common.
> > > > 
> > > > The problem I have with all these properties is you are using them on
> > > > both the upstream and downstream sides of the PCIe links. They belong in
> > > > either the device's node (downstream) or the bus's node (upstream).
> > > > 
> > > This switch allows us to configure both upstream, downstream ports and
> > > also embedded Ethernet port which is internal to the switch. These
> > > properties are applicable for all of those.
> > > > > +
> > > > > +    allOf:
> > > > > +      - $ref: /schemas/pci/pci-bus.yaml#
> > > > 
> > > > pci-pci-bridge.yaml is more specific and closer to what this device is.
> > > > 
> > > I tried this now, I was getting warning saying the compatible
> > > /local/mnt/workspace/skales/kobj/Documentation/devicetree/bindings/pci/qcom,qps615.example.dtb:
> > > pcie@0,0: compatible: ['pci1179,0623'] does not contain items matching the
> > > given schema
> > >          from schema $id: http://devicetree.org/schemas/pci/qcom,qps615.yaml#
> > > /local/mnt/workspace/skales/kobj/Documentation/devicetree/bindings/pci/qcom,qps615.example.dtb:
> > > pcie@0,0: Unevaluated properties are not allowed ('#address-cells',
> > > '#size-cells', 'bus-range', 'device_type', 'ranges' were unexpected)
> > > 
> > > I think pci-pci-bridge is expecting the compatible string in this format
> > > only "pciclass,0604".
> > 
> > I think the pci-pci-bridge schema requires to have "pciclass,0604" among
> > other compatibles. So you should be able to do something like:
> > 
> > compatible = "pci1179,0623", "pciclass,0604";
> > 
> > At least if follows PCI Bus Binding to Open Firmware document.
> > 
> let us try this and come back.
> > > 
> > > > > +
> > > > > +unevaluatedProperties: false
> > > > > +
> > > > > +required:
> > > > > +  - vdd18-supply
> > > > > +  - vdd09-supply
> > > > > +  - vddc-supply
> > > > > +  - vddio1-supply
> > > > > +  - vddio2-supply
> > > > > +  - vddio18-supply
> > > > > +  - i2c-parent
> > > > > +  - reset-gpios
> > > > > +
> > > > > +examples:
> > > > > +  - |
> > > > > +
> > > > > +    #include <dt-bindings/gpio/gpio.h>
> > > > > +
> > > > > +    pcie {
> > > > > +        #address-cells = <3>;
> > > > > +        #size-cells = <2>;
> > > > > +
> > > > > +        pcie@0 {
> > > > > +            device_type = "pci";
> > > > > +            reg = <0x0 0x0 0x0 0x0 0x0>;
> > > > > +
> > > > > +            #address-cells = <3>;
> > > > > +            #size-cells = <2>;
> > > > > +            ranges;
> > > > > +            bus-range = <0x01 0xff>;
> > > > > +
> > > > > +            pcie@0,0 {
> > > > > +                compatible = "pci1179,0623";
> > > > > +                reg = <0x10000 0x0 0x0 0x0 0x0>;
> > > > > +                device_type = "pci";
> > > > > +                #address-cells = <3>;
> > > > > +                #size-cells = <2>;
> > > > > +                ranges;
> > > > > +                bus-range = <0x02 0xff>;
> > > > > +
> > > > > +                i2c-parent = <&qup_i2c 0x77>;
> > > > > +
> > > > > +                vdd18-supply = <&vdd>;
> > > > > +                vdd09-supply = <&vdd>;
> > > > > +                vddc-supply = <&vdd>;
> > > > > +                vddio1-supply = <&vdd>;
> > > > > +                vddio2-supply = <&vdd>;
> > > > > +                vddio18-supply = <&vdd>;
> > > > > +
> > > > > +                reset-gpios = <&gpio 1 GPIO_ACTIVE_LOW>;
> > > > > +
> > > > > +                pcie@1,0 {
> > > > > +                    reg = <0x20800 0x0 0x0 0x0 0x0>;
> > > > > +                    #address-cells = <3>;
> > > > > +                    #size-cells = <2>;
> > > > > +                    device_type = "pci";
> > > > > +                    ranges;
> > > > > +                    bus-range = <0x03 0xff>;
> > > > > +
> > > > > +                    qcom,no-dfe-support;
> > > > > +                };
> > > > > +
> > > > > +                pcie@2,0 {
> > > > > +                    reg = <0x21000 0x0 0x0 0x0 0x0>;
> > > > > +                    #address-cells = <3>;
> > > > > +                    #size-cells = <2>;
> > > > > +                    device_type = "pci";
> > > > > +                    ranges;
> > > > > +                    bus-range = <0x04 0xff>;
> > > > > +
> > > > > +                    qcom,nfts = <10>;
> > > > > +                };
> > > > > +
> > > > > +                pcie@3,0 {
> > > > > +                    reg = <0x21800 0x0 0x0 0x0 0x0>;
> > > > > +                    #address-cells = <3>;
> > > > > +                    #size-cells = <2>;
> > > > > +                    device_type = "pci";
> > > > > +                    ranges;
> > > > > +                    bus-range = <0x05 0xff>;
> > > > > +
> > > > > +                    qcom,tx-amplitude-millivolt = <10>;
> > > > > +                    pcie@0,0 {
> > > > > +                        reg = <0x50000 0x0 0x0 0x0 0x0>;
> > > > > +                        #address-cells = <3>;
> > > > > +                        #size-cells = <2>;
> > > > > +                        device_type = "pci";
> > > > 
> > > > There's a 2nd PCI-PCI bridge?
> > > This the embedded ethernet port which is as part of DSP3.
> > 
> > So is there an adidtional bus for that ethernet device?
> > 
> yes for ethernet it has aditional bus assigned.
> 
> > > 
> > > - Krishna Chaitanya.
> > > > 
> > > > > +                        ranges;
> > > > > +
> > > > > +                        qcom,l1-entry-delay-ns = <10>;
> > > > > +                    };
> > > > > +
> > > > > +                    pcie@0,1 {
> > > > > +                        reg = <0x50100 0x0 0x0 0x0 0x0>;
> > > > > +                        #address-cells = <3>;
> > > > > +                        #size-cells = <2>;
> > > > > +                        device_type = "pci";
> > > > > +                        ranges;
> > > > > +
> > > > > +                        qcom,l0s-entry-delay-ns = <10>;
> > > > > +                    };
> > 
> > What is this?
> > 
> Ethernet endpoint is a multi function device which has 2 functions
> This node represents 2nd node. I will update the description to
> reflect the same.

If this is an ethernet device, why does it have a name of pcie@? Per
bindings the pcie@ name should be used only for devices with the class
0604. Whas is the PCI device class for those devices? I think ethernet@
(0200) should probably be the best fit, judgin by your description.

> 
> - Krishna Chaitanya.
> 
> > > > > +                };
> > > > > +            };
> > > > > +        };
> > > > > +    };
> > > > > 
> > > > > -- 
> > > > > 2.34.1
> > > > > 
> > 

-- 
With best wishes
Dmitry

Re: [PATCH v3 1/6] dt-bindings: PCI: Add binding for qps615

[Krishna Chaitanya Chundru]

On 12/24/2024 12:24 PM, Dmitry Baryshkov wrote:
> On Tue, Dec 24, 2024 at 11:34:10AM +0530, Krishna Chaitanya Chundru wrote:
>>
>>
>> On 12/24/2024 12:27 AM, Dmitry Baryshkov wrote:
>>> On Sun, Nov 24, 2024 at 07:02:48AM +0530, Krishna Chaitanya Chundru wrote:
>>>>
>>>>
>>>> On 11/15/2024 9:48 PM, Rob Herring wrote:
>>>>> On Tue, Nov 12, 2024 at 08:31:33PM +0530, Krishna chaitanya chundru wrote:
>>>>>> Add binding describing the Qualcomm PCIe switch, QPS615,
>>>>>> which provides Ethernet MAC integrated to the 3rd downstream port
>>>>>> and two downstream PCIe ports.
>>>>>>
>>>>>> Signed-off-by: Krishna chaitanya chundru <quic_krichai@quicinc.com>
>>>>>> ---
>>>>>>     .../devicetree/bindings/pci/qcom,qps615.yaml       | 205 +++++++++++++++++++++
>>>>>>     1 file changed, 205 insertions(+)
>>>>>>
>>>>>> diff --git a/Documentation/devicetree/bindings/pci/qcom,qps615.yaml b/Documentation/devicetree/bindings/pci/qcom,qps615.yaml
>>>>>> new file mode 100644
>>>>>> index 000000000000..e6a63a0bb0f3
>>>>>> --- /dev/null
>>>>>> +++ b/Documentation/devicetree/bindings/pci/qcom,qps615.yaml
>>>>>> @@ -0,0 +1,205 @@
>>>>>> +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
>>>>>> +%YAML 1.2
>>>>>> +---
>>>>>> +$id: http://devicetree.org/schemas/pci/qcom,qps615.yaml#
>>>>>> +$schema: http://devicetree.org/meta-schemas/core.yaml#
>>>>>> +
>>>>>> +title: Qualcomm QPS615 PCIe switch
>>>>>> +
>>>>>> +maintainers:
>>>>>> +  - Krishna chaitanya chundru <quic_krichai@quicinc.com>
>>>>>> +
>>>>>> +description: |
>>>>>> +  Qualcomm QPS615 PCIe switch has one upstream and three downstream
>>>>>> +  ports. The 3rd downstream port has integrated endpoint device of
>>>>>> +  Ethernet MAC. Other two downstream ports are supposed to connect
>>>>>> +  to external device.
>>>>>> +
>>>>>> +  The QPS615 PCIe switch can be configured through I2C interface before
>>>>>> +  PCIe link is established to change FTS, ASPM related entry delays,
>>>>>> +  tx amplitude etc for better power efficiency and functionality.
>>>>>> +
>>>>>> +properties:
>>>>>> +  compatible:
>>>>>> +    enum:
>>>>>> +      - pci1179,0623
>>>>>> +
>>>>>> +  reg:
>>>>>> +    maxItems: 1
>>>>>> +
>>>>>> +  i2c-parent:
>>>>>> +    $ref: /schemas/types.yaml#/definitions/phandle-array
>>>>>> +    description: |
>>>>>
>>>>> Don't need '|' if no formatting to preserve.
>>>>>
>>>> ack
>>>>>> +      A phandle to the parent I2C node and the slave address of the device
>>>>>> +      used to do configure qps615 to change FTS, tx amplitude etc.
>>>>>> +    items:
>>>>>> +      - description: Phandle to the I2C controller node
>>>>>> +      - description: I2C slave address
>>>>>> +
>>>>>> +  vdd18-supply: true
>>>>>> +
>>>>>> +  vdd09-supply: true
>>>>>> +
>>>>>> +  vddc-supply: true
>>>>>> +
>>>>>> +  vddio1-supply: true
>>>>>> +
>>>>>> +  vddio2-supply: true
>>>>>> +
>>>>>> +  vddio18-supply: true
>>>>>> +
>>>>>> +  reset-gpios:
>>>>>> +    maxItems: 1
>>>>>> +    description:
>>>>>> +      GPIO controlling the RESX# pin.
>>>>>
>>>>> Is the PERST# or something else?
>>>>>
>>>> it is not PERST GPIO, it is similar to PERST in terms
>>>> of functionality which brings switch out from reset.
>>>
>>> Do you have an actual PERST# on upstream facing port? Is it a separate
>>> wire? Judging by the RB3 Gen2 this line is being used as PERST#
>>>
>> we had PERST# as a separate line. It has two inputs one is PERST# &
>> other one is RESX# gpio functionality wise both are similar.
> 
> I don't think I follow. Are you describing the QPS615 side or the SoC side?
> 
These are QPS615 side. it has both PERST# as per PCIe spec and RESX# 
which belongs to only qps615 to bring out of reset. There are two 
different GPIO lines.
>>>>>> +
>>>>>> +  qps615,axi-clk-freq-hz:
>>>>>
>>>>> qps615 is not a vendor prefix.
>>>>>
>>>>>> +    description:
>>>>>> +      AXI clock rate which is internal bus of the switch
>>>>>> +      The switch only runs in two frequencies i.e 250MHz and 125MHz.
>>>>>> +    enum: [125000000, 250000000]
>>>>>> +
>>>>>> +allOf:
>>>>>> +  - $ref: "#/$defs/qps615-node"
>>>>>> +
>>>>>> +patternProperties:
>>>>>> +  "@1?[0-9a-f](,[0-7])?$":
>>>>>
>>>>> You have 3 ports. So isn't this fixed and limited to 0-2?
>>>>>
>>>> sure I will change it to below as suggested
>>>> "@1?[0-3](,[0-1])?$"
>>>
>>> Why do you still need '1?' ?
>>>
>> we want to represent integrated ethernet MAC also here and to represent it
>> we need '1' as it is multi function device. I will update the
>> description to reflect the same.
> 
> Note, I has asked about the '1?' part, not about the [0-1].
> 
> However as you've mentioned it, you are describing the first level
> subnodes. Per your example, these subnodes are "pcie@1,0", "pcie@2,0"
> and "pcie@3,0". Thus this patternProperties should have the regexp of
> "^pcie@[1-3],0$". The multifunction devices for the ethernet node are
> hidden under the pcie@3,0 and as such they are not being matched against
> this regexp.
> 
ack. I will use as the suggested one.
>>>>>> +    description: child nodes describing the internal downstream ports
>>>>>> +      the qps615 switch.
>>>>>
>>>>> Please be consistent with starting after the ':' or on the next line.
>>>>>
>>>>> And start with capital C.
>>>>>
>>>>>
>>>> ack
>>>>
>>>>>> +    type: object
>>>>>> +    $ref: "#/$defs/qps615-node"
>>>>>> +    unevaluatedProperties: false
>>>>>> +
>>>>>> +$defs:
>>>>>> +  qps615-node:
>>>>>> +    type: object
>>>>>> +
>>>>>> +    properties:
>>>>>> +      qcom,l0s-entry-delay-ns:
>>>>>> +        description: Aspm l0s entry delay.
>>>>>> +
>>>>>> +      qcom,l1-entry-delay-ns:
>>>>>> +        description: Aspm l1 entry delay.
>>>>>
>>>>> These should probably be common being standard PCIe things. Though, why
>>>>> are they needed? I'm sure the timing is defined by the PCIe spec, so
>>>>> they are not compliant?
>>>>>
>>>> Usually the firmware in the endpoints/switches should do this these
>>>> configurations. But the qps615 PCIe switch doesn't have any firmware
>>>> running to configure these. So the hardware exposes i2c interface to
>>>> configure these before link training.
>>>
>>> If they are following the standard, why do you need to have them in the
>>> DT? Can you hardcode thos evalues in the driver?
>>>
>> These values can be changed from platform to platform based upon the
>> different power goals and latency requirements so we can't have hard coded
>> values.
>>
>> And even DWC controllers also provide provision to change these values
>> currently we are not using them. As bjorn suggested if we move these to
>> common pcie bindings these can be used in future by controller drivers also.
> 
> Ack
> 
>>>>>> +
>>>>>> +      qcom,tx-amplitude-millivolt:
>>>>>> +        $ref: /schemas/types.yaml#/definitions/uint32
>>>>>> +        description: Change Tx Margin setting for low power consumption.
>>>>>> +
>>>>>> +      qcom,no-dfe-support:
>>>>>> +        type: boolean
>>>>>> +        description: Disable DFE (Decision Feedback Equalizer), which mitigates
>>>>>> +          intersymbol interference and some reflections caused by impedance mismatches.
>>>>>> +
>>>>>> +      qcom,nfts:
>>>>>> +        $ref: /schemas/types.yaml#/definitions/uint32
>>>>>> +        description:
>>>>>> +          Number of Fast Training Sequence (FTS) used during L0s to L0 exit
>>>>>> +          for bit and Symbol lock.
>>>>>
>>>>> Also something common.
>>>>>
>>>>> The problem I have with all these properties is you are using them on
>>>>> both the upstream and downstream sides of the PCIe links. They belong in
>>>>> either the device's node (downstream) or the bus's node (upstream).
>>>>>
>>>> This switch allows us to configure both upstream, downstream ports and
>>>> also embedded Ethernet port which is internal to the switch. These
>>>> properties are applicable for all of those.
>>>>>> +
>>>>>> +    allOf:
>>>>>> +      - $ref: /schemas/pci/pci-bus.yaml#
>>>>>
>>>>> pci-pci-bridge.yaml is more specific and closer to what this device is.
>>>>>
>>>> I tried this now, I was getting warning saying the compatible
>>>> /local/mnt/workspace/skales/kobj/Documentation/devicetree/bindings/pci/qcom,qps615.example.dtb:
>>>> pcie@0,0: compatible: ['pci1179,0623'] does not contain items matching the
>>>> given schema
>>>>           from schema $id: http://devicetree.org/schemas/pci/qcom,qps615.yaml#
>>>> /local/mnt/workspace/skales/kobj/Documentation/devicetree/bindings/pci/qcom,qps615.example.dtb:
>>>> pcie@0,0: Unevaluated properties are not allowed ('#address-cells',
>>>> '#size-cells', 'bus-range', 'device_type', 'ranges' were unexpected)
>>>>
>>>> I think pci-pci-bridge is expecting the compatible string in this format
>>>> only "pciclass,0604".
>>>
>>> I think the pci-pci-bridge schema requires to have "pciclass,0604" among
>>> other compatibles. So you should be able to do something like:
>>>
>>> compatible = "pci1179,0623", "pciclass,0604";
>>>
>>> At least if follows PCI Bus Binding to Open Firmware document.
>>>
>> let us try this and come back.
>>>>
>>>>>> +
>>>>>> +unevaluatedProperties: false
>>>>>> +
>>>>>> +required:
>>>>>> +  - vdd18-supply
>>>>>> +  - vdd09-supply
>>>>>> +  - vddc-supply
>>>>>> +  - vddio1-supply
>>>>>> +  - vddio2-supply
>>>>>> +  - vddio18-supply
>>>>>> +  - i2c-parent
>>>>>> +  - reset-gpios
>>>>>> +
>>>>>> +examples:
>>>>>> +  - |
>>>>>> +
>>>>>> +    #include <dt-bindings/gpio/gpio.h>
>>>>>> +
>>>>>> +    pcie {
>>>>>> +        #address-cells = <3>;
>>>>>> +        #size-cells = <2>;
>>>>>> +
>>>>>> +        pcie@0 {
>>>>>> +            device_type = "pci";
>>>>>> +            reg = <0x0 0x0 0x0 0x0 0x0>;
>>>>>> +
>>>>>> +            #address-cells = <3>;
>>>>>> +            #size-cells = <2>;
>>>>>> +            ranges;
>>>>>> +            bus-range = <0x01 0xff>;
>>>>>> +
>>>>>> +            pcie@0,0 {
>>>>>> +                compatible = "pci1179,0623";
>>>>>> +                reg = <0x10000 0x0 0x0 0x0 0x0>;
>>>>>> +                device_type = "pci";
>>>>>> +                #address-cells = <3>;
>>>>>> +                #size-cells = <2>;
>>>>>> +                ranges;
>>>>>> +                bus-range = <0x02 0xff>;
>>>>>> +
>>>>>> +                i2c-parent = <&qup_i2c 0x77>;
>>>>>> +
>>>>>> +                vdd18-supply = <&vdd>;
>>>>>> +                vdd09-supply = <&vdd>;
>>>>>> +                vddc-supply = <&vdd>;
>>>>>> +                vddio1-supply = <&vdd>;
>>>>>> +                vddio2-supply = <&vdd>;
>>>>>> +                vddio18-supply = <&vdd>;
>>>>>> +
>>>>>> +                reset-gpios = <&gpio 1 GPIO_ACTIVE_LOW>;
>>>>>> +
>>>>>> +                pcie@1,0 {
>>>>>> +                    reg = <0x20800 0x0 0x0 0x0 0x0>;
>>>>>> +                    #address-cells = <3>;
>>>>>> +                    #size-cells = <2>;
>>>>>> +                    device_type = "pci";
>>>>>> +                    ranges;
>>>>>> +                    bus-range = <0x03 0xff>;
>>>>>> +
>>>>>> +                    qcom,no-dfe-support;
>>>>>> +                };
>>>>>> +
>>>>>> +                pcie@2,0 {
>>>>>> +                    reg = <0x21000 0x0 0x0 0x0 0x0>;
>>>>>> +                    #address-cells = <3>;
>>>>>> +                    #size-cells = <2>;
>>>>>> +                    device_type = "pci";
>>>>>> +                    ranges;
>>>>>> +                    bus-range = <0x04 0xff>;
>>>>>> +
>>>>>> +                    qcom,nfts = <10>;
>>>>>> +                };
>>>>>> +
>>>>>> +                pcie@3,0 {
>>>>>> +                    reg = <0x21800 0x0 0x0 0x0 0x0>;
>>>>>> +                    #address-cells = <3>;
>>>>>> +                    #size-cells = <2>;
>>>>>> +                    device_type = "pci";
>>>>>> +                    ranges;
>>>>>> +                    bus-range = <0x05 0xff>;
>>>>>> +
>>>>>> +                    qcom,tx-amplitude-millivolt = <10>;
>>>>>> +                    pcie@0,0 {
>>>>>> +                        reg = <0x50000 0x0 0x0 0x0 0x0>;
>>>>>> +                        #address-cells = <3>;
>>>>>> +                        #size-cells = <2>;
>>>>>> +                        device_type = "pci";
>>>>>
>>>>> There's a 2nd PCI-PCI bridge?
>>>> This the embedded ethernet port which is as part of DSP3.
>>>
>>> So is there an adidtional bus for that ethernet device?
>>>
>> yes for ethernet it has aditional bus assigned.
>>
>>>>
>>>> - Krishna Chaitanya.
>>>>>
>>>>>> +                        ranges;
>>>>>> +
>>>>>> +                        qcom,l1-entry-delay-ns = <10>;
>>>>>> +                    };
>>>>>> +
>>>>>> +                    pcie@0,1 {
>>>>>> +                        reg = <0x50100 0x0 0x0 0x0 0x0>;
>>>>>> +                        #address-cells = <3>;
>>>>>> +                        #size-cells = <2>;
>>>>>> +                        device_type = "pci";
>>>>>> +                        ranges;
>>>>>> +
>>>>>> +                        qcom,l0s-entry-delay-ns = <10>;
>>>>>> +                    };
>>>
>>> What is this?
>>>
>> Ethernet endpoint is a multi function device which has 2 functions
>> This node represents 2nd node. I will update the description to
>> reflect the same.
> 
> If this is an ethernet device, why does it have a name of pcie@? Per
> bindings the pcie@ name should be used only for devices with the class
> 0604. Whas is the PCI device class for those devices? I think ethernet@
> (0200) should probably be the best fit, judgin by your description.
> 
These are PCIe Ethernet endpoints with base class 2 & subclass 2, I 
taught all the PCIe devices should start with pcie irrespective of the 
class, can you point us the binding you are referring to. I was 
referring to this 
https://github.com/devicetree-org/dt-schema/blob/main/dtschema/schemas/pci/pci-device.yaml#L23

As this is a endpoint device, I will cross check once if we can 
represent here or not and get back on this.

- Krishna Chaitanya.
>>
>> - Krishna Chaitanya.
>>
>>>>>> +                };
>>>>>> +            };
>>>>>> +        };
>>>>>> +    };
>>>>>>
>>>>>> -- 
>>>>>> 2.34.1
>>>>>>
>>>
> 

Re: [PATCH v3 1/6] dt-bindings: PCI: Add binding for qps615

[Krishna Chaitanya Chundru]

On 12/5/2024 2:55 AM, Bjorn Helgaas wrote:
> On Tue, Nov 12, 2024 at 08:31:33PM +0530, Krishna chaitanya chundru wrote:
>> Add binding describing the Qualcomm PCIe switch, QPS615,
>> which provides Ethernet MAC integrated to the 3rd downstream port
>> and two downstream PCIe ports.
> 
>> +$defs:
>> +  qps615-node:
>> +    type: object
>> +
>> +    properties:
>> +      qcom,l0s-entry-delay-ns:
>> +        description: Aspm l0s entry delay.
>> +
>> +      qcom,l1-entry-delay-ns:
>> +        description: Aspm l1 entry delay.
> 
> To match spec usage:
> s/Aspm/ASPM/
> s/l0s/L0s/
> s/l1/L1/
> 
> Other than the fact that qps615 needs the driver to configure these,
> there's nothing qcom-specific here, so I suggest the names should omit
> "qcom" and include "aspm".
> 
>> +    pcie {
>> +        #address-cells = <3>;
>> +        #size-cells = <2>;
>> +
>> +        pcie@0 {
>> +            device_type = "pci";
>> +            reg = <0x0 0x0 0x0 0x0 0x0>;
>> +
>> +            #address-cells = <3>;
>> +            #size-cells = <2>;
>> +            ranges;
>> +            bus-range = <0x01 0xff>;
>> +
>> +            pcie@0,0 {
>> +                compatible = "pci1179,0623";
>> +                reg = <0x10000 0x0 0x0 0x0 0x0>;
>> +                device_type = "pci";
>> +                #address-cells = <3>;
>> +                #size-cells = <2>;
>> +                ranges;
>> +                bus-range = <0x02 0xff>;
> 
> This binding describes a switch.  I don't think bus-range should
> appear here at all because it is not a feature of the hardware (unless
> the switch ports are broken and their Secondary/Subordinate Bus
> Numbers are hard-wired).
> 
> The Primary/Secondary/Subordinate Bus Numbers of all switch ports
> should be writable and the PCI core knows how to manage them.
> 
Bjorn,

The dt binding check is throwing an error if we don't keep bus-range
property for that reason we added it, from dt binding perspective i 
think it is mandatory to add this property.

- Krishna Chaitanya.
> Bjorn

Re: [PATCH v3 1/6] dt-bindings: PCI: Add binding for qps615

[Dmitry Baryshkov]

On Tue, Dec 24, 2024 at 02:39:17PM +0530, Krishna Chaitanya Chundru wrote:
> 
> 
> On 12/24/2024 12:24 PM, Dmitry Baryshkov wrote:
> > On Tue, Dec 24, 2024 at 11:34:10AM +0530, Krishna Chaitanya Chundru wrote:
> > > 
> > > 
> > > On 12/24/2024 12:27 AM, Dmitry Baryshkov wrote:
> > > > On Sun, Nov 24, 2024 at 07:02:48AM +0530, Krishna Chaitanya Chundru wrote:
> > > > > 
> > > > > 
> > > > > On 11/15/2024 9:48 PM, Rob Herring wrote:
> > > > > > On Tue, Nov 12, 2024 at 08:31:33PM +0530, Krishna chaitanya chundru wrote:
> > > > > > > Add binding describing the Qualcomm PCIe switch, QPS615,
> > > > > > > which provides Ethernet MAC integrated to the 3rd downstream port
> > > > > > > and two downstream PCIe ports.
> > > > > > > 
> > > > > > > Signed-off-by: Krishna chaitanya chundru <quic_krichai@quicinc.com>
> > > > > > > ---
> > > > > > >     .../devicetree/bindings/pci/qcom,qps615.yaml       | 205 +++++++++++++++++++++
> > > > > > >     1 file changed, 205 insertions(+)
> > > > > > > 
> > > > > > > diff --git a/Documentation/devicetree/bindings/pci/qcom,qps615.yaml b/Documentation/devicetree/bindings/pci/qcom,qps615.yaml
> > > > > > > new file mode 100644
> > > > > > > index 000000000000..e6a63a0bb0f3
> > > > > > > --- /dev/null
> > > > > > > +++ b/Documentation/devicetree/bindings/pci/qcom,qps615.yaml
> > > > > > > @@ -0,0 +1,205 @@
> > > > > > > +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
> > > > > > > +%YAML 1.2
> > > > > > > +---
> > > > > > > +$id: http://devicetree.org/schemas/pci/qcom,qps615.yaml#
> > > > > > > +$schema: http://devicetree.org/meta-schemas/core.yaml#
> > > > > > > +
> > > > > > > +title: Qualcomm QPS615 PCIe switch
> > > > > > > +
> > > > > > > +maintainers:
> > > > > > > +  - Krishna chaitanya chundru <quic_krichai@quicinc.com>
> > > > > > > +
> > > > > > > +description: |
> > > > > > > +  Qualcomm QPS615 PCIe switch has one upstream and three downstream
> > > > > > > +  ports. The 3rd downstream port has integrated endpoint device of
> > > > > > > +  Ethernet MAC. Other two downstream ports are supposed to connect
> > > > > > > +  to external device.
> > > > > > > +
> > > > > > > +  The QPS615 PCIe switch can be configured through I2C interface before
> > > > > > > +  PCIe link is established to change FTS, ASPM related entry delays,
> > > > > > > +  tx amplitude etc for better power efficiency and functionality.
> > > > > > > +
> > > > > > > +properties:
> > > > > > > +  compatible:
> > > > > > > +    enum:
> > > > > > > +      - pci1179,0623
> > > > > > > +
> > > > > > > +  reg:
> > > > > > > +    maxItems: 1
> > > > > > > +
> > > > > > > +  i2c-parent:
> > > > > > > +    $ref: /schemas/types.yaml#/definitions/phandle-array
> > > > > > > +    description: |
> > > > > > 
> > > > > > Don't need '|' if no formatting to preserve.
> > > > > > 
> > > > > ack
> > > > > > > +      A phandle to the parent I2C node and the slave address of the device
> > > > > > > +      used to do configure qps615 to change FTS, tx amplitude etc.
> > > > > > > +    items:
> > > > > > > +      - description: Phandle to the I2C controller node
> > > > > > > +      - description: I2C slave address
> > > > > > > +
> > > > > > > +  vdd18-supply: true
> > > > > > > +
> > > > > > > +  vdd09-supply: true
> > > > > > > +
> > > > > > > +  vddc-supply: true
> > > > > > > +
> > > > > > > +  vddio1-supply: true
> > > > > > > +
> > > > > > > +  vddio2-supply: true
> > > > > > > +
> > > > > > > +  vddio18-supply: true
> > > > > > > +
> > > > > > > +  reset-gpios:
> > > > > > > +    maxItems: 1
> > > > > > > +    description:
> > > > > > > +      GPIO controlling the RESX# pin.
> > > > > > 
> > > > > > Is the PERST# or something else?
> > > > > > 
> > > > > it is not PERST GPIO, it is similar to PERST in terms
> > > > > of functionality which brings switch out from reset.
> > > > 
> > > > Do you have an actual PERST# on upstream facing port? Is it a separate
> > > > wire? Judging by the RB3 Gen2 this line is being used as PERST#
> > > > 
> > > we had PERST# as a separate line. It has two inputs one is PERST# &
> > > other one is RESX# gpio functionality wise both are similar.
> > 
> > I don't think I follow. Are you describing the QPS615 side or the SoC side?
> > 
> These are QPS615 side. it has both PERST# as per PCIe spec and RESX# which
> belongs to only qps615 to bring out of reset. There are two different GPIO
> lines.

Hmm, okay. I indeed see two pins, PCIE_RESET_N and RESX. PCIE_RESET_N is
described as "Reset for PCIe block", while RESX is "System reset input".
RESX should be lifted before PCIE_RESET_N during QPS615 power on.
If I understand correctly, the reset-gpios is a RESX pin, which is
controlled manually by the QPS driver. Is PERST# controlled by the DWC3
driver or by the DWC3 controller itself?

> > > > > > > +
> > > > > > > +  qps615,axi-clk-freq-hz:
> > > > > > 
> > > > > > qps615 is not a vendor prefix.
> > > > > > 
> > > > > > > +    description:
> > > > > > > +      AXI clock rate which is internal bus of the switch
> > > > > > > +      The switch only runs in two frequencies i.e 250MHz and 125MHz.
> > > > > > > +    enum: [125000000, 250000000]
> > > > > > > +
> > > > > > > +allOf:
> > > > > > > +  - $ref: "#/$defs/qps615-node"
> > > > > > > +
> > > > > > > +patternProperties:
> > > > > > > +  "@1?[0-9a-f](,[0-7])?$":
> > > > > > 
> > > > > > You have 3 ports. So isn't this fixed and limited to 0-2?
> > > > > > 
> > > > > sure I will change it to below as suggested
> > > > > "@1?[0-3](,[0-1])?$"
> > > > 
> > > > Why do you still need '1?' ?
> > > > 
> > > we want to represent integrated ethernet MAC also here and to represent it
> > > we need '1' as it is multi function device. I will update the
> > > description to reflect the same.
> > 
> > Note, I has asked about the '1?' part, not about the [0-1].
> > 
> > However as you've mentioned it, you are describing the first level
> > subnodes. Per your example, these subnodes are "pcie@1,0", "pcie@2,0"
> > and "pcie@3,0". Thus this patternProperties should have the regexp of
> > "^pcie@[1-3],0$". The multifunction devices for the ethernet node are
> > hidden under the pcie@3,0 and as such they are not being matched against
> > this regexp.
> > 
> ack. I will use as the suggested one.
> > > > > > > +    description: child nodes describing the internal downstream ports
> > > > > > > +      the qps615 switch.
> > > > > > 
> > > > > > Please be consistent with starting after the ':' or on the next line.
> > > > > > 
> > > > > > And start with capital C.
> > > > > > 
> > > > > > 
> > > > > ack
> > > > > 
> > > > > > > +    type: object
> > > > > > > +    $ref: "#/$defs/qps615-node"
> > > > > > > +    unevaluatedProperties: false
> > > > > > > +
> > > > > > > +$defs:
> > > > > > > +  qps615-node:
> > > > > > > +    type: object
> > > > > > > +
> > > > > > > +    properties:
> > > > > > > +      qcom,l0s-entry-delay-ns:
> > > > > > > +        description: Aspm l0s entry delay.
> > > > > > > +
> > > > > > > +      qcom,l1-entry-delay-ns:
> > > > > > > +        description: Aspm l1 entry delay.
> > > > > > 
> > > > > > These should probably be common being standard PCIe things. Though, why
> > > > > > are they needed? I'm sure the timing is defined by the PCIe spec, so
> > > > > > they are not compliant?
> > > > > > 
> > > > > Usually the firmware in the endpoints/switches should do this these
> > > > > configurations. But the qps615 PCIe switch doesn't have any firmware
> > > > > running to configure these. So the hardware exposes i2c interface to
> > > > > configure these before link training.
> > > > 
> > > > If they are following the standard, why do you need to have them in the
> > > > DT? Can you hardcode thos evalues in the driver?
> > > > 
> > > These values can be changed from platform to platform based upon the
> > > different power goals and latency requirements so we can't have hard coded
> > > values.
> > > 
> > > And even DWC controllers also provide provision to change these values
> > > currently we are not using them. As bjorn suggested if we move these to
> > > common pcie bindings these can be used in future by controller drivers also.
> > 
> > Ack
> > 
> > > > > > > +
> > > > > > > +      qcom,tx-amplitude-millivolt:
> > > > > > > +        $ref: /schemas/types.yaml#/definitions/uint32
> > > > > > > +        description: Change Tx Margin setting for low power consumption.
> > > > > > > +
> > > > > > > +      qcom,no-dfe-support:
> > > > > > > +        type: boolean
> > > > > > > +        description: Disable DFE (Decision Feedback Equalizer), which mitigates
> > > > > > > +          intersymbol interference and some reflections caused by impedance mismatches.
> > > > > > > +
> > > > > > > +      qcom,nfts:
> > > > > > > +        $ref: /schemas/types.yaml#/definitions/uint32
> > > > > > > +        description:
> > > > > > > +          Number of Fast Training Sequence (FTS) used during L0s to L0 exit
> > > > > > > +          for bit and Symbol lock.
> > > > > > 
> > > > > > Also something common.
> > > > > > 
> > > > > > The problem I have with all these properties is you are using them on
> > > > > > both the upstream and downstream sides of the PCIe links. They belong in
> > > > > > either the device's node (downstream) or the bus's node (upstream).
> > > > > > 
> > > > > This switch allows us to configure both upstream, downstream ports and
> > > > > also embedded Ethernet port which is internal to the switch. These
> > > > > properties are applicable for all of those.
> > > > > > > +
> > > > > > > +    allOf:
> > > > > > > +      - $ref: /schemas/pci/pci-bus.yaml#
> > > > > > 
> > > > > > pci-pci-bridge.yaml is more specific and closer to what this device is.
> > > > > > 
> > > > > I tried this now, I was getting warning saying the compatible
> > > > > /local/mnt/workspace/skales/kobj/Documentation/devicetree/bindings/pci/qcom,qps615.example.dtb:
> > > > > pcie@0,0: compatible: ['pci1179,0623'] does not contain items matching the
> > > > > given schema
> > > > >           from schema $id: http://devicetree.org/schemas/pci/qcom,qps615.yaml#
> > > > > /local/mnt/workspace/skales/kobj/Documentation/devicetree/bindings/pci/qcom,qps615.example.dtb:
> > > > > pcie@0,0: Unevaluated properties are not allowed ('#address-cells',
> > > > > '#size-cells', 'bus-range', 'device_type', 'ranges' were unexpected)
> > > > > 
> > > > > I think pci-pci-bridge is expecting the compatible string in this format
> > > > > only "pciclass,0604".
> > > > 
> > > > I think the pci-pci-bridge schema requires to have "pciclass,0604" among
> > > > other compatibles. So you should be able to do something like:
> > > > 
> > > > compatible = "pci1179,0623", "pciclass,0604";
> > > > 
> > > > At least if follows PCI Bus Binding to Open Firmware document.
> > > > 
> > > let us try this and come back.
> > > > > 
> > > > > > > +
> > > > > > > +unevaluatedProperties: false
> > > > > > > +
> > > > > > > +required:
> > > > > > > +  - vdd18-supply
> > > > > > > +  - vdd09-supply
> > > > > > > +  - vddc-supply
> > > > > > > +  - vddio1-supply
> > > > > > > +  - vddio2-supply
> > > > > > > +  - vddio18-supply
> > > > > > > +  - i2c-parent
> > > > > > > +  - reset-gpios
> > > > > > > +
> > > > > > > +examples:
> > > > > > > +  - |
> > > > > > > +
> > > > > > > +    #include <dt-bindings/gpio/gpio.h>
> > > > > > > +
> > > > > > > +    pcie {
> > > > > > > +        #address-cells = <3>;
> > > > > > > +        #size-cells = <2>;
> > > > > > > +
> > > > > > > +        pcie@0 {
> > > > > > > +            device_type = "pci";
> > > > > > > +            reg = <0x0 0x0 0x0 0x0 0x0>;
> > > > > > > +
> > > > > > > +            #address-cells = <3>;
> > > > > > > +            #size-cells = <2>;
> > > > > > > +            ranges;
> > > > > > > +            bus-range = <0x01 0xff>;
> > > > > > > +
> > > > > > > +            pcie@0,0 {
> > > > > > > +                compatible = "pci1179,0623";
> > > > > > > +                reg = <0x10000 0x0 0x0 0x0 0x0>;
> > > > > > > +                device_type = "pci";
> > > > > > > +                #address-cells = <3>;
> > > > > > > +                #size-cells = <2>;
> > > > > > > +                ranges;
> > > > > > > +                bus-range = <0x02 0xff>;
> > > > > > > +
> > > > > > > +                i2c-parent = <&qup_i2c 0x77>;
> > > > > > > +
> > > > > > > +                vdd18-supply = <&vdd>;
> > > > > > > +                vdd09-supply = <&vdd>;
> > > > > > > +                vddc-supply = <&vdd>;
> > > > > > > +                vddio1-supply = <&vdd>;
> > > > > > > +                vddio2-supply = <&vdd>;
> > > > > > > +                vddio18-supply = <&vdd>;
> > > > > > > +
> > > > > > > +                reset-gpios = <&gpio 1 GPIO_ACTIVE_LOW>;
> > > > > > > +
> > > > > > > +                pcie@1,0 {
> > > > > > > +                    reg = <0x20800 0x0 0x0 0x0 0x0>;
> > > > > > > +                    #address-cells = <3>;
> > > > > > > +                    #size-cells = <2>;
> > > > > > > +                    device_type = "pci";
> > > > > > > +                    ranges;
> > > > > > > +                    bus-range = <0x03 0xff>;
> > > > > > > +
> > > > > > > +                    qcom,no-dfe-support;
> > > > > > > +                };
> > > > > > > +
> > > > > > > +                pcie@2,0 {
> > > > > > > +                    reg = <0x21000 0x0 0x0 0x0 0x0>;
> > > > > > > +                    #address-cells = <3>;
> > > > > > > +                    #size-cells = <2>;
> > > > > > > +                    device_type = "pci";
> > > > > > > +                    ranges;
> > > > > > > +                    bus-range = <0x04 0xff>;
> > > > > > > +
> > > > > > > +                    qcom,nfts = <10>;
> > > > > > > +                };
> > > > > > > +
> > > > > > > +                pcie@3,0 {
> > > > > > > +                    reg = <0x21800 0x0 0x0 0x0 0x0>;
> > > > > > > +                    #address-cells = <3>;
> > > > > > > +                    #size-cells = <2>;
> > > > > > > +                    device_type = "pci";
> > > > > > > +                    ranges;
> > > > > > > +                    bus-range = <0x05 0xff>;
> > > > > > > +
> > > > > > > +                    qcom,tx-amplitude-millivolt = <10>;
> > > > > > > +                    pcie@0,0 {
> > > > > > > +                        reg = <0x50000 0x0 0x0 0x0 0x0>;
> > > > > > > +                        #address-cells = <3>;
> > > > > > > +                        #size-cells = <2>;
> > > > > > > +                        device_type = "pci";
> > > > > > 
> > > > > > There's a 2nd PCI-PCI bridge?
> > > > > This the embedded ethernet port which is as part of DSP3.
> > > > 
> > > > So is there an adidtional bus for that ethernet device?
> > > > 
> > > yes for ethernet it has aditional bus assigned.
> > > 
> > > > > 
> > > > > - Krishna Chaitanya.
> > > > > > 
> > > > > > > +                        ranges;
> > > > > > > +
> > > > > > > +                        qcom,l1-entry-delay-ns = <10>;
> > > > > > > +                    };
> > > > > > > +
> > > > > > > +                    pcie@0,1 {
> > > > > > > +                        reg = <0x50100 0x0 0x0 0x0 0x0>;
> > > > > > > +                        #address-cells = <3>;
> > > > > > > +                        #size-cells = <2>;
> > > > > > > +                        device_type = "pci";
> > > > > > > +                        ranges;
> > > > > > > +
> > > > > > > +                        qcom,l0s-entry-delay-ns = <10>;
> > > > > > > +                    };
> > > > 
> > > > What is this?
> > > > 
> > > Ethernet endpoint is a multi function device which has 2 functions
> > > This node represents 2nd node. I will update the description to
> > > reflect the same.
> > 
> > If this is an ethernet device, why does it have a name of pcie@? Per
> > bindings the pcie@ name should be used only for devices with the class
> > 0604. Whas is the PCI device class for those devices? I think ethernet@
> > (0200) should probably be the best fit, judgin by your description.
> > 
> These are PCIe Ethernet endpoints with base class 2 & subclass 2, I taught

Hmm, 0x0202 is reserved for FDDI devices. Has somebody been
over-creative or is it me missing a part of the PCIe spec?

> all the PCIe devices should start with pcie irrespective of the class, can
> you point us the binding you are referring to. I was referring to this https://github.com/devicetree-org/dt-schema/blob/main/dtschema/schemas/pci/pci-device.yaml#L23

These bindings do not fix $nodename. A quick search through the existing
DTs should have provided you with the list of the endpoint device node
names as used by the kernel, which contains more than just pcie@N,M.

As for the spec, see [1], Table 1 on page 15. It defines node names for
various PCI classes.

[1] https://www.devicetree.org/open-firmware/bindings/pci/pci2_1.pdf

> 
> As this is a endpoint device, I will cross check once if we can represent
> here or not and get back on this.

Unless you have to configure those ports, you should be able to skip
them. From your DT example it is not clear which part is actually
configurable: pcie@3,0 or its subdevices: DT example contains extra
properties in all those nodes.

> 
> - Krishna Chaitanya.
> > > 
> > > - Krishna Chaitanya.
> > > 
> > > > > > > +                };
> > > > > > > +            };
> > > > > > > +        };
> > > > > > > +    };
> > > > > > > 
> > > > > > > -- 
> > > > > > > 2.34.1
> > > > > > > 
> > > > 
> > 

-- 
With best wishes
Dmitry

Re: [PATCH v3 1/6] dt-bindings: PCI: Add binding for qps615

[Dmitry Baryshkov]

On Tue, Dec 24, 2024 at 02:41:10PM +0530, Krishna Chaitanya Chundru wrote:
> 
> 
> On 12/5/2024 2:55 AM, Bjorn Helgaas wrote:
> > On Tue, Nov 12, 2024 at 08:31:33PM +0530, Krishna chaitanya chundru wrote:
> > > Add binding describing the Qualcomm PCIe switch, QPS615,
> > > which provides Ethernet MAC integrated to the 3rd downstream port
> > > and two downstream PCIe ports.
> > 
> > > +$defs:
> > > +  qps615-node:
> > > +    type: object
> > > +
> > > +    properties:
> > > +      qcom,l0s-entry-delay-ns:
> > > +        description: Aspm l0s entry delay.
> > > +
> > > +      qcom,l1-entry-delay-ns:
> > > +        description: Aspm l1 entry delay.
> > 
> > To match spec usage:
> > s/Aspm/ASPM/
> > s/l0s/L0s/
> > s/l1/L1/
> > 
> > Other than the fact that qps615 needs the driver to configure these,
> > there's nothing qcom-specific here, so I suggest the names should omit
> > "qcom" and include "aspm".
> > 
> > > +    pcie {
> > > +        #address-cells = <3>;
> > > +        #size-cells = <2>;
> > > +
> > > +        pcie@0 {
> > > +            device_type = "pci";
> > > +            reg = <0x0 0x0 0x0 0x0 0x0>;
> > > +
> > > +            #address-cells = <3>;
> > > +            #size-cells = <2>;
> > > +            ranges;
> > > +            bus-range = <0x01 0xff>;
> > > +
> > > +            pcie@0,0 {
> > > +                compatible = "pci1179,0623";
> > > +                reg = <0x10000 0x0 0x0 0x0 0x0>;
> > > +                device_type = "pci";
> > > +                #address-cells = <3>;
> > > +                #size-cells = <2>;
> > > +                ranges;
> > > +                bus-range = <0x02 0xff>;
> > 
> > This binding describes a switch.  I don't think bus-range should
> > appear here at all because it is not a feature of the hardware (unless
> > the switch ports are broken and their Secondary/Subordinate Bus
> > Numbers are hard-wired).
> > 
> > The Primary/Secondary/Subordinate Bus Numbers of all switch ports
> > should be writable and the PCI core knows how to manage them.
> > 
> Bjorn,
> 
> The dt binding check is throwing an error if we don't keep bus-range
> property for that reason we added it, from dt binding perspective i think it
> is mandatory to add this property.

Could you please provide an error message? I don't see any of the PCIe
bindingins declaring bus-range as mandatory. I might be missing it
though.

> 
> - Krishna Chaitanya.
> > Bjorn

-- 
With best wishes
Dmitry

Re: [PATCH v3 1/6] dt-bindings: PCI: Add binding for qps615

[Krishna Chaitanya Chundru]

On 12/24/2024 12:27 AM, Dmitry Baryshkov wrote:
> On Sun, Nov 24, 2024 at 07:02:48AM +0530, Krishna Chaitanya Chundru wrote:
>>
>>
>> On 11/15/2024 9:48 PM, Rob Herring wrote:
>>> On Tue, Nov 12, 2024 at 08:31:33PM +0530, Krishna chaitanya chundru wrote:
>>>> Add binding describing the Qualcomm PCIe switch, QPS615,
>>>> which provides Ethernet MAC integrated to the 3rd downstream port
>>>> and two downstream PCIe ports.
>>>>
>>>> Signed-off-by: Krishna chaitanya chundru <quic_krichai@quicinc.com>
>>>> ---
>>>>    .../devicetree/bindings/pci/qcom,qps615.yaml       | 205 +++++++++++++++++++++
>>>>    1 file changed, 205 insertions(+)
>>>>
>>>> diff --git a/Documentation/devicetree/bindings/pci/qcom,qps615.yaml b/Documentation/devicetree/bindings/pci/qcom,qps615.yaml
>>>> new file mode 100644
>>>> index 000000000000..e6a63a0bb0f3
>>>> --- /dev/null
>>>> +++ b/Documentation/devicetree/bindings/pci/qcom,qps615.yaml
>>>> @@ -0,0 +1,205 @@
>>>> +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
>>>> +%YAML 1.2
>>>> +---
>>>> +$id: http://devicetree.org/schemas/pci/qcom,qps615.yaml#
>>>> +$schema: http://devicetree.org/meta-schemas/core.yaml#
>>>> +
>>>> +title: Qualcomm QPS615 PCIe switch
>>>> +
>>>> +maintainers:
>>>> +  - Krishna chaitanya chundru <quic_krichai@quicinc.com>
>>>> +
>>>> +description: |
>>>> +  Qualcomm QPS615 PCIe switch has one upstream and three downstream
>>>> +  ports. The 3rd downstream port has integrated endpoint device of
>>>> +  Ethernet MAC. Other two downstream ports are supposed to connect
>>>> +  to external device.
>>>> +
>>>> +  The QPS615 PCIe switch can be configured through I2C interface before
>>>> +  PCIe link is established to change FTS, ASPM related entry delays,
>>>> +  tx amplitude etc for better power efficiency and functionality.
>>>> +
>>>> +properties:
>>>> +  compatible:
>>>> +    enum:
>>>> +      - pci1179,0623
>>>> +
>>>> +  reg:
>>>> +    maxItems: 1
>>>> +
>>>> +  i2c-parent:
>>>> +    $ref: /schemas/types.yaml#/definitions/phandle-array
>>>> +    description: |
>>>
>>> Don't need '|' if no formatting to preserve.
>>>
>> ack
>>>> +      A phandle to the parent I2C node and the slave address of the device
>>>> +      used to do configure qps615 to change FTS, tx amplitude etc.
>>>> +    items:
>>>> +      - description: Phandle to the I2C controller node
>>>> +      - description: I2C slave address
>>>> +
>>>> +  vdd18-supply: true
>>>> +
>>>> +  vdd09-supply: true
>>>> +
>>>> +  vddc-supply: true
>>>> +
>>>> +  vddio1-supply: true
>>>> +
>>>> +  vddio2-supply: true
>>>> +
>>>> +  vddio18-supply: true
>>>> +
>>>> +  reset-gpios:
>>>> +    maxItems: 1
>>>> +    description:
>>>> +      GPIO controlling the RESX# pin.
>>>
>>> Is the PERST# or something else?
>>>
>> it is not PERST GPIO, it is similar to PERST in terms
>> of functionality which brings switch out from reset.
> 
> Do you have an actual PERST# on upstream facing port? Is it a separate
> wire? Judging by the RB3 Gen2 this line is being used as PERST#
> 
>>>> +
>>>> +  qps615,axi-clk-freq-hz:
>>>
>>> qps615 is not a vendor prefix.
>>>
>>>> +    description:
>>>> +      AXI clock rate which is internal bus of the switch
>>>> +      The switch only runs in two frequencies i.e 250MHz and 125MHz.
>>>> +    enum: [125000000, 250000000]
>>>> +
>>>> +allOf:
>>>> +  - $ref: "#/$defs/qps615-node"
>>>> +
>>>> +patternProperties:
>>>> +  "@1?[0-9a-f](,[0-7])?$":
>>>
>>> You have 3 ports. So isn't this fixed and limited to 0-2?
>>>
>> sure I will change it to below as suggested
>> "@1?[0-3](,[0-1])?$"
> 
> Why do you still need '1?' ?
> 
>>>> +    description: child nodes describing the internal downstream ports
>>>> +      the qps615 switch.
>>>
>>> Please be consistent with starting after the ':' or on the next line.
>>>
>>> And start with capital C.
>>>
>>>
>> ack
>>
>>>> +    type: object
>>>> +    $ref: "#/$defs/qps615-node"
>>>> +    unevaluatedProperties: false
>>>> +
>>>> +$defs:
>>>> +  qps615-node:
>>>> +    type: object
>>>> +
>>>> +    properties:
>>>> +      qcom,l0s-entry-delay-ns:
>>>> +        description: Aspm l0s entry delay.
>>>> +
>>>> +      qcom,l1-entry-delay-ns:
>>>> +        description: Aspm l1 entry delay.
>>>
>>> These should probably be common being standard PCIe things. Though, why
>>> are they needed? I'm sure the timing is defined by the PCIe spec, so
>>> they are not compliant?
>>>
>> Usually the firmware in the endpoints/switches should do this these
>> configurations. But the qps615 PCIe switch doesn't have any firmware
>> running to configure these. So the hardware exposes i2c interface to
>> configure these before link training.
> 
> If they are following the standard, why do you need to have them in the
> DT? Can you hardcode thos evalues in the driver?
> 
>>>> +
>>>> +      qcom,tx-amplitude-millivolt:
>>>> +        $ref: /schemas/types.yaml#/definitions/uint32
>>>> +        description: Change Tx Margin setting for low power consumption.
>>>> +
>>>> +      qcom,no-dfe-support:
>>>> +        type: boolean
>>>> +        description: Disable DFE (Decision Feedback Equalizer), which mitigates
>>>> +          intersymbol interference and some reflections caused by impedance mismatches.
>>>> +
>>>> +      qcom,nfts:
>>>> +        $ref: /schemas/types.yaml#/definitions/uint32
>>>> +        description:
>>>> +          Number of Fast Training Sequence (FTS) used during L0s to L0 exit
>>>> +          for bit and Symbol lock.
>>>
>>> Also something common.
>>>
>>> The problem I have with all these properties is you are using them on
>>> both the upstream and downstream sides of the PCIe links. They belong in
>>> either the device's node (downstream) or the bus's node (upstream).
>>>
>> This switch allows us to configure both upstream, downstream ports and
>> also embedded Ethernet port which is internal to the switch. These
>> properties are applicable for all of those.
>>>> +
>>>> +    allOf:
>>>> +      - $ref: /schemas/pci/pci-bus.yaml#
>>>
>>> pci-pci-bridge.yaml is more specific and closer to what this device is.
>>>
>> I tried this now, I was getting warning saying the compatible
>> /local/mnt/workspace/skales/kobj/Documentation/devicetree/bindings/pci/qcom,qps615.example.dtb:
>> pcie@0,0: compatible: ['pci1179,0623'] does not contain items matching the
>> given schema
>>          from schema $id: http://devicetree.org/schemas/pci/qcom,qps615.yaml#
>> /local/mnt/workspace/skales/kobj/Documentation/devicetree/bindings/pci/qcom,qps615.example.dtb:
>> pcie@0,0: Unevaluated properties are not allowed ('#address-cells',
>> '#size-cells', 'bus-range', 'device_type', 'ranges' were unexpected)
>>
>> I think pci-pci-bridge is expecting the compatible string in this format
>> only "pciclass,0604".
> 
> I think the pci-pci-bridge schema requires to have "pciclass,0604" among
> other compatibles. So you should be able to do something like:
> 
> compatible = "pci1179,0623", "pciclass,0604";
> 
> At least if follows PCI Bus Binding to Open Firmware document.
> 
There is a slot driver which is using this pciclass,0604 can we use
still the suggested way.

https://lore.kernel.org/linux-pci/20241210-pci-pwrctrl-slot-v1-4-eae45e488040@linaro.org/

- Krishna Chaitanya.
>>
>>>> +
>>>> +unevaluatedProperties: false
>>>> +
>>>> +required:
>>>> +  - vdd18-supply
>>>> +  - vdd09-supply
>>>> +  - vddc-supply
>>>> +  - vddio1-supply
>>>> +  - vddio2-supply
>>>> +  - vddio18-supply
>>>> +  - i2c-parent
>>>> +  - reset-gpios
>>>> +
>>>> +examples:
>>>> +  - |
>>>> +
>>>> +    #include <dt-bindings/gpio/gpio.h>
>>>> +
>>>> +    pcie {
>>>> +        #address-cells = <3>;
>>>> +        #size-cells = <2>;
>>>> +
>>>> +        pcie@0 {
>>>> +            device_type = "pci";
>>>> +            reg = <0x0 0x0 0x0 0x0 0x0>;
>>>> +
>>>> +            #address-cells = <3>;
>>>> +            #size-cells = <2>;
>>>> +            ranges;
>>>> +            bus-range = <0x01 0xff>;
>>>> +
>>>> +            pcie@0,0 {
>>>> +                compatible = "pci1179,0623";
>>>> +                reg = <0x10000 0x0 0x0 0x0 0x0>;
>>>> +                device_type = "pci";
>>>> +                #address-cells = <3>;
>>>> +                #size-cells = <2>;
>>>> +                ranges;
>>>> +                bus-range = <0x02 0xff>;
>>>> +
>>>> +                i2c-parent = <&qup_i2c 0x77>;
>>>> +
>>>> +                vdd18-supply = <&vdd>;
>>>> +                vdd09-supply = <&vdd>;
>>>> +                vddc-supply = <&vdd>;
>>>> +                vddio1-supply = <&vdd>;
>>>> +                vddio2-supply = <&vdd>;
>>>> +                vddio18-supply = <&vdd>;
>>>> +
>>>> +                reset-gpios = <&gpio 1 GPIO_ACTIVE_LOW>;
>>>> +
>>>> +                pcie@1,0 {
>>>> +                    reg = <0x20800 0x0 0x0 0x0 0x0>;
>>>> +                    #address-cells = <3>;
>>>> +                    #size-cells = <2>;
>>>> +                    device_type = "pci";
>>>> +                    ranges;
>>>> +                    bus-range = <0x03 0xff>;
>>>> +
>>>> +                    qcom,no-dfe-support;
>>>> +                };
>>>> +
>>>> +                pcie@2,0 {
>>>> +                    reg = <0x21000 0x0 0x0 0x0 0x0>;
>>>> +                    #address-cells = <3>;
>>>> +                    #size-cells = <2>;
>>>> +                    device_type = "pci";
>>>> +                    ranges;
>>>> +                    bus-range = <0x04 0xff>;
>>>> +
>>>> +                    qcom,nfts = <10>;
>>>> +                };
>>>> +
>>>> +                pcie@3,0 {
>>>> +                    reg = <0x21800 0x0 0x0 0x0 0x0>;
>>>> +                    #address-cells = <3>;
>>>> +                    #size-cells = <2>;
>>>> +                    device_type = "pci";
>>>> +                    ranges;
>>>> +                    bus-range = <0x05 0xff>;
>>>> +
>>>> +                    qcom,tx-amplitude-millivolt = <10>;
>>>> +                    pcie@0,0 {
>>>> +                        reg = <0x50000 0x0 0x0 0x0 0x0>;
>>>> +                        #address-cells = <3>;
>>>> +                        #size-cells = <2>;
>>>> +                        device_type = "pci";
>>>
>>> There's a 2nd PCI-PCI bridge?
>> This the embedded ethernet port which is as part of DSP3.
> 
> So is there an adidtional bus for that ethernet device?
> 
>>
>> - Krishna Chaitanya.
>>>
>>>> +                        ranges;
>>>> +
>>>> +                        qcom,l1-entry-delay-ns = <10>;
>>>> +                    };
>>>> +
>>>> +                    pcie@0,1 {
>>>> +                        reg = <0x50100 0x0 0x0 0x0 0x0>;
>>>> +                        #address-cells = <3>;
>>>> +                        #size-cells = <2>;
>>>> +                        device_type = "pci";
>>>> +                        ranges;
>>>> +
>>>> +                        qcom,l0s-entry-delay-ns = <10>;
>>>> +                    };
> 
> What is this?
> 
>>>> +                };
>>>> +            };
>>>> +        };
>>>> +    };
>>>>
>>>> -- 
>>>> 2.34.1
>>>>
> 

Re: [PATCH v3 1/6] dt-bindings: PCI: Add binding for qps615

[Manivannan Sadhasivam]

On Mon, Dec 23, 2024 at 08:57:37PM +0200, Dmitry Baryshkov wrote:

[...]

> > This switch allows us to configure both upstream, downstream ports and
> > also embedded Ethernet port which is internal to the switch. These
> > properties are applicable for all of those.
> > > > +
> > > > +    allOf:
> > > > +      - $ref: /schemas/pci/pci-bus.yaml#
> > > 
> > > pci-pci-bridge.yaml is more specific and closer to what this device is.
> > > 
> > I tried this now, I was getting warning saying the compatible
> > /local/mnt/workspace/skales/kobj/Documentation/devicetree/bindings/pci/qcom,qps615.example.dtb:
> > pcie@0,0: compatible: ['pci1179,0623'] does not contain items matching the
> > given schema
> >         from schema $id: http://devicetree.org/schemas/pci/qcom,qps615.yaml#
> > /local/mnt/workspace/skales/kobj/Documentation/devicetree/bindings/pci/qcom,qps615.example.dtb:
> > pcie@0,0: Unevaluated properties are not allowed ('#address-cells',
> > '#size-cells', 'bus-range', 'device_type', 'ranges' were unexpected)
> > 
> > I think pci-pci-bridge is expecting the compatible string in this format
> > only "pciclass,0604".
> 
> I think the pci-pci-bridge schema requires to have "pciclass,0604" among
> other compatibles. So you should be able to do something like:
> 
> compatible = "pci1179,0623", "pciclass,0604";
> 

Even though a PCIe switch is supposed to be a network of PCI bridges, using
PCI bridge fallback for this switch is not technically correct IMO. Mostly
because, this switch requires other configurations which are not applicable to
PCI bridges. So the drivers matching against the bridge compatible won't be able
to use this switch.

- Mani

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

Re: [PATCH v3 1/6] dt-bindings: PCI: Add binding for qps615

[Dmitry Baryshkov]

On Fri, Dec 27, 2024 at 07:44:49AM +0530, Krishna Chaitanya Chundru wrote:
> 
> 
> On 12/24/2024 12:27 AM, Dmitry Baryshkov wrote:
> > On Sun, Nov 24, 2024 at 07:02:48AM +0530, Krishna Chaitanya Chundru wrote:
> > > 
> > > 
> > > On 11/15/2024 9:48 PM, Rob Herring wrote:
> > > > On Tue, Nov 12, 2024 at 08:31:33PM +0530, Krishna chaitanya chundru wrote:
> > > > > Add binding describing the Qualcomm PCIe switch, QPS615,
> > > > > which provides Ethernet MAC integrated to the 3rd downstream port
> > > > > and two downstream PCIe ports.
> > > > > 
> > > > > Signed-off-by: Krishna chaitanya chundru <quic_krichai@quicinc.com>
> > > > > ---
> > > > >    .../devicetree/bindings/pci/qcom,qps615.yaml       | 205 +++++++++++++++++++++
> > > > >    1 file changed, 205 insertions(+)
> > > > > 
> > > > > diff --git a/Documentation/devicetree/bindings/pci/qcom,qps615.yaml b/Documentation/devicetree/bindings/pci/qcom,qps615.yaml
> > > > > new file mode 100644
> > > > > index 000000000000..e6a63a0bb0f3
> > > > > --- /dev/null
> > > > > +++ b/Documentation/devicetree/bindings/pci/qcom,qps615.yaml
> > > > > @@ -0,0 +1,205 @@
> > > > > +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
> > > > > +%YAML 1.2
> > > > > +---
> > > > > +$id: http://devicetree.org/schemas/pci/qcom,qps615.yaml#
> > > > > +$schema: http://devicetree.org/meta-schemas/core.yaml#
> > > > > +
> > > > > +title: Qualcomm QPS615 PCIe switch
> > > > > +
> > > > > +maintainers:
> > > > > +  - Krishna chaitanya chundru <quic_krichai@quicinc.com>
> > > > > +
> > > > > +description: |
> > > > > +  Qualcomm QPS615 PCIe switch has one upstream and three downstream
> > > > > +  ports. The 3rd downstream port has integrated endpoint device of
> > > > > +  Ethernet MAC. Other two downstream ports are supposed to connect
> > > > > +  to external device.
> > > > > +
> > > > > +  The QPS615 PCIe switch can be configured through I2C interface before
> > > > > +  PCIe link is established to change FTS, ASPM related entry delays,
> > > > > +  tx amplitude etc for better power efficiency and functionality.
> > > > > +
> > > > > +properties:
> > > > > +  compatible:
> > > > > +    enum:
> > > > > +      - pci1179,0623
> > > > > +
> > > > > +  reg:
> > > > > +    maxItems: 1
> > > > > +
> > > > > +  i2c-parent:
> > > > > +    $ref: /schemas/types.yaml#/definitions/phandle-array
> > > > > +    description: |
> > > > 
> > > > Don't need '|' if no formatting to preserve.
> > > > 
> > > ack
> > > > > +      A phandle to the parent I2C node and the slave address of the device
> > > > > +      used to do configure qps615 to change FTS, tx amplitude etc.
> > > > > +    items:
> > > > > +      - description: Phandle to the I2C controller node
> > > > > +      - description: I2C slave address
> > > > > +
> > > > > +  vdd18-supply: true
> > > > > +
> > > > > +  vdd09-supply: true
> > > > > +
> > > > > +  vddc-supply: true
> > > > > +
> > > > > +  vddio1-supply: true
> > > > > +
> > > > > +  vddio2-supply: true
> > > > > +
> > > > > +  vddio18-supply: true
> > > > > +
> > > > > +  reset-gpios:
> > > > > +    maxItems: 1
> > > > > +    description:
> > > > > +      GPIO controlling the RESX# pin.
> > > > 
> > > > Is the PERST# or something else?
> > > > 
> > > it is not PERST GPIO, it is similar to PERST in terms
> > > of functionality which brings switch out from reset.
> > 
> > Do you have an actual PERST# on upstream facing port? Is it a separate
> > wire? Judging by the RB3 Gen2 this line is being used as PERST#
> > 
> > > > > +
> > > > > +  qps615,axi-clk-freq-hz:
> > > > 
> > > > qps615 is not a vendor prefix.
> > > > 
> > > > > +    description:
> > > > > +      AXI clock rate which is internal bus of the switch
> > > > > +      The switch only runs in two frequencies i.e 250MHz and 125MHz.
> > > > > +    enum: [125000000, 250000000]
> > > > > +
> > > > > +allOf:
> > > > > +  - $ref: "#/$defs/qps615-node"
> > > > > +
> > > > > +patternProperties:
> > > > > +  "@1?[0-9a-f](,[0-7])?$":
> > > > 
> > > > You have 3 ports. So isn't this fixed and limited to 0-2?
> > > > 
> > > sure I will change it to below as suggested
> > > "@1?[0-3](,[0-1])?$"
> > 
> > Why do you still need '1?' ?
> > 
> > > > > +    description: child nodes describing the internal downstream ports
> > > > > +      the qps615 switch.
> > > > 
> > > > Please be consistent with starting after the ':' or on the next line.
> > > > 
> > > > And start with capital C.
> > > > 
> > > > 
> > > ack
> > > 
> > > > > +    type: object
> > > > > +    $ref: "#/$defs/qps615-node"
> > > > > +    unevaluatedProperties: false
> > > > > +
> > > > > +$defs:
> > > > > +  qps615-node:
> > > > > +    type: object
> > > > > +
> > > > > +    properties:
> > > > > +      qcom,l0s-entry-delay-ns:
> > > > > +        description: Aspm l0s entry delay.
> > > > > +
> > > > > +      qcom,l1-entry-delay-ns:
> > > > > +        description: Aspm l1 entry delay.
> > > > 
> > > > These should probably be common being standard PCIe things. Though, why
> > > > are they needed? I'm sure the timing is defined by the PCIe spec, so
> > > > they are not compliant?
> > > > 
> > > Usually the firmware in the endpoints/switches should do this these
> > > configurations. But the qps615 PCIe switch doesn't have any firmware
> > > running to configure these. So the hardware exposes i2c interface to
> > > configure these before link training.
> > 
> > If they are following the standard, why do you need to have them in the
> > DT? Can you hardcode thos evalues in the driver?
> > 
> > > > > +
> > > > > +      qcom,tx-amplitude-millivolt:
> > > > > +        $ref: /schemas/types.yaml#/definitions/uint32
> > > > > +        description: Change Tx Margin setting for low power consumption.
> > > > > +
> > > > > +      qcom,no-dfe-support:
> > > > > +        type: boolean
> > > > > +        description: Disable DFE (Decision Feedback Equalizer), which mitigates
> > > > > +          intersymbol interference and some reflections caused by impedance mismatches.
> > > > > +
> > > > > +      qcom,nfts:
> > > > > +        $ref: /schemas/types.yaml#/definitions/uint32
> > > > > +        description:
> > > > > +          Number of Fast Training Sequence (FTS) used during L0s to L0 exit
> > > > > +          for bit and Symbol lock.
> > > > 
> > > > Also something common.
> > > > 
> > > > The problem I have with all these properties is you are using them on
> > > > both the upstream and downstream sides of the PCIe links. They belong in
> > > > either the device's node (downstream) or the bus's node (upstream).
> > > > 
> > > This switch allows us to configure both upstream, downstream ports and
> > > also embedded Ethernet port which is internal to the switch. These
> > > properties are applicable for all of those.
> > > > > +
> > > > > +    allOf:
> > > > > +      - $ref: /schemas/pci/pci-bus.yaml#
> > > > 
> > > > pci-pci-bridge.yaml is more specific and closer to what this device is.
> > > > 
> > > I tried this now, I was getting warning saying the compatible
> > > /local/mnt/workspace/skales/kobj/Documentation/devicetree/bindings/pci/qcom,qps615.example.dtb:
> > > pcie@0,0: compatible: ['pci1179,0623'] does not contain items matching the
> > > given schema
> > >          from schema $id: http://devicetree.org/schemas/pci/qcom,qps615.yaml#
> > > /local/mnt/workspace/skales/kobj/Documentation/devicetree/bindings/pci/qcom,qps615.example.dtb:
> > > pcie@0,0: Unevaluated properties are not allowed ('#address-cells',
> > > '#size-cells', 'bus-range', 'device_type', 'ranges' were unexpected)
> > > 
> > > I think pci-pci-bridge is expecting the compatible string in this format
> > > only "pciclass,0604".
> > 
> > I think the pci-pci-bridge schema requires to have "pciclass,0604" among
> > other compatibles. So you should be able to do something like:
> > 
> > compatible = "pci1179,0623", "pciclass,0604";
> > 
> > At least if follows PCI Bus Binding to Open Firmware document.
> > 
> There is a slot driver which is using this pciclass,0604 can we use
> still the suggested way.

The suggested way is to describe devices properly.

> 
> https://lore.kernel.org/linux-pci/20241210-pci-pwrctrl-slot-v1-4-eae45e488040@linaro.org/

-- 
With best wishes
Dmitry

Re: [PATCH v3 1/6] dt-bindings: PCI: Add binding for qps615

[Krishna Chaitanya Chundru]

On 12/30/2024 11:52 PM, Manivannan Sadhasivam wrote:
> On Mon, Dec 23, 2024 at 08:57:37PM +0200, Dmitry Baryshkov wrote:
> 
> [...]
> 
>>> This switch allows us to configure both upstream, downstream ports and
>>> also embedded Ethernet port which is internal to the switch. These
>>> properties are applicable for all of those.
>>>>> +
>>>>> +    allOf:
>>>>> +      - $ref: /schemas/pci/pci-bus.yaml#
>>>>
>>>> pci-pci-bridge.yaml is more specific and closer to what this device is.
>>>>
>>> I tried this now, I was getting warning saying the compatible
>>> /local/mnt/workspace/skales/kobj/Documentation/devicetree/bindings/pci/qcom,qps615.example.dtb:
>>> pcie@0,0: compatible: ['pci1179,0623'] does not contain items matching the
>>> given schema
>>>          from schema $id: http://devicetree.org/schemas/pci/qcom,qps615.yaml#
>>> /local/mnt/workspace/skales/kobj/Documentation/devicetree/bindings/pci/qcom,qps615.example.dtb:
>>> pcie@0,0: Unevaluated properties are not allowed ('#address-cells',
>>> '#size-cells', 'bus-range', 'device_type', 'ranges' were unexpected)
>>>
>>> I think pci-pci-bridge is expecting the compatible string in this format
>>> only "pciclass,0604".
>>
>> I think the pci-pci-bridge schema requires to have "pciclass,0604" among
>> other compatibles. So you should be able to do something like:
>>
>> compatible = "pci1179,0623", "pciclass,0604";
>>
> 
> Even though a PCIe switch is supposed to be a network of PCI bridges, using
> PCI bridge fallback for this switch is not technically correct IMO. Mostly
> because, this switch requires other configurations which are not applicable to
> PCI bridges. So the drivers matching against the bridge compatible won't be able
> to use this switch.
> 
> - Mani
Rob,

Using pci-pci-bridge expects to use compatible as pciclass,0604, we
can't  use as this switch is doing other configurations which are
applicable to PCI bridges. can we continue to use pci-bus.yaml.

- Krishna Chaitanya.
> 

Re: [PATCH v3 1/6] dt-bindings: PCI: Add binding for qps615

[Bjorn Helgaas]

On Tue, Dec 24, 2024 at 11:49:42AM +0200, Dmitry Baryshkov wrote:
> On Tue, Dec 24, 2024 at 02:41:10PM +0530, Krishna Chaitanya Chundru wrote:
> > On 12/5/2024 2:55 AM, Bjorn Helgaas wrote:
> > > On Tue, Nov 12, 2024 at 08:31:33PM +0530, Krishna chaitanya chundru wrote:
> > > > Add binding describing the Qualcomm PCIe switch, QPS615,
> > > > which provides Ethernet MAC integrated to the 3rd downstream port
> > > > and two downstream PCIe ports.

> > > > +    pcie {
> > > > +        #address-cells = <3>;
> > > > +        #size-cells = <2>;
> > > > +
> > > > +        pcie@0 {
> > > > +            device_type = "pci";
> > > > +            reg = <0x0 0x0 0x0 0x0 0x0>;
> > > > +
> > > > +            #address-cells = <3>;
> > > > +            #size-cells = <2>;
> > > > +            ranges;
> > > > +            bus-range = <0x01 0xff>;
> > > > +
> > > > +            pcie@0,0 {
> > > > +                compatible = "pci1179,0623";
> > > > +                reg = <0x10000 0x0 0x0 0x0 0x0>;
> > > > +                device_type = "pci";
> > > > +                #address-cells = <3>;
> > > > +                #size-cells = <2>;
> > > > +                ranges;
> > > > +                bus-range = <0x02 0xff>;
> > > 
> > > This binding describes a switch.  I don't think bus-range should
> > > appear here at all because it is not a feature of the hardware (unless
> > > the switch ports are broken and their Secondary/Subordinate Bus
> > > Numbers are hard-wired).
> > > 
> > > The Primary/Secondary/Subordinate Bus Numbers of all switch ports
> > > should be writable and the PCI core knows how to manage them.
> > 
> > The dt binding check is throwing an error if we don't keep bus-range
> > property for that reason we added it, from dt binding perspective i think it
> > is mandatory to add this property.
> 
> Could you please provide an error message? I don't see any of the PCIe
> bindingins declaring bus-range as mandatory. I might be missing it
> though.

I think the warning message is like this:

  Warning (pci_device_bus_num): /soc@0/pcie@1c00000/pcie@0/wifi@0: PCI bus number 1 out of range, expected (0 - 0)

and only happens if there's a device below a Root Port or a Switch.
In that case the device "reg" property apparently has to include the
bus/device/function.

IIUC, in this case, we're describing a Switch with an integrated
Ethernet MAC:

  pcie@0 {
    device_type = "pci";
    reg = <0x0 0x0 0x0 0x0 0x0>;           # 00:00.0 RP to [bus 01-ff]
    bus-range = <0x01 0xff>;

    pcie@0,0 {
      compatible = "pci1179,0623";
      reg = <0x10000 0x0 0x0 0x0 0x0>;     # 01:00.0 Switch USP to [bus 02-ff]
      device_type = "pci";
      bus-range = <0x02 0xff>;

      pcie@1,0 {
        reg = <0x20800 0x0 0x0 0x0 0x0>;   # 02:01.0 Switch DSP to [bus 03-ff]
        device_type = "pci";
        bus-range = <0x03 0xff>;
        qcom,no-dfe-support;
      };

      pcie@2,0 {
        reg = <0x21000 0x0 0x0 0x0 0x0>;   # 02:02.0 Switch DSP to [bus 04-ff]
        device_type = "pci";
        bus-range = <0x04 0xff>;
        qcom,nfts = <10>;
      };

      pcie@3,0 {
        reg = <0x21800 0x0 0x0 0x0 0x0>;   # 02:02.1 Switch DSP to [bus 05-ff]
        device_type = "pci";
        bus-range = <0x05 0xff>;
        qcom,tx-amplitude-millivolt = <10>;

        pcie@0,0 {
          reg = <0x50000 0x0 0x0 0x0 0x0>; # 05:00.0 Ethernet MAC, I guess?
          device_type = "pci";
          qcom,l1-entry-delay-ns = <10>;
        };

        ...
      };
    };
  };

So I think the bus-range properties are needed to match the reg
properties of the downstream devices.

I do think the bus-ranges of the Switch Downstream Ports look bogus
because they all extend to bus ff, so they overlap.  The Switch
wouldn't know how to route config transactions to the correct DSP.
I suppose the PCI core would fix these overlaps at boot time, but 
it seems wrong to describe them this way here.

There's an example "reg" decoding and a couple URLs here:
https://lore.kernel.org/r/20250106230705.GA132316@bhelgaas

Bjorn

Re: [PATCH v3 1/6] dt-bindings: PCI: Add binding for qps615

[Manivannan Sadhasivam]

On Tue, Jan 07, 2025 at 04:42:44PM -0600, Bjorn Helgaas wrote:
> On Tue, Dec 24, 2024 at 11:49:42AM +0200, Dmitry Baryshkov wrote:
> > On Tue, Dec 24, 2024 at 02:41:10PM +0530, Krishna Chaitanya Chundru wrote:
> > > On 12/5/2024 2:55 AM, Bjorn Helgaas wrote:
> > > > On Tue, Nov 12, 2024 at 08:31:33PM +0530, Krishna chaitanya chundru wrote:
> > > > > Add binding describing the Qualcomm PCIe switch, QPS615,
> > > > > which provides Ethernet MAC integrated to the 3rd downstream port
> > > > > and two downstream PCIe ports.
> 
> > > > > +    pcie {
> > > > > +        #address-cells = <3>;
> > > > > +        #size-cells = <2>;
> > > > > +
> > > > > +        pcie@0 {
> > > > > +            device_type = "pci";
> > > > > +            reg = <0x0 0x0 0x0 0x0 0x0>;
> > > > > +
> > > > > +            #address-cells = <3>;
> > > > > +            #size-cells = <2>;
> > > > > +            ranges;
> > > > > +            bus-range = <0x01 0xff>;
> > > > > +
> > > > > +            pcie@0,0 {
> > > > > +                compatible = "pci1179,0623";
> > > > > +                reg = <0x10000 0x0 0x0 0x0 0x0>;
> > > > > +                device_type = "pci";
> > > > > +                #address-cells = <3>;
> > > > > +                #size-cells = <2>;
> > > > > +                ranges;
> > > > > +                bus-range = <0x02 0xff>;
> > > > 
> > > > This binding describes a switch.  I don't think bus-range should
> > > > appear here at all because it is not a feature of the hardware (unless
> > > > the switch ports are broken and their Secondary/Subordinate Bus
> > > > Numbers are hard-wired).
> > > > 
> > > > The Primary/Secondary/Subordinate Bus Numbers of all switch ports
> > > > should be writable and the PCI core knows how to manage them.
> > > 
> > > The dt binding check is throwing an error if we don't keep bus-range
> > > property for that reason we added it, from dt binding perspective i think it
> > > is mandatory to add this property.
> > 
> > Could you please provide an error message? I don't see any of the PCIe
> > bindingins declaring bus-range as mandatory. I might be missing it
> > though.
> 
> I think the warning message is like this:
> 
>   Warning (pci_device_bus_num): /soc@0/pcie@1c00000/pcie@0/wifi@0: PCI bus number 1 out of range, expected (0 - 0)
> 
> and only happens if there's a device below a Root Port or a Switch.
> In that case the device "reg" property apparently has to include the
> bus/device/function.
> 
> IIUC, in this case, we're describing a Switch with an integrated
> Ethernet MAC:
> 
>   pcie@0 {
>     device_type = "pci";
>     reg = <0x0 0x0 0x0 0x0 0x0>;           # 00:00.0 RP to [bus 01-ff]
>     bus-range = <0x01 0xff>;
> 
>     pcie@0,0 {
>       compatible = "pci1179,0623";
>       reg = <0x10000 0x0 0x0 0x0 0x0>;     # 01:00.0 Switch USP to [bus 02-ff]
>       device_type = "pci";
>       bus-range = <0x02 0xff>;
> 
>       pcie@1,0 {
>         reg = <0x20800 0x0 0x0 0x0 0x0>;   # 02:01.0 Switch DSP to [bus 03-ff]
>         device_type = "pci";
>         bus-range = <0x03 0xff>;
>         qcom,no-dfe-support;
>       };
> 
>       pcie@2,0 {
>         reg = <0x21000 0x0 0x0 0x0 0x0>;   # 02:02.0 Switch DSP to [bus 04-ff]
>         device_type = "pci";
>         bus-range = <0x04 0xff>;
>         qcom,nfts = <10>;
>       };
> 
>       pcie@3,0 {
>         reg = <0x21800 0x0 0x0 0x0 0x0>;   # 02:02.1 Switch DSP to [bus 05-ff]
>         device_type = "pci";
>         bus-range = <0x05 0xff>;
>         qcom,tx-amplitude-millivolt = <10>;
> 
>         pcie@0,0 {
>           reg = <0x50000 0x0 0x0 0x0 0x0>; # 05:00.0 Ethernet MAC, I guess?
>           device_type = "pci";
>           qcom,l1-entry-delay-ns = <10>;
>         };
> 
>         ...
>       };
>     };
>   };
> 
> So I think the bus-range properties are needed to match the reg
> properties of the downstream devices.
> 
> I do think the bus-ranges of the Switch Downstream Ports look bogus
> because they all extend to bus ff, so they overlap.  The Switch
> wouldn't know how to route config transactions to the correct DSP.
> I suppose the PCI core would fix these overlaps at boot time, but 
> it seems wrong to describe them this way here.
> 

Yeah, max bus range is really a dynamic value. But I don't know how we could
define a legal value other than 'ff' statically.

Open firmware PCI bus binding defines 'bus-range' as:

"Two integers, each encoded as with encode-int, the first representing the bus
number of the PCI bus implemented by the bus controller represented by this node
(the secondary bus number in PCI-to-PCI bridge nomenclature), and the second
representing the largest bus number of any PCI bus in the portion of the PCI
domain that is subordinate to this node (the subordinate bus number in
PCI-to-PCI bridge nomenclature)."

https://www.openfirmware.info/data/docs/bus.pci.pdf

- Mani

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

Re: [PATCH v3 1/6] dt-bindings: PCI: Add binding for qps615

[Manivannan Sadhasivam]

On Wed, Dec 04, 2024 at 02:19:56PM +0530, Krishna Chaitanya Chundru wrote:

[...]

> > > > +                pcie@3,0 {
> > > > +                    reg = <0x21800 0x0 0x0 0x0 0x0>;
> > > > +                    #address-cells = <3>;
> > > > +                    #size-cells = <2>;
> > > > +                    device_type = "pci";
> > > > +                    ranges;
> > > > +                    bus-range = <0x05 0xff>;
> > > > +
> > > > +                    qcom,tx-amplitude-millivolt = <10>;
> > > > +                    pcie@0,0 {
> > > > +                        reg = <0x50000 0x0 0x0 0x0 0x0>;
> > > > +                        #address-cells = <3>;
> > > > +                        #size-cells = <2>;
> > > > +                        device_type = "pci";
> > > 
> > > There's a 2nd PCI-PCI bridge?
> > This the embedded ethernet port which is as part of DSP3.
> > 
> Hi Rob,
> 
> Can you please check my response on your queries, if you need
> any extra information, we can provide to sort this out.
> 

I believe Rob was pointing the 'device_type' property which is not needed for
PCI device nodes but only for nodes implementing PCI bus (like host bridge, PCI
bridge).

- Mani

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

Re: [PATCH v3 1/6] dt-bindings: PCI: Add binding for qps615

[Manivannan Sadhasivam]

On Tue, Jan 07, 2025 at 07:58:17PM +0530, Krishna Chaitanya Chundru wrote:
> 
> 
> On 12/30/2024 11:52 PM, Manivannan Sadhasivam wrote:
> > On Mon, Dec 23, 2024 at 08:57:37PM +0200, Dmitry Baryshkov wrote:
> > 
> > [...]
> > 
> > > > This switch allows us to configure both upstream, downstream ports and
> > > > also embedded Ethernet port which is internal to the switch. These
> > > > properties are applicable for all of those.
> > > > > > +
> > > > > > +    allOf:
> > > > > > +      - $ref: /schemas/pci/pci-bus.yaml#
> > > > > 
> > > > > pci-pci-bridge.yaml is more specific and closer to what this device is.
> > > > > 
> > > > I tried this now, I was getting warning saying the compatible
> > > > /local/mnt/workspace/skales/kobj/Documentation/devicetree/bindings/pci/qcom,qps615.example.dtb:
> > > > pcie@0,0: compatible: ['pci1179,0623'] does not contain items matching the
> > > > given schema
> > > >          from schema $id: http://devicetree.org/schemas/pci/qcom,qps615.yaml#
> > > > /local/mnt/workspace/skales/kobj/Documentation/devicetree/bindings/pci/qcom,qps615.example.dtb:
> > > > pcie@0,0: Unevaluated properties are not allowed ('#address-cells',
> > > > '#size-cells', 'bus-range', 'device_type', 'ranges' were unexpected)
> > > > 
> > > > I think pci-pci-bridge is expecting the compatible string in this format
> > > > only "pciclass,0604".
> > > 
> > > I think the pci-pci-bridge schema requires to have "pciclass,0604" among
> > > other compatibles. So you should be able to do something like:
> > > 
> > > compatible = "pci1179,0623", "pciclass,0604";
> > > 
> > 
> > Even though a PCIe switch is supposed to be a network of PCI bridges, using
> > PCI bridge fallback for this switch is not technically correct IMO. Mostly
> > because, this switch requires other configurations which are not applicable to
> > PCI bridges. So the drivers matching against the bridge compatible won't be able
> > to use this switch.
> > 
> > - Mani
> Rob,
> 
> Using pci-pci-bridge expects to use compatible as pciclass,0604, we
> can't  use as this switch is doing other configurations which are
> applicable to PCI bridges. can we continue to use pci-bus.yaml.
> 

Let's put it the other way. What are the blockers in using the
pci-pci-bridge.yaml other than the fallback compatible? If the compatible is the
only blocker, you can add it even though the drivers cannot make use of it
(that's one of the reason why I was against adding it).

- Mani

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

Re: [PATCH v3 1/6] dt-bindings: PCI: Add binding for qps615

[Krishna Chaitanya Chundru]

On 2/10/2025 1:21 PM, Manivannan Sadhasivam wrote:
> On Wed, Dec 04, 2024 at 02:19:56PM +0530, Krishna Chaitanya Chundru wrote:
> 
> [...]
> 
>>>>> +                pcie@3,0 {
>>>>> +                    reg = <0x21800 0x0 0x0 0x0 0x0>;
>>>>> +                    #address-cells = <3>;
>>>>> +                    #size-cells = <2>;
>>>>> +                    device_type = "pci";
>>>>> +                    ranges;
>>>>> +                    bus-range = <0x05 0xff>;
>>>>> +
>>>>> +                    qcom,tx-amplitude-millivolt = <10>;
>>>>> +                    pcie@0,0 {
>>>>> +                        reg = <0x50000 0x0 0x0 0x0 0x0>;
>>>>> +                        #address-cells = <3>;
>>>>> +                        #size-cells = <2>;
>>>>> +                        device_type = "pci";
>>>>
>>>> There's a 2nd PCI-PCI bridge?
>>> This the embedded ethernet port which is as part of DSP3.
>>>
>> Hi Rob,
>>
>> Can you please check my response on your queries, if you need
>> any extra information, we can provide to sort this out.
>>
> 
> I believe Rob was pointing the 'device_type' property which is not needed for
> PCI device nodes but only for nodes implementing PCI bus (like host bridge, PCI
> bridge).
> 
Got it, I will remove device_type in the next patch series.

- Krishna Chaitanya.
> - Mani
> 

Re: [PATCH v3 1/6] dt-bindings: PCI: Add binding for qps615

[Krishna Chaitanya Chundru]

On 2/10/2025 1:28 PM, Manivannan Sadhasivam wrote:
> On Tue, Jan 07, 2025 at 07:58:17PM +0530, Krishna Chaitanya Chundru wrote:
>>
>>
>> On 12/30/2024 11:52 PM, Manivannan Sadhasivam wrote:
>>> On Mon, Dec 23, 2024 at 08:57:37PM +0200, Dmitry Baryshkov wrote:
>>>
>>> [...]
>>>
>>>>> This switch allows us to configure both upstream, downstream ports and
>>>>> also embedded Ethernet port which is internal to the switch. These
>>>>> properties are applicable for all of those.
>>>>>>> +
>>>>>>> +    allOf:
>>>>>>> +      - $ref: /schemas/pci/pci-bus.yaml#
>>>>>>
>>>>>> pci-pci-bridge.yaml is more specific and closer to what this device is.
>>>>>>
>>>>> I tried this now, I was getting warning saying the compatible
>>>>> /local/mnt/workspace/skales/kobj/Documentation/devicetree/bindings/pci/qcom,qps615.example.dtb:
>>>>> pcie@0,0: compatible: ['pci1179,0623'] does not contain items matching the
>>>>> given schema
>>>>>           from schema $id: http://devicetree.org/schemas/pci/qcom,qps615.yaml#
>>>>> /local/mnt/workspace/skales/kobj/Documentation/devicetree/bindings/pci/qcom,qps615.example.dtb:
>>>>> pcie@0,0: Unevaluated properties are not allowed ('#address-cells',
>>>>> '#size-cells', 'bus-range', 'device_type', 'ranges' were unexpected)
>>>>>
>>>>> I think pci-pci-bridge is expecting the compatible string in this format
>>>>> only "pciclass,0604".
>>>>
>>>> I think the pci-pci-bridge schema requires to have "pciclass,0604" among
>>>> other compatibles. So you should be able to do something like:
>>>>
>>>> compatible = "pci1179,0623", "pciclass,0604";
>>>>
>>>
>>> Even though a PCIe switch is supposed to be a network of PCI bridges, using
>>> PCI bridge fallback for this switch is not technically correct IMO. Mostly
>>> because, this switch requires other configurations which are not applicable to
>>> PCI bridges. So the drivers matching against the bridge compatible won't be able
>>> to use this switch.
>>>
>>> - Mani
>> Rob,
>>
>> Using pci-pci-bridge expects to use compatible as pciclass,0604, we
>> can't  use as this switch is doing other configurations which are
>> applicable to PCI bridges. can we continue to use pci-bus.yaml.
>>
> 
> Let's put it the other way. What are the blockers in using the
> pci-pci-bridge.yaml other than the fallback compatible? If the compatible is the
> only blocker, you can add it even though the drivers cannot make use of it
> (that's one of the reason why I was against adding it).
> 
> - Mani
> 
Compatible is the only blocking thing here.
If I use pci-pci-bridge.yaml I was getting fallowing warning
pcie@0,0: compatible: ['pci1179,0623'] does not contain items matching 
the given schema

can we use this way compatible = "pci1179,0623", "pciclass,0604"; to
avoid warnings.

- Krishna Chaitanya.