[PATCH v3 0/7] arm64: dts: rockchip: rk3568-evb1-v10: add sd card support

[PATCH v3 0/7] arm64: dts: rockchip: rk3568-evb1-v10: add sd card support

[Michael Riesch]

Hi all,

This series enables the SD card reader on the RK3568 EVB1
and completes the support for the on-board eMMC.

As the PMU IO domains are required, the patch series that
introduces support for the RK3568 PMU IO domains [1] has been
revised and integrated in this series.
Additionally, the required voltage regulators of the RK809
PMIC are enabled.

Best regards,
Michael

[1] https://patchwork.kernel.org/project/linux-rockchip/list/?series=489383

v3:
- clean up device tree properties and sort alphabetically

v2:
- rename alias to match convention
- add support for rk3568 io domains

Jianqun Xu (1):
  soc: rockchip: io-domain: add rk3568 support

Michael Riesch (6):
  dt-bindings: power: add rk3568-pmu-io-domain support
  arm64: dts: rockchip: enable io domains for rk356x
  arm64: dts: rockchip: rk3568-evb1-v10: enable io domains
  arm64: dts: rockchip: rk3568-evb1-v10: add regulators of rk809 pmic
  arm64: dts: rockchip: rk3568-evb1-v10: add node for sd card
  arm64: dts: rockchip: rk3568-evb1-v10: add pinctrl and alias to emmc
    node

 .../bindings/power/rockchip-io-domain.yaml    |  30 +++
 .../devicetree/bindings/soc/rockchip/grf.yaml |   1 +
 .../boot/dts/rockchip/rk3568-evb1-v10.dts     | 251 ++++++++++++++++++
 arch/arm64/boot/dts/rockchip/rk356x.dtsi      |   5 +
 drivers/soc/rockchip/io-domain.c              |  88 +++++-
 5 files changed, 367 insertions(+), 8 deletions(-)

-- 
2.17.1


_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

[PATCH v3 1/7] dt-bindings: power: add rk3568-pmu-io-domain support

[Michael Riesch]

Add binding for the RK3568 along a SoC-specific description of
voltage supplies.

Signed-off-by: Jianqun Xu <jay.xu@rock-chips.com>
[add soc-specific section]
Signed-off-by: Michael Riesch <michael.riesch@wolfvision.net>
---
v3:
- add missing compatible for the rk3568 to grf.yaml

 .../bindings/power/rockchip-io-domain.yaml    | 30 +++++++++++++++++++
 .../devicetree/bindings/soc/rockchip/grf.yaml |  1 +
 2 files changed, 31 insertions(+)

diff --git a/Documentation/devicetree/bindings/power/rockchip-io-domain.yaml b/Documentation/devicetree/bindings/power/rockchip-io-domain.yaml
index 121bec56b2b0..1727bf108979 100644
--- a/Documentation/devicetree/bindings/power/rockchip-io-domain.yaml
+++ b/Documentation/devicetree/bindings/power/rockchip-io-domain.yaml
@@ -55,6 +55,7 @@ properties:
       - rockchip,rk3368-pmu-io-voltage-domain
       - rockchip,rk3399-io-voltage-domain
       - rockchip,rk3399-pmu-io-voltage-domain
+      - rockchip,rk3568-pmu-io-voltage-domain
       - rockchip,rv1108-io-voltage-domain
       - rockchip,rv1108-pmu-io-voltage-domain
 
@@ -74,6 +75,7 @@ allOf:
   - $ref: "#/$defs/rk3368-pmu"
   - $ref: "#/$defs/rk3399"
   - $ref: "#/$defs/rk3399-pmu"
+  - $ref: "#/$defs/rk3568-pmu"
   - $ref: "#/$defs/rv1108"
   - $ref: "#/$defs/rv1108-pmu"
 
@@ -282,6 +284,34 @@ $defs:
         pmu1830-supply:
           description: The supply connected to PMUIO2_VDD.
 
+  rk3568-pmu:
+    if:
+      properties:
+        compatible:
+          contains:
+            const: rockchip,rk3568-pmu-io-voltage-domain
+
+    then:
+      properties:
+        pmuio1-supply:
+          description: The supply connected to PMUIO1.
+        pmuio2-supply:
+          description: The supply connected to PMUIO2.
+        vccio1-supply:
+          description: The supply connected to VCCIO1.
+        vccio2-supply:
+          description: The supply connected to VCCIO2.
+        vccio3-supply:
+          description: The supply connected to VCCIO3.
+        vccio4-supply:
+          description: The supply connected to VCCIO4.
+        vccio5-supply:
+          description: The supply connected to VCCIO5.
+        vccio6-supply:
+          description: The supply connected to VCCIO6.
+        vccio7-supply:
+          description: The supply connected to VCCIO7.
+
   rv1108:
     if:
       properties:
diff --git a/Documentation/devicetree/bindings/soc/rockchip/grf.yaml b/Documentation/devicetree/bindings/soc/rockchip/grf.yaml
index fa010df51a5c..dfebf425ca49 100644
--- a/Documentation/devicetree/bindings/soc/rockchip/grf.yaml
+++ b/Documentation/devicetree/bindings/soc/rockchip/grf.yaml
@@ -208,6 +208,7 @@ allOf:
               - rockchip,rk3368-pmugrf
               - rockchip,rk3399-grf
               - rockchip,rk3399-pmugrf
+              - rockchip,rk3568-pmugrf
               - rockchip,rv1108-grf
               - rockchip,rv1108-pmugrf
 
-- 
2.17.1


_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

[PATCH v3 2/7] soc: rockchip: io-domain: add rk3568 support

[Michael Riesch]

From: Jianqun Xu <jay.xu@rock-chips.com>

The io-domain registers on RK3568 SoCs have three separated bits to
enable/disable the 1.8v/2.5v/3.3v power.

This patch make the write to be a operation, allow rk3568 uses a private
register set function.

Since the 2.5v is not used on RK3568, so the driver only set
1.8v [enable] + 3.3v [disable] for 1.8v mode
1.8v [disable] + 3.3v [enable] for 3.3v mode

There is not register order requirement which has been cleared by our IC
team.

Signed-off-by: Jianqun Xu <jay.xu@rock-chips.com>
---
 drivers/soc/rockchip/io-domain.c | 88 +++++++++++++++++++++++++++++---
 1 file changed, 80 insertions(+), 8 deletions(-)

diff --git a/drivers/soc/rockchip/io-domain.c b/drivers/soc/rockchip/io-domain.c
index cf8182fc3642..13c446fd33a9 100644
--- a/drivers/soc/rockchip/io-domain.c
+++ b/drivers/soc/rockchip/io-domain.c
@@ -51,13 +51,11 @@
 #define RK3399_PMUGRF_CON0_VSEL		BIT(8)
 #define RK3399_PMUGRF_VSEL_SUPPLY_NUM	9
 
-struct rockchip_iodomain;
+#define RK3568_PMU_GRF_IO_VSEL0		(0x0140)
+#define RK3568_PMU_GRF_IO_VSEL1		(0x0144)
+#define RK3568_PMU_GRF_IO_VSEL2		(0x0148)
 
-struct rockchip_iodomain_soc_data {
-	int grf_offset;
-	const char *supply_names[MAX_SUPPLIES];
-	void (*init)(struct rockchip_iodomain *iod);
-};
+struct rockchip_iodomain;
 
 struct rockchip_iodomain_supply {
 	struct rockchip_iodomain *iod;
@@ -66,13 +64,62 @@ struct rockchip_iodomain_supply {
 	int idx;
 };
 
+struct rockchip_iodomain_soc_data {
+	int grf_offset;
+	const char *supply_names[MAX_SUPPLIES];
+	void (*init)(struct rockchip_iodomain *iod);
+	int (*write)(struct rockchip_iodomain_supply *supply, int uV);
+};
+
 struct rockchip_iodomain {
 	struct device *dev;
 	struct regmap *grf;
 	const struct rockchip_iodomain_soc_data *soc_data;
 	struct rockchip_iodomain_supply supplies[MAX_SUPPLIES];
+	int (*write)(struct rockchip_iodomain_supply *supply, int uV);
 };
 
+static int rk3568_iodomain_write(struct rockchip_iodomain_supply *supply, int uV)
+{
+	struct rockchip_iodomain *iod = supply->iod;
+	u32 is_3v3 = uV > MAX_VOLTAGE_1_8;
+	u32 val0, val1;
+	int b;
+
+	switch (supply->idx) {
+	case 0: /* pmuio1 */
+		break;
+	case 1: /* pmuio2 */
+		b = supply->idx;
+		val0 = BIT(16 + b) | (is_3v3 ? 0 : BIT(b));
+		b = supply->idx + 4;
+		val1 = BIT(16 + b) | (is_3v3 ? BIT(b) : 0);
+
+		regmap_write(iod->grf, RK3568_PMU_GRF_IO_VSEL2, val0);
+		regmap_write(iod->grf, RK3568_PMU_GRF_IO_VSEL2, val1);
+		break;
+	case 3: /* vccio2 */
+		break;
+	case 2: /* vccio1 */
+	case 4: /* vccio3 */
+	case 5: /* vccio4 */
+	case 6: /* vccio5 */
+	case 7: /* vccio6 */
+	case 8: /* vccio7 */
+		b = supply->idx - 1;
+		val0 = BIT(16 + b) | (is_3v3 ? 0 : BIT(b));
+		val1 = BIT(16 + b) | (is_3v3 ? BIT(b) : 0);
+
+		regmap_write(iod->grf, RK3568_PMU_GRF_IO_VSEL0, val0);
+		regmap_write(iod->grf, RK3568_PMU_GRF_IO_VSEL1, val1);
+		break;
+	default:
+		return -EINVAL;
+	};
+
+	return 0;
+}
+
 static int rockchip_iodomain_write(struct rockchip_iodomain_supply *supply,
 				   int uV)
 {
@@ -136,7 +183,7 @@ static int rockchip_iodomain_notify(struct notifier_block *nb,
 			return NOTIFY_BAD;
 	}
 
-	ret = rockchip_iodomain_write(supply, uV);
+	ret = supply->iod->write(supply, uV);
 	if (ret && event == REGULATOR_EVENT_PRE_VOLTAGE_CHANGE)
 		return NOTIFY_BAD;
 
@@ -398,6 +445,22 @@ static const struct rockchip_iodomain_soc_data soc_data_rk3399_pmu = {
 	.init = rk3399_pmu_iodomain_init,
 };
 
+static const struct rockchip_iodomain_soc_data soc_data_rk3568_pmu = {
+	.grf_offset = 0x140,
+	.supply_names = {
+		"pmuio1",
+		"pmuio2",
+		"vccio1",
+		"vccio2",
+		"vccio3",
+		"vccio4",
+		"vccio5",
+		"vccio6",
+		"vccio7",
+	},
+	.write = rk3568_iodomain_write,
+};
+
 static const struct rockchip_iodomain_soc_data soc_data_rv1108 = {
 	.grf_offset = 0x404,
 	.supply_names = {
@@ -469,6 +532,10 @@ static const struct of_device_id rockchip_iodomain_match[] = {
 		.compatible = "rockchip,rk3399-pmu-io-voltage-domain",
 		.data = &soc_data_rk3399_pmu
 	},
+	{
+		.compatible = "rockchip,rk3568-pmu-io-voltage-domain",
+		.data = &soc_data_rk3568_pmu
+	},
 	{
 		.compatible = "rockchip,rv1108-io-voltage-domain",
 		.data = &soc_data_rv1108
@@ -502,6 +569,11 @@ static int rockchip_iodomain_probe(struct platform_device *pdev)
 	match = of_match_node(rockchip_iodomain_match, np);
 	iod->soc_data = match->data;
 
+	if (iod->soc_data->write)
+		iod->write = iod->soc_data->write;
+	else
+		iod->write = rockchip_iodomain_write;
+
 	parent = pdev->dev.parent;
 	if (parent && parent->of_node) {
 		iod->grf = syscon_node_to_regmap(parent->of_node);
@@ -562,7 +634,7 @@ static int rockchip_iodomain_probe(struct platform_device *pdev)
 		supply->reg = reg;
 		supply->nb.notifier_call = rockchip_iodomain_notify;
 
-		ret = rockchip_iodomain_write(supply, uV);
+		ret = iod->write(supply, uV);
 		if (ret) {
 			supply->reg = NULL;
 			goto unreg_notify;
-- 
2.17.1


_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

[PATCH v3 3/7] arm64: dts: rockchip: enable io domains for rk356x

[Michael Riesch]

Enable the PMU IO domains for the RK3566 and the RK3568.

Signed-off-by: Michael Riesch <michael.riesch@wolfvision.net>
---
 arch/arm64/boot/dts/rockchip/rk356x.dtsi | 5 +++++
 1 file changed, 5 insertions(+)

diff --git a/arch/arm64/boot/dts/rockchip/rk356x.dtsi b/arch/arm64/boot/dts/rockchip/rk356x.dtsi
index 3e90a8832bb9..834863940eba 100644
--- a/arch/arm64/boot/dts/rockchip/rk356x.dtsi
+++ b/arch/arm64/boot/dts/rockchip/rk356x.dtsi
@@ -203,6 +203,11 @@
 	pmugrf: syscon@fdc20000 {
 		compatible = "rockchip,rk3568-pmugrf", "syscon", "simple-mfd";
 		reg = <0x0 0xfdc20000 0x0 0x10000>;
+
+		pmu_io_domains: io-domains {
+			compatible = "rockchip,rk3568-pmu-io-voltage-domain";
+			status = "disabled";
+		};
 	};
 
 	grf: syscon@fdc60000 {
-- 
2.17.1


_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

[PATCH v3 4/7] arm64: dts: rockchip: rk3568-evb1-v10: enable io domains

[Michael Riesch]

Enable the PMU IO domains in the device tree for the RK3568 EVB1.

Signed-off-by: Michael Riesch <michael.riesch@wolfvision.net>
---
 arch/arm64/boot/dts/rockchip/rk3568-evb1-v10.dts | 13 +++++++++++++
 1 file changed, 13 insertions(+)

diff --git a/arch/arm64/boot/dts/rockchip/rk3568-evb1-v10.dts b/arch/arm64/boot/dts/rockchip/rk3568-evb1-v10.dts
index 65e536c78d2e..287b58aa6a77 100644
--- a/arch/arm64/boot/dts/rockchip/rk3568-evb1-v10.dts
+++ b/arch/arm64/boot/dts/rockchip/rk3568-evb1-v10.dts
@@ -124,6 +124,19 @@
 	};
 };
 
+&pmu_io_domains {
+	pmuio1-supply = <&vcc3v3_pmu>;
+	pmuio2-supply = <&vcc3v3_pmu>;
+	vccio1-supply = <&vccio_acodec>;
+	vccio2-supply = <&vcc_1v8>;
+	vccio3-supply = <&vccio_sd>;
+	vccio4-supply = <&vcc_1v8>;
+	vccio5-supply = <&vcc_3v3>;
+	vccio6-supply = <&vcc_1v8>;
+	vccio7-supply = <&vcc_3v3>;
+	status = "okay";
+};
+
 &sdhci {
 	bus-width = <8>;
 	max-frequency = <200000000>;
-- 
2.17.1


_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

[PATCH v3 5/7] arm64: dts: rockchip: rk3568-evb1-v10: add regulators of rk809 pmic

[Michael Riesch]

Add the regulators of the RK809 PMIC to the device tree of the
RK3568 EVB1.

Signed-off-by: Michael Riesch <michael.riesch@wolfvision.net>
---
v3:
- sort device tree properties alphabetically

 .../boot/dts/rockchip/rk3568-evb1-v10.dts     | 221 ++++++++++++++++++
 1 file changed, 221 insertions(+)

diff --git a/arch/arm64/boot/dts/rockchip/rk3568-evb1-v10.dts b/arch/arm64/boot/dts/rockchip/rk3568-evb1-v10.dts
index 287b58aa6a77..92af4ce89b70 100644
--- a/arch/arm64/boot/dts/rockchip/rk3568-evb1-v10.dts
+++ b/arch/arm64/boot/dts/rockchip/rk3568-evb1-v10.dts
@@ -104,6 +104,218 @@
 	status = "okay";
 };
 
+&i2c0 {
+	status = "okay";
+
+	rk809: pmic@20 {
+		compatible = "rockchip,rk809";
+		reg = <0x20>;
+		interrupt-parent = <&gpio0>;
+		interrupts = <RK_PA3 IRQ_TYPE_LEVEL_LOW>;
+		#clock-cells = <1>;
+		pinctrl-names = "default";
+		pinctrl-0 = <&pmic_int>;
+		rockchip,system-power-controller;
+		vcc1-supply = <&vcc3v3_sys>;
+		vcc2-supply = <&vcc3v3_sys>;
+		vcc3-supply = <&vcc3v3_sys>;
+		vcc4-supply = <&vcc3v3_sys>;
+		vcc5-supply = <&vcc3v3_sys>;
+		vcc6-supply = <&vcc3v3_sys>;
+		vcc7-supply = <&vcc3v3_sys>;
+		vcc8-supply = <&vcc3v3_sys>;
+		vcc9-supply = <&vcc3v3_sys>;
+		wakeup-source;
+
+		regulators {
+			vdd_logic: DCDC_REG1 {
+				regulator-name = "vdd_logic";
+				regulator-always-on;
+				regulator-boot-on;
+				regulator-init-microvolt = <900000>;
+				regulator-initial-mode = <0x2>;
+				regulator-min-microvolt = <500000>;
+				regulator-max-microvolt = <1350000>;
+				regulator-ramp-delay = <6001>;
+
+				regulator-state-mem {
+					regulator-off-in-suspend;
+				};
+			};
+
+			vdd_gpu: DCDC_REG2 {
+				regulator-name = "vdd_gpu";
+				regulator-init-microvolt = <900000>;
+				regulator-initial-mode = <0x2>;
+				regulator-min-microvolt = <500000>;
+				regulator-max-microvolt = <1350000>;
+				regulator-ramp-delay = <6001>;
+
+				regulator-state-mem {
+					regulator-off-in-suspend;
+				};
+			};
+
+			vcc_ddr: DCDC_REG3 {
+				regulator-name = "vcc_ddr";
+				regulator-always-on;
+				regulator-boot-on;
+				regulator-initial-mode = <0x2>;
+
+				regulator-state-mem {
+					regulator-on-in-suspend;
+				};
+			};
+
+			vdd_npu: DCDC_REG4 {
+				regulator-name = "vdd_npu";
+				regulator-init-microvolt = <900000>;
+				regulator-initial-mode = <0x2>;
+				regulator-min-microvolt = <500000>;
+				regulator-max-microvolt = <1350000>;
+				regulator-ramp-delay = <6001>;
+
+				regulator-state-mem {
+					regulator-off-in-suspend;
+				};
+			};
+
+			vcc_1v8: DCDC_REG5 {
+				regulator-name = "vcc_1v8";
+				regulator-always-on;
+				regulator-boot-on;
+				regulator-min-microvolt = <1800000>;
+				regulator-max-microvolt = <1800000>;
+
+				regulator-state-mem {
+					regulator-off-in-suspend;
+				};
+			};
+
+			vdda0v9_image: LDO_REG1 {
+				regulator-name = "vdda0v9_image";
+				regulator-min-microvolt = <900000>;
+				regulator-max-microvolt = <900000>;
+
+				regulator-state-mem {
+					regulator-off-in-suspend;
+				};
+			};
+
+			vdda_0v9: LDO_REG2 {
+				regulator-name = "vdda_0v9";
+				regulator-always-on;
+				regulator-boot-on;
+				regulator-min-microvolt = <900000>;
+				regulator-max-microvolt = <900000>;
+
+				regulator-state-mem {
+					regulator-off-in-suspend;
+				};
+			};
+
+			vdda0v9_pmu: LDO_REG3 {
+				regulator-name = "vdda0v9_pmu";
+				regulator-always-on;
+				regulator-boot-on;
+				regulator-min-microvolt = <900000>;
+				regulator-max-microvolt = <900000>;
+
+				regulator-state-mem {
+					regulator-on-in-suspend;
+					regulator-suspend-microvolt = <900000>;
+				};
+			};
+
+			vccio_acodec: LDO_REG4 {
+				regulator-name = "vccio_acodec";
+				regulator-min-microvolt = <3300000>;
+				regulator-max-microvolt = <3300000>;
+
+				regulator-state-mem {
+					regulator-off-in-suspend;
+				};
+			};
+
+			vccio_sd: LDO_REG5 {
+				regulator-name = "vccio_sd";
+				regulator-min-microvolt = <1800000>;
+				regulator-max-microvolt = <3300000>;
+
+				regulator-state-mem {
+					regulator-off-in-suspend;
+				};
+			};
+
+			vcc3v3_pmu: LDO_REG6 {
+				regulator-name = "vcc3v3_pmu";
+				regulator-always-on;
+				regulator-boot-on;
+				regulator-min-microvolt = <3300000>;
+				regulator-max-microvolt = <3300000>;
+
+				regulator-state-mem {
+					regulator-on-in-suspend;
+					regulator-suspend-microvolt = <3300000>;
+				};
+			};
+
+			vcca_1v8: LDO_REG7 {
+				regulator-name = "vcca_1v8";
+				regulator-always-on;
+				regulator-boot-on;
+				regulator-min-microvolt = <1800000>;
+				regulator-max-microvolt = <1800000>;
+
+				regulator-state-mem {
+					regulator-off-in-suspend;
+				};
+			};
+
+			vcca1v8_pmu: LDO_REG8 {
+				regulator-name = "vcca1v8_pmu";
+				regulator-always-on;
+				regulator-boot-on;
+				regulator-min-microvolt = <1800000>;
+				regulator-max-microvolt = <1800000>;
+
+				regulator-state-mem {
+					regulator-on-in-suspend;
+					regulator-suspend-microvolt = <1800000>;
+				};
+			};
+
+			vcca1v8_image: LDO_REG9 {
+				regulator-name = "vcca1v8_image";
+				regulator-min-microvolt = <1800000>;
+				regulator-max-microvolt = <1800000>;
+
+				regulator-state-mem {
+					regulator-off-in-suspend;
+				};
+			};
+
+			vcc_3v3: SWITCH_REG1 {
+				regulator-name = "vcc_3v3";
+				regulator-always-on;
+				regulator-boot-on;
+
+				regulator-state-mem {
+					regulator-off-in-suspend;
+				};
+			};
+
+			vcc3v3_sd: SWITCH_REG2 {
+				regulator-name = "vcc3v3_sd";
+
+				regulator-state-mem {
+					regulator-off-in-suspend;
+				};
+			};
+		};
+	};
+};
+
 &mdio0 {
 	rgmii_phy0: ethernet-phy@0 {
 		compatible = "ethernet-phy-ieee802.3-c22";
@@ -124,6 +336,15 @@
 	};
 };
 
+&pinctrl {
+	pmic {
+		pmic_int: pmic_int {
+			rockchip,pins =
+				<0 RK_PA3 RK_FUNC_GPIO &pcfg_pull_up>;
+		};
+	};
+};
+
 &pmu_io_domains {
 	pmuio1-supply = <&vcc3v3_pmu>;
 	pmuio2-supply = <&vcc3v3_pmu>;
-- 
2.17.1


_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

[PATCH v3 6/7] arm64: dts: rockchip: rk3568-evb1-v10: add node for sd card

[Michael Riesch]

Add the SD card reader to the device tree of the RK3568 EVB1.

Signed-off-by: Michael Riesch <michael.riesch@wolfvision.net>
---
v3:
- clean up device tree properties and sort alphabetically
- revise alias

 arch/arm64/boot/dts/rockchip/rk3568-evb1-v10.dts | 14 ++++++++++++++
 1 file changed, 14 insertions(+)

diff --git a/arch/arm64/boot/dts/rockchip/rk3568-evb1-v10.dts b/arch/arm64/boot/dts/rockchip/rk3568-evb1-v10.dts
index 92af4ce89b70..1c34d529b771 100644
--- a/arch/arm64/boot/dts/rockchip/rk3568-evb1-v10.dts
+++ b/arch/arm64/boot/dts/rockchip/rk3568-evb1-v10.dts
@@ -16,6 +16,7 @@
 	aliases {
 		ethernet0 = &gmac0;
 		ethernet1 = &gmac1;
+		mmc0 = &sdmmc0;
 	};
 
 	chosen: chosen {
@@ -365,6 +366,19 @@
 	status = "okay";
 };
 
+&sdmmc0 {
+	bus-width = <4>;
+	cap-sd-highspeed;
+	cd-gpios = <&gpio0 RK_PA4 GPIO_ACTIVE_LOW>;
+	disable-wp;
+	pinctrl-names = "default";
+	pinctrl-0 = <&sdmmc0_bus4 &sdmmc0_clk &sdmmc0_cmd &sdmmc0_det>;
+	sd-uhs-sdr104;
+	vmmc-supply = <&vcc3v3_sd>;
+	vqmmc-supply = <&vccio_sd>;
+	status = "okay";
+};
+
 &uart2 {
 	status = "okay";
 };
-- 
2.17.1


_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

[PATCH v3 7/7] arm64: dts: rockchip: rk3568-evb1-v10: add pinctrl and alias to emmc node

[Michael Riesch]

Since the EMMC pins can be used for other functions as well, we need to
configure the pinctrl.

Signed-off-by: Michael Riesch <michael.riesch@wolfvision.net>
---
v3:
- revise alias

 arch/arm64/boot/dts/rockchip/rk3568-evb1-v10.dts | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/arch/arm64/boot/dts/rockchip/rk3568-evb1-v10.dts b/arch/arm64/boot/dts/rockchip/rk3568-evb1-v10.dts
index 1c34d529b771..1bc79e95b2fb 100644
--- a/arch/arm64/boot/dts/rockchip/rk3568-evb1-v10.dts
+++ b/arch/arm64/boot/dts/rockchip/rk3568-evb1-v10.dts
@@ -17,6 +17,7 @@
 		ethernet0 = &gmac0;
 		ethernet1 = &gmac1;
 		mmc0 = &sdmmc0;
+		mmc1 = &sdhci;
 	};
 
 	chosen: chosen {
@@ -363,6 +364,8 @@
 	bus-width = <8>;
 	max-frequency = <200000000>;
 	non-removable;
+	pinctrl-names = "default";
+	pinctrl-0 = <&emmc_bus8 &emmc_clk &emmc_cmd &emmc_datastrobe>;
 	status = "okay";
 };
 
-- 
2.17.1


_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

Re: [PATCH v3 2/7] soc: rockchip: io-domain: add rk3568 support

[Peter Geis]

On Thu, Aug 5, 2021 at 8:01 AM Michael Riesch
<michael.riesch@wolfvision.net> wrote:
>
> From: Jianqun Xu <jay.xu@rock-chips.com>
>
> The io-domain registers on RK3568 SoCs have three separated bits to
> enable/disable the 1.8v/2.5v/3.3v power.
>
> This patch make the write to be a operation, allow rk3568 uses a private
> register set function.
>
> Since the 2.5v is not used on RK3568, so the driver only set
> 1.8v [enable] + 3.3v [disable] for 1.8v mode
> 1.8v [disable] + 3.3v [enable] for 3.3v mode
>
> There is not register order requirement which has been cleared by our IC
> team.

Tested on Quartz64 Model A, Quartz64 Model B.
Tested-by: Peter Geis <pgwipeout@gmail.com>

>
> Signed-off-by: Jianqun Xu <jay.xu@rock-chips.com>
> ---
>  drivers/soc/rockchip/io-domain.c | 88 +++++++++++++++++++++++++++++---
>  1 file changed, 80 insertions(+), 8 deletions(-)
>
> diff --git a/drivers/soc/rockchip/io-domain.c b/drivers/soc/rockchip/io-domain.c
> index cf8182fc3642..13c446fd33a9 100644
> --- a/drivers/soc/rockchip/io-domain.c
> +++ b/drivers/soc/rockchip/io-domain.c
> @@ -51,13 +51,11 @@
>  #define RK3399_PMUGRF_CON0_VSEL                BIT(8)
>  #define RK3399_PMUGRF_VSEL_SUPPLY_NUM  9
>
> -struct rockchip_iodomain;
> +#define RK3568_PMU_GRF_IO_VSEL0                (0x0140)
> +#define RK3568_PMU_GRF_IO_VSEL1                (0x0144)
> +#define RK3568_PMU_GRF_IO_VSEL2                (0x0148)
>
> -struct rockchip_iodomain_soc_data {
> -       int grf_offset;
> -       const char *supply_names[MAX_SUPPLIES];
> -       void (*init)(struct rockchip_iodomain *iod);
> -};
> +struct rockchip_iodomain;
>
>  struct rockchip_iodomain_supply {
>         struct rockchip_iodomain *iod;
> @@ -66,13 +64,62 @@ struct rockchip_iodomain_supply {
>         int idx;
>  };
>
> +struct rockchip_iodomain_soc_data {
> +       int grf_offset;
> +       const char *supply_names[MAX_SUPPLIES];
> +       void (*init)(struct rockchip_iodomain *iod);
> +       int (*write)(struct rockchip_iodomain_supply *supply, int uV);
> +};
> +
>  struct rockchip_iodomain {
>         struct device *dev;
>         struct regmap *grf;
>         const struct rockchip_iodomain_soc_data *soc_data;
>         struct rockchip_iodomain_supply supplies[MAX_SUPPLIES];
> +       int (*write)(struct rockchip_iodomain_supply *supply, int uV);
>  };
>
> +static int rk3568_iodomain_write(struct rockchip_iodomain_supply *supply, int uV)
> +{
> +       struct rockchip_iodomain *iod = supply->iod;
> +       u32 is_3v3 = uV > MAX_VOLTAGE_1_8;
> +       u32 val0, val1;
> +       int b;
> +
> +       switch (supply->idx) {
> +       case 0: /* pmuio1 */
> +               break;
> +       case 1: /* pmuio2 */
> +               b = supply->idx;
> +               val0 = BIT(16 + b) | (is_3v3 ? 0 : BIT(b));
> +               b = supply->idx + 4;
> +               val1 = BIT(16 + b) | (is_3v3 ? BIT(b) : 0);
> +
> +               regmap_write(iod->grf, RK3568_PMU_GRF_IO_VSEL2, val0);
> +               regmap_write(iod->grf, RK3568_PMU_GRF_IO_VSEL2, val1);
> +               break;
> +       case 3: /* vccio2 */
> +               break;
> +       case 2: /* vccio1 */
> +       case 4: /* vccio3 */
> +       case 5: /* vccio4 */
> +       case 6: /* vccio5 */
> +       case 7: /* vccio6 */
> +       case 8: /* vccio7 */
> +               b = supply->idx - 1;
> +               val0 = BIT(16 + b) | (is_3v3 ? 0 : BIT(b));
> +               val1 = BIT(16 + b) | (is_3v3 ? BIT(b) : 0);
> +
> +               regmap_write(iod->grf, RK3568_PMU_GRF_IO_VSEL0, val0);
> +               regmap_write(iod->grf, RK3568_PMU_GRF_IO_VSEL1, val1);
> +               break;
> +       default:
> +               return -EINVAL;
> +       };
> +
> +       return 0;
> +}
> +
>  static int rockchip_iodomain_write(struct rockchip_iodomain_supply *supply,
>                                    int uV)
>  {
> @@ -136,7 +183,7 @@ static int rockchip_iodomain_notify(struct notifier_block *nb,
>                         return NOTIFY_BAD;
>         }
>
> -       ret = rockchip_iodomain_write(supply, uV);
> +       ret = supply->iod->write(supply, uV);
>         if (ret && event == REGULATOR_EVENT_PRE_VOLTAGE_CHANGE)
>                 return NOTIFY_BAD;
>
> @@ -398,6 +445,22 @@ static const struct rockchip_iodomain_soc_data soc_data_rk3399_pmu = {
>         .init = rk3399_pmu_iodomain_init,
>  };
>
> +static const struct rockchip_iodomain_soc_data soc_data_rk3568_pmu = {
> +       .grf_offset = 0x140,
> +       .supply_names = {
> +               "pmuio1",
> +               "pmuio2",
> +               "vccio1",
> +               "vccio2",
> +               "vccio3",
> +               "vccio4",
> +               "vccio5",
> +               "vccio6",
> +               "vccio7",
> +       },
> +       .write = rk3568_iodomain_write,
> +};
> +
>  static const struct rockchip_iodomain_soc_data soc_data_rv1108 = {
>         .grf_offset = 0x404,
>         .supply_names = {
> @@ -469,6 +532,10 @@ static const struct of_device_id rockchip_iodomain_match[] = {
>                 .compatible = "rockchip,rk3399-pmu-io-voltage-domain",
>                 .data = &soc_data_rk3399_pmu
>         },
> +       {
> +               .compatible = "rockchip,rk3568-pmu-io-voltage-domain",
> +               .data = &soc_data_rk3568_pmu
> +       },
>         {
>                 .compatible = "rockchip,rv1108-io-voltage-domain",
>                 .data = &soc_data_rv1108
> @@ -502,6 +569,11 @@ static int rockchip_iodomain_probe(struct platform_device *pdev)
>         match = of_match_node(rockchip_iodomain_match, np);
>         iod->soc_data = match->data;
>
> +       if (iod->soc_data->write)
> +               iod->write = iod->soc_data->write;
> +       else
> +               iod->write = rockchip_iodomain_write;
> +
>         parent = pdev->dev.parent;
>         if (parent && parent->of_node) {
>                 iod->grf = syscon_node_to_regmap(parent->of_node);
> @@ -562,7 +634,7 @@ static int rockchip_iodomain_probe(struct platform_device *pdev)
>                 supply->reg = reg;
>                 supply->nb.notifier_call = rockchip_iodomain_notify;
>
> -               ret = rockchip_iodomain_write(supply, uV);
> +               ret = iod->write(supply, uV);
>                 if (ret) {
>                         supply->reg = NULL;
>                         goto unreg_notify;
> --
> 2.17.1
>

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

Re: [PATCH v3 2/7] soc: rockchip: io-domain: add rk3568 support

[Robin Murphy]

On 2021-08-05 13:01, Michael Riesch wrote:
> From: Jianqun Xu <jay.xu@rock-chips.com>
> 
> The io-domain registers on RK3568 SoCs have three separated bits to
> enable/disable the 1.8v/2.5v/3.3v power.
> 
> This patch make the write to be a operation, allow rk3568 uses a private
> register set function.
> 
> Since the 2.5v is not used on RK3568, so the driver only set

FWIW, this seems at odds with what the first paragraph says - can anyone 
clarify what exactly "not used" means here? Is it that the I/O domain 
controller has been redesigned to support more than two logic levels on 
the new generation of SoCs, but RK3568's I/O pads still only physically 
support 1.8v and 3.3v; or is it that it *can* support 2.5v as well but 
no currently-known RK3568-based designs use that?

In the former case it's just a wording issue in the commit message, but 
in the latter it's arguably worth implementing support now for the sake 
of future compatibility.

Robin.

> 1.8v [enable] + 3.3v [disable] for 1.8v mode
> 1.8v [disable] + 3.3v [enable] for 3.3v mode
> 
> There is not register order requirement which has been cleared by our IC
> team.
> 
> Signed-off-by: Jianqun Xu <jay.xu@rock-chips.com>
> ---
>   drivers/soc/rockchip/io-domain.c | 88 +++++++++++++++++++++++++++++---
>   1 file changed, 80 insertions(+), 8 deletions(-)
> 
> diff --git a/drivers/soc/rockchip/io-domain.c b/drivers/soc/rockchip/io-domain.c
> index cf8182fc3642..13c446fd33a9 100644
> --- a/drivers/soc/rockchip/io-domain.c
> +++ b/drivers/soc/rockchip/io-domain.c
> @@ -51,13 +51,11 @@
>   #define RK3399_PMUGRF_CON0_VSEL		BIT(8)
>   #define RK3399_PMUGRF_VSEL_SUPPLY_NUM	9
>   
> -struct rockchip_iodomain;
> +#define RK3568_PMU_GRF_IO_VSEL0		(0x0140)
> +#define RK3568_PMU_GRF_IO_VSEL1		(0x0144)
> +#define RK3568_PMU_GRF_IO_VSEL2		(0x0148)
>   
> -struct rockchip_iodomain_soc_data {
> -	int grf_offset;
> -	const char *supply_names[MAX_SUPPLIES];
> -	void (*init)(struct rockchip_iodomain *iod);
> -};
> +struct rockchip_iodomain;
>   
>   struct rockchip_iodomain_supply {
>   	struct rockchip_iodomain *iod;
> @@ -66,13 +64,62 @@ struct rockchip_iodomain_supply {
>   	int idx;
>   };
>   
> +struct rockchip_iodomain_soc_data {
> +	int grf_offset;
> +	const char *supply_names[MAX_SUPPLIES];
> +	void (*init)(struct rockchip_iodomain *iod);
> +	int (*write)(struct rockchip_iodomain_supply *supply, int uV);
> +};
> +
>   struct rockchip_iodomain {
>   	struct device *dev;
>   	struct regmap *grf;
>   	const struct rockchip_iodomain_soc_data *soc_data;
>   	struct rockchip_iodomain_supply supplies[MAX_SUPPLIES];
> +	int (*write)(struct rockchip_iodomain_supply *supply, int uV);
>   };
>   
> +static int rk3568_iodomain_write(struct rockchip_iodomain_supply *supply, int uV)
> +{
> +	struct rockchip_iodomain *iod = supply->iod;
> +	u32 is_3v3 = uV > MAX_VOLTAGE_1_8;
> +	u32 val0, val1;
> +	int b;
> +
> +	switch (supply->idx) {
> +	case 0: /* pmuio1 */
> +		break;
> +	case 1: /* pmuio2 */
> +		b = supply->idx;
> +		val0 = BIT(16 + b) | (is_3v3 ? 0 : BIT(b));
> +		b = supply->idx + 4;
> +		val1 = BIT(16 + b) | (is_3v3 ? BIT(b) : 0);
> +
> +		regmap_write(iod->grf, RK3568_PMU_GRF_IO_VSEL2, val0);
> +		regmap_write(iod->grf, RK3568_PMU_GRF_IO_VSEL2, val1);
> +		break;
> +	case 3: /* vccio2 */
> +		break;
> +	case 2: /* vccio1 */
> +	case 4: /* vccio3 */
> +	case 5: /* vccio4 */
> +	case 6: /* vccio5 */
> +	case 7: /* vccio6 */
> +	case 8: /* vccio7 */
> +		b = supply->idx - 1;
> +		val0 = BIT(16 + b) | (is_3v3 ? 0 : BIT(b));
> +		val1 = BIT(16 + b) | (is_3v3 ? BIT(b) : 0);
> +
> +		regmap_write(iod->grf, RK3568_PMU_GRF_IO_VSEL0, val0);
> +		regmap_write(iod->grf, RK3568_PMU_GRF_IO_VSEL1, val1);
> +		break;
> +	default:
> +		return -EINVAL;
> +	};
> +
> +	return 0;
> +}
> +
>   static int rockchip_iodomain_write(struct rockchip_iodomain_supply *supply,
>   				   int uV)
>   {
> @@ -136,7 +183,7 @@ static int rockchip_iodomain_notify(struct notifier_block *nb,
>   			return NOTIFY_BAD;
>   	}
>   
> -	ret = rockchip_iodomain_write(supply, uV);
> +	ret = supply->iod->write(supply, uV);
>   	if (ret && event == REGULATOR_EVENT_PRE_VOLTAGE_CHANGE)
>   		return NOTIFY_BAD;
>   
> @@ -398,6 +445,22 @@ static const struct rockchip_iodomain_soc_data soc_data_rk3399_pmu = {
>   	.init = rk3399_pmu_iodomain_init,
>   };
>   
> +static const struct rockchip_iodomain_soc_data soc_data_rk3568_pmu = {
> +	.grf_offset = 0x140,
> +	.supply_names = {
> +		"pmuio1",
> +		"pmuio2",
> +		"vccio1",
> +		"vccio2",
> +		"vccio3",
> +		"vccio4",
> +		"vccio5",
> +		"vccio6",
> +		"vccio7",
> +	},
> +	.write = rk3568_iodomain_write,
> +};
> +
>   static const struct rockchip_iodomain_soc_data soc_data_rv1108 = {
>   	.grf_offset = 0x404,
>   	.supply_names = {
> @@ -469,6 +532,10 @@ static const struct of_device_id rockchip_iodomain_match[] = {
>   		.compatible = "rockchip,rk3399-pmu-io-voltage-domain",
>   		.data = &soc_data_rk3399_pmu
>   	},
> +	{
> +		.compatible = "rockchip,rk3568-pmu-io-voltage-domain",
> +		.data = &soc_data_rk3568_pmu
> +	},
>   	{
>   		.compatible = "rockchip,rv1108-io-voltage-domain",
>   		.data = &soc_data_rv1108
> @@ -502,6 +569,11 @@ static int rockchip_iodomain_probe(struct platform_device *pdev)
>   	match = of_match_node(rockchip_iodomain_match, np);
>   	iod->soc_data = match->data;
>   
> +	if (iod->soc_data->write)
> +		iod->write = iod->soc_data->write;
> +	else
> +		iod->write = rockchip_iodomain_write;
> +
>   	parent = pdev->dev.parent;
>   	if (parent && parent->of_node) {
>   		iod->grf = syscon_node_to_regmap(parent->of_node);
> @@ -562,7 +634,7 @@ static int rockchip_iodomain_probe(struct platform_device *pdev)
>   		supply->reg = reg;
>   		supply->nb.notifier_call = rockchip_iodomain_notify;
>   
> -		ret = rockchip_iodomain_write(supply, uV);
> +		ret = iod->write(supply, uV);
>   		if (ret) {
>   			supply->reg = NULL;
>   			goto unreg_notify;
> 

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

Re: [PATCH v3 2/7] soc: rockchip: io-domain: add rk3568 support

[Heiko Stübner]

Hi Robin,

Am Donnerstag, 5. August 2021, 18:27:36 CEST schrieb Robin Murphy:
> On 2021-08-05 13:01, Michael Riesch wrote:
> > From: Jianqun Xu <jay.xu@rock-chips.com>
> > 
> > The io-domain registers on RK3568 SoCs have three separated bits to
> > enable/disable the 1.8v/2.5v/3.3v power.
> > 
> > This patch make the write to be a operation, allow rk3568 uses a private
> > register set function.
> > 
> > Since the 2.5v is not used on RK3568, so the driver only set
> 
> FWIW, this seems at odds with what the first paragraph says - can anyone 
> clarify what exactly "not used" means here? Is it that the I/O domain 
> controller has been redesigned to support more than two logic levels on 
> the new generation of SoCs, but RK3568's I/O pads still only physically 
> support 1.8v and 3.3v; or is it that it *can* support 2.5v as well but 
> no currently-known RK3568-based designs use that?
> 
> In the former case it's just a wording issue in the commit message, but 
> in the latter it's arguably worth implementing support now for the sake 
> of future compatibility.

I hadn't looked that deeply into the rk356x io-domain config, but at least
on a register level in the TRM it seems there are separate bits for
"3.3V control", "2.5V control", "1.8V control" [0] for each io-domain.

Of course the documentation is otherwise somewhat sparse.

Maybe Jay or Kever [added] can explain a bit more about the 3 voltage
levels.


In general though, I tend to find the approach good enough for now.

Especially as the io-domain stuff is always said to "can cause damage
to the soc if used incorrectly" and it looks like nobody (including
Rockchip) seems to have actual hardware using these 2.5V levels right now.

So having code in there that no-one ever tested doesn't feel too good ;-)

Adding this later when needed should be somewhat easy, as it really only
needs adding of handling that 3rd control bit per domain.


Heiko



[0] what happens if none of the 3 is active? ;-)


> 
> Robin.
> 
> > 1.8v [enable] + 3.3v [disable] for 1.8v mode
> > 1.8v [disable] + 3.3v [enable] for 3.3v mode
> > 
> > There is not register order requirement which has been cleared by our IC
> > team.
> > 
> > Signed-off-by: Jianqun Xu <jay.xu@rock-chips.com>
> > ---
> >   drivers/soc/rockchip/io-domain.c | 88 +++++++++++++++++++++++++++++---
> >   1 file changed, 80 insertions(+), 8 deletions(-)
> > 
> > diff --git a/drivers/soc/rockchip/io-domain.c b/drivers/soc/rockchip/io-domain.c
> > index cf8182fc3642..13c446fd33a9 100644
> > --- a/drivers/soc/rockchip/io-domain.c
> > +++ b/drivers/soc/rockchip/io-domain.c
> > @@ -51,13 +51,11 @@
> >   #define RK3399_PMUGRF_CON0_VSEL		BIT(8)
> >   #define RK3399_PMUGRF_VSEL_SUPPLY_NUM	9
> >   
> > -struct rockchip_iodomain;
> > +#define RK3568_PMU_GRF_IO_VSEL0		(0x0140)
> > +#define RK3568_PMU_GRF_IO_VSEL1		(0x0144)
> > +#define RK3568_PMU_GRF_IO_VSEL2		(0x0148)
> >   
> > -struct rockchip_iodomain_soc_data {
> > -	int grf_offset;
> > -	const char *supply_names[MAX_SUPPLIES];
> > -	void (*init)(struct rockchip_iodomain *iod);
> > -};
> > +struct rockchip_iodomain;
> >   
> >   struct rockchip_iodomain_supply {
> >   	struct rockchip_iodomain *iod;
> > @@ -66,13 +64,62 @@ struct rockchip_iodomain_supply {
> >   	int idx;
> >   };
> >   
> > +struct rockchip_iodomain_soc_data {
> > +	int grf_offset;
> > +	const char *supply_names[MAX_SUPPLIES];
> > +	void (*init)(struct rockchip_iodomain *iod);
> > +	int (*write)(struct rockchip_iodomain_supply *supply, int uV);
> > +};
> > +
> >   struct rockchip_iodomain {
> >   	struct device *dev;
> >   	struct regmap *grf;
> >   	const struct rockchip_iodomain_soc_data *soc_data;
> >   	struct rockchip_iodomain_supply supplies[MAX_SUPPLIES];
> > +	int (*write)(struct rockchip_iodomain_supply *supply, int uV);
> >   };
> >   
> > +static int rk3568_iodomain_write(struct rockchip_iodomain_supply *supply, int uV)
> > +{
> > +	struct rockchip_iodomain *iod = supply->iod;
> > +	u32 is_3v3 = uV > MAX_VOLTAGE_1_8;
> > +	u32 val0, val1;
> > +	int b;
> > +
> > +	switch (supply->idx) {
> > +	case 0: /* pmuio1 */
> > +		break;
> > +	case 1: /* pmuio2 */
> > +		b = supply->idx;
> > +		val0 = BIT(16 + b) | (is_3v3 ? 0 : BIT(b));
> > +		b = supply->idx + 4;
> > +		val1 = BIT(16 + b) | (is_3v3 ? BIT(b) : 0);
> > +
> > +		regmap_write(iod->grf, RK3568_PMU_GRF_IO_VSEL2, val0);
> > +		regmap_write(iod->grf, RK3568_PMU_GRF_IO_VSEL2, val1);
> > +		break;
> > +	case 3: /* vccio2 */
> > +		break;
> > +	case 2: /* vccio1 */
> > +	case 4: /* vccio3 */
> > +	case 5: /* vccio4 */
> > +	case 6: /* vccio5 */
> > +	case 7: /* vccio6 */
> > +	case 8: /* vccio7 */
> > +		b = supply->idx - 1;
> > +		val0 = BIT(16 + b) | (is_3v3 ? 0 : BIT(b));
> > +		val1 = BIT(16 + b) | (is_3v3 ? BIT(b) : 0);
> > +
> > +		regmap_write(iod->grf, RK3568_PMU_GRF_IO_VSEL0, val0);
> > +		regmap_write(iod->grf, RK3568_PMU_GRF_IO_VSEL1, val1);
> > +		break;
> > +	default:
> > +		return -EINVAL;
> > +	};
> > +
> > +	return 0;
> > +}
> > +
> >   static int rockchip_iodomain_write(struct rockchip_iodomain_supply *supply,
> >   				   int uV)
> >   {
> > @@ -136,7 +183,7 @@ static int rockchip_iodomain_notify(struct notifier_block *nb,
> >   			return NOTIFY_BAD;
> >   	}
> >   
> > -	ret = rockchip_iodomain_write(supply, uV);
> > +	ret = supply->iod->write(supply, uV);
> >   	if (ret && event == REGULATOR_EVENT_PRE_VOLTAGE_CHANGE)
> >   		return NOTIFY_BAD;
> >   
> > @@ -398,6 +445,22 @@ static const struct rockchip_iodomain_soc_data soc_data_rk3399_pmu = {
> >   	.init = rk3399_pmu_iodomain_init,
> >   };
> >   
> > +static const struct rockchip_iodomain_soc_data soc_data_rk3568_pmu = {
> > +	.grf_offset = 0x140,
> > +	.supply_names = {
> > +		"pmuio1",
> > +		"pmuio2",
> > +		"vccio1",
> > +		"vccio2",
> > +		"vccio3",
> > +		"vccio4",
> > +		"vccio5",
> > +		"vccio6",
> > +		"vccio7",
> > +	},
> > +	.write = rk3568_iodomain_write,
> > +};
> > +
> >   static const struct rockchip_iodomain_soc_data soc_data_rv1108 = {
> >   	.grf_offset = 0x404,
> >   	.supply_names = {
> > @@ -469,6 +532,10 @@ static const struct of_device_id rockchip_iodomain_match[] = {
> >   		.compatible = "rockchip,rk3399-pmu-io-voltage-domain",
> >   		.data = &soc_data_rk3399_pmu
> >   	},
> > +	{
> > +		.compatible = "rockchip,rk3568-pmu-io-voltage-domain",
> > +		.data = &soc_data_rk3568_pmu
> > +	},
> >   	{
> >   		.compatible = "rockchip,rv1108-io-voltage-domain",
> >   		.data = &soc_data_rv1108
> > @@ -502,6 +569,11 @@ static int rockchip_iodomain_probe(struct platform_device *pdev)
> >   	match = of_match_node(rockchip_iodomain_match, np);
> >   	iod->soc_data = match->data;
> >   
> > +	if (iod->soc_data->write)
> > +		iod->write = iod->soc_data->write;
> > +	else
> > +		iod->write = rockchip_iodomain_write;
> > +
> >   	parent = pdev->dev.parent;
> >   	if (parent && parent->of_node) {
> >   		iod->grf = syscon_node_to_regmap(parent->of_node);
> > @@ -562,7 +634,7 @@ static int rockchip_iodomain_probe(struct platform_device *pdev)
> >   		supply->reg = reg;
> >   		supply->nb.notifier_call = rockchip_iodomain_notify;
> >   
> > -		ret = rockchip_iodomain_write(supply, uV);
> > +		ret = iod->write(supply, uV);
> >   		if (ret) {
> >   			supply->reg = NULL;
> >   			goto unreg_notify;
> > 
> 





_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

Re: Re: [PATCH v3 2/7] soc: rockchip: io-domain: add rk3568 support

[jay.xu]

Hi Heiko and Robin

--------------
jay.xu@rock-chips.com
>Hi Robin,
>
>Am Donnerstag, 5. August 2021, 18:27:36 CEST schrieb Robin Murphy:
>> On 2021-08-05 13:01, Michael Riesch wrote:
>> > From: Jianqun Xu <jay.xu@rock-chips.com>
>> >
>> > The io-domain registers on RK3568 SoCs have three separated bits to
>> > enable/disable the 1.8v/2.5v/3.3v power.
>> >
>> > This patch make the write to be a operation, allow rk3568 uses a private
>> > register set function.
>> >
>> > Since the 2.5v is not used on RK3568, so the driver only set
>>
>> FWIW, this seems at odds with what the first paragraph says - can anyone
>> clarify what exactly "not used" means here? Is it that the I/O domain
>> controller has been redesigned to support more than two logic levels on
>> the new generation of SoCs, but RK3568's I/O pads still only physically
>> support 1.8v and 3.3v; or is it that it *can* support 2.5v as well but
>> no currently-known RK3568-based designs use that?
>>
>> In the former case it's just a wording issue in the commit message, but
>> in the latter it's arguably worth implementing support now for the sake
>> of future compatibility.
>
>I hadn't looked that deeply into the rk356x io-domain config, but at least
>on a register level in the TRM it seems there are separate bits for
>"3.3V control", "2.5V control", "1.8V control" [0] for each io-domain.
>
>Of course the documentation is otherwise somewhat sparse.
>
>Maybe Jay or Kever [added] can explain a bit more about the 3 voltage
>levels.
>
>
>In general though, I tend to find the approach good enough for now.
>
>Especially as the io-domain stuff is always said to "can cause damage
>to the soc if used incorrectly" and it looks like nobody (including
>Rockchip) seems to have actual hardware using these 2.5V levels right now.
>
>So having code in there that no-one ever tested doesn't feel too good ;-)
> 
yes

about the 3bit

case     V33  V25  V18       result
0          0      0       0           IO safe, but cannot work
1          0      0       1           IO require 1.8V, should < 1.98V, otherwise IO may damage
2          0      1       0           IO require 2.5V, should < 2.75V, otherwise IO may damage
3          0      1       1           Invalid state, should avoid
4          1      0       0           IO require 3.3V, should < 3.63V, otherwise IO may damage
5          1      0       1           IO require 1.8V, should < 1.98V, otherwise IO may damage
6          1      1       0           IO require 2.5V, should < 2.75V, otherwise IO may damage
7          1      1       1           Invalid state, should avoid

>Adding this later when needed should be somewhat easy, as it really only
>needs adding of handling that 3rd control bit per domain.
>
>
>Heiko
>
>
>
>[0] what happens if none of the 3 is active? ;-)
>
>
>>
>> Robin.
>>
>> > 1.8v [enable] + 3.3v [disable] for 1.8v mode
>> > 1.8v [disable] + 3.3v [enable] for 3.3v mode
>> >
>> > There is not register order requirement which has been cleared by our IC
>> > team.
>> >
>> > Signed-off-by: Jianqun Xu <jay.xu@rock-chips.com>
>> > ---
>> >   drivers/soc/rockchip/io-domain.c | 88 +++++++++++++++++++++++++++++---
>> >   1 file changed, 80 insertions(+), 8 deletions(-)
>> >
>> > diff --git a/drivers/soc/rockchip/io-domain.c b/drivers/soc/rockchip/io-domain.c
>> > index cf8182fc3642..13c446fd33a9 100644
>> > --- a/drivers/soc/rockchip/io-domain.c
>> > +++ b/drivers/soc/rockchip/io-domain.c
>> > @@ -51,13 +51,11 @@
>> >   #define RK3399_PMUGRF_CON0_VSEL	BIT(8)
>> >   #define RK3399_PMUGRF_VSEL_SUPPLY_NUM	9
>> >  
>> > -struct rockchip_iodomain;
>> > +#define RK3568_PMU_GRF_IO_VSEL0	(0x0140)
>> > +#define RK3568_PMU_GRF_IO_VSEL1	(0x0144)
>> > +#define RK3568_PMU_GRF_IO_VSEL2	(0x0148)
>> >  
>> > -struct rockchip_iodomain_soc_data {
>> > -	int grf_offset;
>> > -	const char *supply_names[MAX_SUPPLIES];
>> > -	void (*init)(struct rockchip_iodomain *iod);
>> > -};
>> > +struct rockchip_iodomain;
>> >  
>> >   struct rockchip_iodomain_supply {
>> >   struct rockchip_iodomain *iod;
>> > @@ -66,13 +64,62 @@ struct rockchip_iodomain_supply {
>> >   int idx;
>> >   };
>> >  
>> > +struct rockchip_iodomain_soc_data {
>> > +	int grf_offset;
>> > +	const char *supply_names[MAX_SUPPLIES];
>> > +	void (*init)(struct rockchip_iodomain *iod);
>> > +	int (*write)(struct rockchip_iodomain_supply *supply, int uV);
>> > +};
>> > +
>> >   struct rockchip_iodomain {
>> >   struct device *dev;
>> >   struct regmap *grf;
>> >   const struct rockchip_iodomain_soc_data *soc_data;
>> >   struct rockchip_iodomain_supply supplies[MAX_SUPPLIES];
>> > +	int (*write)(struct rockchip_iodomain_supply *supply, int uV);
>> >   };
>> >  
>> > +static int rk3568_iodomain_write(struct rockchip_iodomain_supply *supply, int uV)
>> > +{
>> > +	struct rockchip_iodomain *iod = supply->iod;
>> > +	u32 is_3v3 = uV > MAX_VOLTAGE_1_8;
>> > +	u32 val0, val1;
>> > +	int b;
>> > +
>> > +	switch (supply->idx) {
>> > +	case 0: /* pmuio1 */
>> > +	break;
>> > +	case 1: /* pmuio2 */
>> > +	b = supply->idx;
>> > +	val0 = BIT(16 + b) | (is_3v3 ? 0 : BIT(b));
>> > +	b = supply->idx + 4;
>> > +	val1 = BIT(16 + b) | (is_3v3 ? BIT(b) : 0);
>> > +
>> > +	regmap_write(iod->grf, RK3568_PMU_GRF_IO_VSEL2, val0);
>> > +	regmap_write(iod->grf, RK3568_PMU_GRF_IO_VSEL2, val1);
>> > +	break;
>> > +	case 3: /* vccio2 */
>> > +	break;
>> > +	case 2: /* vccio1 */
>> > +	case 4: /* vccio3 */
>> > +	case 5: /* vccio4 */
>> > +	case 6: /* vccio5 */
>> > +	case 7: /* vccio6 */
>> > +	case 8: /* vccio7 */
>> > +	b = supply->idx - 1;
>> > +	val0 = BIT(16 + b) | (is_3v3 ? 0 : BIT(b));
>> > +	val1 = BIT(16 + b) | (is_3v3 ? BIT(b) : 0);
>> > +
>> > +	regmap_write(iod->grf, RK3568_PMU_GRF_IO_VSEL0, val0);
>> > +	regmap_write(iod->grf, RK3568_PMU_GRF_IO_VSEL1, val1);
>> > +	break;
>> > +	default:
>> > +	return -EINVAL;
>> > +	};
>> > +
>> > +	return 0;
>> > +}
>> > +
>> >   static int rockchip_iodomain_write(struct rockchip_iodomain_supply *supply,
>> >      int uV)
>> >   {
>> > @@ -136,7 +183,7 @@ static int rockchip_iodomain_notify(struct notifier_block *nb,
>> >   return NOTIFY_BAD;
>> >   }
>> >  
>> > -	ret = rockchip_iodomain_write(supply, uV);
>> > +	ret = supply->iod->write(supply, uV);
>> >   if (ret && event == REGULATOR_EVENT_PRE_VOLTAGE_CHANGE)
>> >   return NOTIFY_BAD;
>> >  
>> > @@ -398,6 +445,22 @@ static const struct rockchip_iodomain_soc_data soc_data_rk3399_pmu = {
>> >   .init = rk3399_pmu_iodomain_init,
>> >   };
>> >  
>> > +static const struct rockchip_iodomain_soc_data soc_data_rk3568_pmu = {
>> > +	.grf_offset = 0x140,
>> > +	.supply_names = {
>> > +	"pmuio1",
>> > +	"pmuio2",
>> > +	"vccio1",
>> > +	"vccio2",
>> > +	"vccio3",
>> > +	"vccio4",
>> > +	"vccio5",
>> > +	"vccio6",
>> > +	"vccio7",
>> > +	},
>> > +	.write = rk3568_iodomain_write,
>> > +};
>> > +
>> >   static const struct rockchip_iodomain_soc_data soc_data_rv1108 = {
>> >   .grf_offset = 0x404,
>> >   .supply_names = {
>> > @@ -469,6 +532,10 @@ static const struct of_device_id rockchip_iodomain_match[] = {
>> >   .compatible = "rockchip,rk3399-pmu-io-voltage-domain",
>> >   .data = &soc_data_rk3399_pmu
>> >   },
>> > +	{
>> > +	.compatible = "rockchip,rk3568-pmu-io-voltage-domain",
>> > +	.data = &soc_data_rk3568_pmu
>> > +	},
>> >   {
>> >   .compatible = "rockchip,rv1108-io-voltage-domain",
>> >   .data = &soc_data_rv1108
>> > @@ -502,6 +569,11 @@ static int rockchip_iodomain_probe(struct platform_device *pdev)
>> >   match = of_match_node(rockchip_iodomain_match, np);
>> >   iod->soc_data = match->data;
>> >  
>> > +	if (iod->soc_data->write)
>> > +	iod->write = iod->soc_data->write;
>> > +	else
>> > +	iod->write = rockchip_iodomain_write;
>> > +
>> >   parent = pdev->dev.parent;
>> >   if (parent && parent->of_node) {
>> >   iod->grf = syscon_node_to_regmap(parent->of_node);
>> > @@ -562,7 +634,7 @@ static int rockchip_iodomain_probe(struct platform_device *pdev)
>> >   supply->reg = reg;
>> >   supply->nb.notifier_call = rockchip_iodomain_notify;
>> >  
>> > -	ret = rockchip_iodomain_write(supply, uV);
>> > +	ret = iod->write(supply, uV);
>> >   if (ret) {
>> >   supply->reg = NULL;
>> >   goto unreg_notify;
>> >
>>
>
>
>
>
>
>
>
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

Re: [PATCH v3 2/7] soc: rockchip: io-domain: add rk3568 support

[Robin Murphy]

On 2021-08-06 10:46, jay.xu@rock-chips.com wrote:
> Hi Heiko and Robin
> 
> --------------
> jay.xu@rock-chips.com
>> Hi Robin,
>>
>> Am Donnerstag, 5. August 2021, 18:27:36 CEST schrieb Robin Murphy:
>>> On 2021-08-05 13:01, Michael Riesch wrote:
>>>> From: Jianqun Xu <jay.xu@rock-chips.com>
>>>>
>>>> The io-domain registers on RK3568 SoCs have three separated bits to
>>>> enable/disable the 1.8v/2.5v/3.3v power.
>>>>
>>>> This patch make the write to be a operation, allow rk3568 uses a private
>>>> register set function.
>>>>
>>>> Since the 2.5v is not used on RK3568, so the driver only set
>>>
>>> FWIW, this seems at odds with what the first paragraph says - can anyone
>>> clarify what exactly "not used" means here? Is it that the I/O domain
>>> controller has been redesigned to support more than two logic levels on
>>> the new generation of SoCs, but RK3568's I/O pads still only physically
>>> support 1.8v and 3.3v; or is it that it *can* support 2.5v as well but
>>> no currently-known RK3568-based designs use that?
>>>
>>> In the former case it's just a wording issue in the commit message, but
>>> in the latter it's arguably worth implementing support now for the sake
>>> of future compatibility.
>>
>> I hadn't looked that deeply into the rk356x io-domain config, but at least
>> on a register level in the TRM it seems there are separate bits for
>> "3.3V control", "2.5V control", "1.8V control" [0] for each io-domain.
>>
>> Of course the documentation is otherwise somewhat sparse.
>>
>> Maybe Jay or Kever [added] can explain a bit more about the 3 voltage
>> levels.
>>
>>
>> In general though, I tend to find the approach good enough for now.
>>
>> Especially as the io-domain stuff is always said to "can cause damage
>> to the soc if used incorrectly" and it looks like nobody (including
>> Rockchip) seems to have actual hardware using these 2.5V levels right now.
>>
>> So having code in there that no-one ever tested doesn't feel too good ;-)
>>
> yes
> 
> about the 3bit
> 
> case     V33  V25  V18       result
> 0          0      0       0           IO safe, but cannot work
> 1          0      0       1           IO require 1.8V, should < 1.98V, otherwise IO may damage
> 2          0      1       0           IO require 2.5V, should < 2.75V, otherwise IO may damage
> 3          0      1       1           Invalid state, should avoid
> 4          1      0       0           IO require 3.3V, should < 3.63V, otherwise IO may damage
> 5          1      0       1           IO require 1.8V, should < 1.98V, otherwise IO may damage
> 6          1      1       0           IO require 2.5V, should < 2.75V, otherwise IO may damage
> 7          1      1       1           Invalid state, should avoid

Thanks Jay, that's useful to know.

Fair enough if it's the case that 2.5V mode hasn't been validated with 
the BSP kernel either - I'd have no objection to clarifying the commit 
message that way instead, I'm just a curious reviewer who noticed some 
ambiguity :)

>> Adding this later when needed should be somewhat easy, as it really only
>> needs adding of handling that 3rd control bit per domain.

I'm mostly just thinking ahead a year or two when board designers have 
ventured further away from the reference design and *are* using 2.5V 
external components, then a user puts an older stable mainline kernel on 
their board and starts tearing their hair out trying to figure out why 
things are flaky. For instance I recall from my RK3328 box that if the 
I/O domain setting for the GMAC is too high for the actual supply 
voltage (such that it never detects MDIO responses from the external 
phy) you end up getting an utterly nonsensical DMA error. In that case I 
eventually figured out (by chance) that it was because I didn't have the 
I/O domain driver enabled in my config, but it would be a whole other 
level of frustration if the driver appeared to be working but was 
quietly doing the wrong thing.

Cheers,
Robin.

>>
>>
>> Heiko
>>
>>
>>
>> [0] what happens if none of the 3 is active? ;-)
>>
>>
>>>
>>> Robin.
>>>
>>>> 1.8v [enable] + 3.3v [disable] for 1.8v mode
>>>> 1.8v [disable] + 3.3v [enable] for 3.3v mode
>>>>
>>>> There is not register order requirement which has been cleared by our IC
>>>> team.
>>>>
>>>> Signed-off-by: Jianqun Xu <jay.xu@rock-chips.com>
>>>> ---
>>>>     drivers/soc/rockchip/io-domain.c | 88 +++++++++++++++++++++++++++++---
>>>>     1 file changed, 80 insertions(+), 8 deletions(-)
>>>>
>>>> diff --git a/drivers/soc/rockchip/io-domain.c b/drivers/soc/rockchip/io-domain.c
>>>> index cf8182fc3642..13c446fd33a9 100644
>>>> --- a/drivers/soc/rockchip/io-domain.c
>>>> +++ b/drivers/soc/rockchip/io-domain.c
>>>> @@ -51,13 +51,11 @@
>>>>     #define RK3399_PMUGRF_CON0_VSEL	BIT(8)
>>>>     #define RK3399_PMUGRF_VSEL_SUPPLY_NUM	9
>>>>    
>>>> -struct rockchip_iodomain;
>>>> +#define RK3568_PMU_GRF_IO_VSEL0	(0x0140)
>>>> +#define RK3568_PMU_GRF_IO_VSEL1	(0x0144)
>>>> +#define RK3568_PMU_GRF_IO_VSEL2	(0x0148)
>>>>    
>>>> -struct rockchip_iodomain_soc_data {
>>>> -	int grf_offset;
>>>> -	const char *supply_names[MAX_SUPPLIES];
>>>> -	void (*init)(struct rockchip_iodomain *iod);
>>>> -};
>>>> +struct rockchip_iodomain;
>>>>    
>>>>     struct rockchip_iodomain_supply {
>>>>     struct rockchip_iodomain *iod;
>>>> @@ -66,13 +64,62 @@ struct rockchip_iodomain_supply {
>>>>     int idx;
>>>>     };
>>>>    
>>>> +struct rockchip_iodomain_soc_data {
>>>> +	int grf_offset;
>>>> +	const char *supply_names[MAX_SUPPLIES];
>>>> +	void (*init)(struct rockchip_iodomain *iod);
>>>> +	int (*write)(struct rockchip_iodomain_supply *supply, int uV);
>>>> +};
>>>> +
>>>>     struct rockchip_iodomain {
>>>>     struct device *dev;
>>>>     struct regmap *grf;
>>>>     const struct rockchip_iodomain_soc_data *soc_data;
>>>>     struct rockchip_iodomain_supply supplies[MAX_SUPPLIES];
>>>> +	int (*write)(struct rockchip_iodomain_supply *supply, int uV);
>>>>     };
>>>>    
>>>> +static int rk3568_iodomain_write(struct rockchip_iodomain_supply *supply, int uV)
>>>> +{
>>>> +	struct rockchip_iodomain *iod = supply->iod;
>>>> +	u32 is_3v3 = uV > MAX_VOLTAGE_1_8;
>>>> +	u32 val0, val1;
>>>> +	int b;
>>>> +
>>>> +	switch (supply->idx) {
>>>> +	case 0: /* pmuio1 */
>>>> +	break;
>>>> +	case 1: /* pmuio2 */
>>>> +	b = supply->idx;
>>>> +	val0 = BIT(16 + b) | (is_3v3 ? 0 : BIT(b));
>>>> +	b = supply->idx + 4;
>>>> +	val1 = BIT(16 + b) | (is_3v3 ? BIT(b) : 0);
>>>> +
>>>> +	regmap_write(iod->grf, RK3568_PMU_GRF_IO_VSEL2, val0);
>>>> +	regmap_write(iod->grf, RK3568_PMU_GRF_IO_VSEL2, val1);
>>>> +	break;
>>>> +	case 3: /* vccio2 */
>>>> +	break;
>>>> +	case 2: /* vccio1 */
>>>> +	case 4: /* vccio3 */
>>>> +	case 5: /* vccio4 */
>>>> +	case 6: /* vccio5 */
>>>> +	case 7: /* vccio6 */
>>>> +	case 8: /* vccio7 */
>>>> +	b = supply->idx - 1;
>>>> +	val0 = BIT(16 + b) | (is_3v3 ? 0 : BIT(b));
>>>> +	val1 = BIT(16 + b) | (is_3v3 ? BIT(b) : 0);
>>>> +
>>>> +	regmap_write(iod->grf, RK3568_PMU_GRF_IO_VSEL0, val0);
>>>> +	regmap_write(iod->grf, RK3568_PMU_GRF_IO_VSEL1, val1);
>>>> +	break;
>>>> +	default:
>>>> +	return -EINVAL;
>>>> +	};
>>>> +
>>>> +	return 0;
>>>> +}
>>>> +
>>>>     static int rockchip_iodomain_write(struct rockchip_iodomain_supply *supply,
>>>>        int uV)
>>>>     {
>>>> @@ -136,7 +183,7 @@ static int rockchip_iodomain_notify(struct notifier_block *nb,
>>>>     return NOTIFY_BAD;
>>>>     }
>>>>    
>>>> -	ret = rockchip_iodomain_write(supply, uV);
>>>> +	ret = supply->iod->write(supply, uV);
>>>>     if (ret && event == REGULATOR_EVENT_PRE_VOLTAGE_CHANGE)
>>>>     return NOTIFY_BAD;
>>>>    
>>>> @@ -398,6 +445,22 @@ static const struct rockchip_iodomain_soc_data soc_data_rk3399_pmu = {
>>>>     .init = rk3399_pmu_iodomain_init,
>>>>     };
>>>>    
>>>> +static const struct rockchip_iodomain_soc_data soc_data_rk3568_pmu = {
>>>> +	.grf_offset = 0x140,
>>>> +	.supply_names = {
>>>> +	"pmuio1",
>>>> +	"pmuio2",
>>>> +	"vccio1",
>>>> +	"vccio2",
>>>> +	"vccio3",
>>>> +	"vccio4",
>>>> +	"vccio5",
>>>> +	"vccio6",
>>>> +	"vccio7",
>>>> +	},
>>>> +	.write = rk3568_iodomain_write,
>>>> +};
>>>> +
>>>>     static const struct rockchip_iodomain_soc_data soc_data_rv1108 = {
>>>>     .grf_offset = 0x404,
>>>>     .supply_names = {
>>>> @@ -469,6 +532,10 @@ static const struct of_device_id rockchip_iodomain_match[] = {
>>>>     .compatible = "rockchip,rk3399-pmu-io-voltage-domain",
>>>>     .data = &soc_data_rk3399_pmu
>>>>     },
>>>> +	{
>>>> +	.compatible = "rockchip,rk3568-pmu-io-voltage-domain",
>>>> +	.data = &soc_data_rk3568_pmu
>>>> +	},
>>>>     {
>>>>     .compatible = "rockchip,rv1108-io-voltage-domain",
>>>>     .data = &soc_data_rv1108
>>>> @@ -502,6 +569,11 @@ static int rockchip_iodomain_probe(struct platform_device *pdev)
>>>>     match = of_match_node(rockchip_iodomain_match, np);
>>>>     iod->soc_data = match->data;
>>>>    
>>>> +	if (iod->soc_data->write)
>>>> +	iod->write = iod->soc_data->write;
>>>> +	else
>>>> +	iod->write = rockchip_iodomain_write;
>>>> +
>>>>     parent = pdev->dev.parent;
>>>>     if (parent && parent->of_node) {
>>>>     iod->grf = syscon_node_to_regmap(parent->of_node);
>>>> @@ -562,7 +634,7 @@ static int rockchip_iodomain_probe(struct platform_device *pdev)
>>>>     supply->reg = reg;
>>>>     supply->nb.notifier_call = rockchip_iodomain_notify;
>>>>    
>>>> -	ret = rockchip_iodomain_write(supply, uV);
>>>> +	ret = iod->write(supply, uV);
>>>>     if (ret) {
>>>>     supply->reg = NULL;
>>>>     goto unreg_notify;
>>>>
>>>
>>
>>
>>
>>
>>
>>
>>
> 

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

Re: [PATCH v3 2/7] soc: rockchip: io-domain: add rk3568 support

[Peter Geis]

On Fri, Aug 6, 2021 at 6:28 AM Robin Murphy <robin.murphy@arm.com> wrote:
>
> On 2021-08-06 10:46, jay.xu@rock-chips.com wrote:
> > Hi Heiko and Robin
> >
> > --------------
> > jay.xu@rock-chips.com
> >> Hi Robin,
> >>
> >> Am Donnerstag, 5. August 2021, 18:27:36 CEST schrieb Robin Murphy:
> >>> On 2021-08-05 13:01, Michael Riesch wrote:
> >>>> From: Jianqun Xu <jay.xu@rock-chips.com>
> >>>>
> >>>> The io-domain registers on RK3568 SoCs have three separated bits to
> >>>> enable/disable the 1.8v/2.5v/3.3v power.
> >>>>
> >>>> This patch make the write to be a operation, allow rk3568 uses a private
> >>>> register set function.
> >>>>
> >>>> Since the 2.5v is not used on RK3568, so the driver only set
> >>>
> >>> FWIW, this seems at odds with what the first paragraph says - can anyone
> >>> clarify what exactly "not used" means here? Is it that the I/O domain
> >>> controller has been redesigned to support more than two logic levels on
> >>> the new generation of SoCs, but RK3568's I/O pads still only physically
> >>> support 1.8v and 3.3v; or is it that it *can* support 2.5v as well but
> >>> no currently-known RK3568-based designs use that?
> >>>
> >>> In the former case it's just a wording issue in the commit message, but
> >>> in the latter it's arguably worth implementing support now for the sake
> >>> of future compatibility.
> >>
> >> I hadn't looked that deeply into the rk356x io-domain config, but at least
> >> on a register level in the TRM it seems there are separate bits for
> >> "3.3V control", "2.5V control", "1.8V control" [0] for each io-domain.
> >>
> >> Of course the documentation is otherwise somewhat sparse.
> >>
> >> Maybe Jay or Kever [added] can explain a bit more about the 3 voltage
> >> levels.
> >>
> >>
> >> In general though, I tend to find the approach good enough for now.
> >>
> >> Especially as the io-domain stuff is always said to "can cause damage
> >> to the soc if used incorrectly" and it looks like nobody (including
> >> Rockchip) seems to have actual hardware using these 2.5V levels right now.
> >>
> >> So having code in there that no-one ever tested doesn't feel too good ;-)
> >>
> > yes
> >
> > about the 3bit
> >
> > case     V33  V25  V18       result
> > 0          0      0       0           IO safe, but cannot work
> > 1          0      0       1           IO require 1.8V, should < 1.98V, otherwise IO may damage
> > 2          0      1       0           IO require 2.5V, should < 2.75V, otherwise IO may damage
> > 3          0      1       1           Invalid state, should avoid
> > 4          1      0       0           IO require 3.3V, should < 3.63V, otherwise IO may damage
> > 5          1      0       1           IO require 1.8V, should < 1.98V, otherwise IO may damage
> > 6          1      1       0           IO require 2.5V, should < 2.75V, otherwise IO may damage
> > 7          1      1       1           Invalid state, should avoid
>
> Thanks Jay, that's useful to know.
>
> Fair enough if it's the case that 2.5V mode hasn't been validated with
> the BSP kernel either - I'd have no objection to clarifying the commit
> message that way instead, I'm just a curious reviewer who noticed some
> ambiguity :)
>
> >> Adding this later when needed should be somewhat easy, as it really only
> >> needs adding of handling that 3rd control bit per domain.
>
> I'm mostly just thinking ahead a year or two when board designers have
> ventured further away from the reference design and *are* using 2.5V
> external components, then a user puts an older stable mainline kernel on
> their board and starts tearing their hair out trying to figure out why
> things are flaky. For instance I recall from my RK3328 box that if the
> I/O domain setting for the GMAC is too high for the actual supply
> voltage (such that it never detects MDIO responses from the external
> phy) you end up getting an utterly nonsensical DMA error. In that case I
> eventually figured out (by chance) that it was because I didn't have the
> I/O domain driver enabled in my config, but it would be a whole other
> level of frustration if the driver appeared to be working but was
> quietly doing the wrong thing.

I too have experienced the joys of io-domains breaking things.
Perhaps the driver should warn when the voltages aren't expected,
instead of when they are simply too high.

>
> Cheers,
> Robin.
>
> >>
> >>
> >> Heiko
> >>
> >>
> >>
> >> [0] what happens if none of the 3 is active? ;-)
> >>
> >>
> >>>
> >>> Robin.
> >>>
> >>>> 1.8v [enable] + 3.3v [disable] for 1.8v mode
> >>>> 1.8v [disable] + 3.3v [enable] for 3.3v mode
> >>>>
> >>>> There is not register order requirement which has been cleared by our IC
> >>>> team.
> >>>>
> >>>> Signed-off-by: Jianqun Xu <jay.xu@rock-chips.com>
> >>>> ---
> >>>>     drivers/soc/rockchip/io-domain.c | 88 +++++++++++++++++++++++++++++---
> >>>>     1 file changed, 80 insertions(+), 8 deletions(-)
> >>>>
> >>>> diff --git a/drivers/soc/rockchip/io-domain.c b/drivers/soc/rockchip/io-domain.c
> >>>> index cf8182fc3642..13c446fd33a9 100644
> >>>> --- a/drivers/soc/rockchip/io-domain.c
> >>>> +++ b/drivers/soc/rockchip/io-domain.c
> >>>> @@ -51,13 +51,11 @@
> >>>>     #define RK3399_PMUGRF_CON0_VSEL        BIT(8)
> >>>>     #define RK3399_PMUGRF_VSEL_SUPPLY_NUM  9
> >>>>
> >>>> -struct rockchip_iodomain;
> >>>> +#define RK3568_PMU_GRF_IO_VSEL0   (0x0140)
> >>>> +#define RK3568_PMU_GRF_IO_VSEL1   (0x0144)
> >>>> +#define RK3568_PMU_GRF_IO_VSEL2   (0x0148)
> >>>>
> >>>> -struct rockchip_iodomain_soc_data {
> >>>> -  int grf_offset;
> >>>> -  const char *supply_names[MAX_SUPPLIES];
> >>>> -  void (*init)(struct rockchip_iodomain *iod);
> >>>> -};
> >>>> +struct rockchip_iodomain;
> >>>>
> >>>>     struct rockchip_iodomain_supply {
> >>>>     struct rockchip_iodomain *iod;
> >>>> @@ -66,13 +64,62 @@ struct rockchip_iodomain_supply {
> >>>>     int idx;
> >>>>     };
> >>>>
> >>>> +struct rockchip_iodomain_soc_data {
> >>>> +  int grf_offset;
> >>>> +  const char *supply_names[MAX_SUPPLIES];
> >>>> +  void (*init)(struct rockchip_iodomain *iod);
> >>>> +  int (*write)(struct rockchip_iodomain_supply *supply, int uV);
> >>>> +};
> >>>> +
> >>>>     struct rockchip_iodomain {
> >>>>     struct device *dev;
> >>>>     struct regmap *grf;
> >>>>     const struct rockchip_iodomain_soc_data *soc_data;
> >>>>     struct rockchip_iodomain_supply supplies[MAX_SUPPLIES];
> >>>> +  int (*write)(struct rockchip_iodomain_supply *supply, int uV);
> >>>>     };
> >>>>
> >>>> +static int rk3568_iodomain_write(struct rockchip_iodomain_supply *supply, int uV)
> >>>> +{
> >>>> +  struct rockchip_iodomain *iod = supply->iod;
> >>>> +  u32 is_3v3 = uV > MAX_VOLTAGE_1_8;
> >>>> +  u32 val0, val1;
> >>>> +  int b;
> >>>> +
> >>>> +  switch (supply->idx) {
> >>>> +  case 0: /* pmuio1 */
> >>>> +  break;
> >>>> +  case 1: /* pmuio2 */
> >>>> +  b = supply->idx;
> >>>> +  val0 = BIT(16 + b) | (is_3v3 ? 0 : BIT(b));
> >>>> +  b = supply->idx + 4;
> >>>> +  val1 = BIT(16 + b) | (is_3v3 ? BIT(b) : 0);
> >>>> +
> >>>> +  regmap_write(iod->grf, RK3568_PMU_GRF_IO_VSEL2, val0);
> >>>> +  regmap_write(iod->grf, RK3568_PMU_GRF_IO_VSEL2, val1);
> >>>> +  break;
> >>>> +  case 3: /* vccio2 */
> >>>> +  break;
> >>>> +  case 2: /* vccio1 */
> >>>> +  case 4: /* vccio3 */
> >>>> +  case 5: /* vccio4 */
> >>>> +  case 6: /* vccio5 */
> >>>> +  case 7: /* vccio6 */
> >>>> +  case 8: /* vccio7 */
> >>>> +  b = supply->idx - 1;
> >>>> +  val0 = BIT(16 + b) | (is_3v3 ? 0 : BIT(b));
> >>>> +  val1 = BIT(16 + b) | (is_3v3 ? BIT(b) : 0);
> >>>> +
> >>>> +  regmap_write(iod->grf, RK3568_PMU_GRF_IO_VSEL0, val0);
> >>>> +  regmap_write(iod->grf, RK3568_PMU_GRF_IO_VSEL1, val1);
> >>>> +  break;
> >>>> +  default:
> >>>> +  return -EINVAL;
> >>>> +  };
> >>>> +
> >>>> +  return 0;
> >>>> +}
> >>>> +
> >>>>     static int rockchip_iodomain_write(struct rockchip_iodomain_supply *supply,
> >>>>        int uV)
> >>>>     {
> >>>> @@ -136,7 +183,7 @@ static int rockchip_iodomain_notify(struct notifier_block *nb,
> >>>>     return NOTIFY_BAD;
> >>>>     }
> >>>>
> >>>> -  ret = rockchip_iodomain_write(supply, uV);
> >>>> +  ret = supply->iod->write(supply, uV);
> >>>>     if (ret && event == REGULATOR_EVENT_PRE_VOLTAGE_CHANGE)
> >>>>     return NOTIFY_BAD;
> >>>>
> >>>> @@ -398,6 +445,22 @@ static const struct rockchip_iodomain_soc_data soc_data_rk3399_pmu = {
> >>>>     .init = rk3399_pmu_iodomain_init,
> >>>>     };
> >>>>
> >>>> +static const struct rockchip_iodomain_soc_data soc_data_rk3568_pmu = {
> >>>> +  .grf_offset = 0x140,
> >>>> +  .supply_names = {
> >>>> +  "pmuio1",
> >>>> +  "pmuio2",
> >>>> +  "vccio1",
> >>>> +  "vccio2",
> >>>> +  "vccio3",
> >>>> +  "vccio4",
> >>>> +  "vccio5",
> >>>> +  "vccio6",
> >>>> +  "vccio7",
> >>>> +  },
> >>>> +  .write = rk3568_iodomain_write,
> >>>> +};
> >>>> +
> >>>>     static const struct rockchip_iodomain_soc_data soc_data_rv1108 = {
> >>>>     .grf_offset = 0x404,
> >>>>     .supply_names = {
> >>>> @@ -469,6 +532,10 @@ static const struct of_device_id rockchip_iodomain_match[] = {
> >>>>     .compatible = "rockchip,rk3399-pmu-io-voltage-domain",
> >>>>     .data = &soc_data_rk3399_pmu
> >>>>     },
> >>>> +  {
> >>>> +  .compatible = "rockchip,rk3568-pmu-io-voltage-domain",
> >>>> +  .data = &soc_data_rk3568_pmu
> >>>> +  },
> >>>>     {
> >>>>     .compatible = "rockchip,rv1108-io-voltage-domain",
> >>>>     .data = &soc_data_rv1108
> >>>> @@ -502,6 +569,11 @@ static int rockchip_iodomain_probe(struct platform_device *pdev)
> >>>>     match = of_match_node(rockchip_iodomain_match, np);
> >>>>     iod->soc_data = match->data;
> >>>>
> >>>> +  if (iod->soc_data->write)
> >>>> +  iod->write = iod->soc_data->write;
> >>>> +  else
> >>>> +  iod->write = rockchip_iodomain_write;
> >>>> +
> >>>>     parent = pdev->dev.parent;
> >>>>     if (parent && parent->of_node) {
> >>>>     iod->grf = syscon_node_to_regmap(parent->of_node);
> >>>> @@ -562,7 +634,7 @@ static int rockchip_iodomain_probe(struct platform_device *pdev)
> >>>>     supply->reg = reg;
> >>>>     supply->nb.notifier_call = rockchip_iodomain_notify;
> >>>>
> >>>> -  ret = rockchip_iodomain_write(supply, uV);
> >>>> +  ret = iod->write(supply, uV);
> >>>>     if (ret) {
> >>>>     supply->reg = NULL;
> >>>>     goto unreg_notify;
> >>>>
> >>>
> >>
> >>
> >>
> >>
> >>
> >>
> >>
> >

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

Re: [PATCH v3 1/7] dt-bindings: power: add rk3568-pmu-io-domain support

[Rob Herring]

On Thu, 05 Aug 2021 14:01:01 +0200, Michael Riesch wrote:
> Add binding for the RK3568 along a SoC-specific description of
> voltage supplies.
> 
> Signed-off-by: Jianqun Xu <jay.xu@rock-chips.com>
> [add soc-specific section]
> Signed-off-by: Michael Riesch <michael.riesch@wolfvision.net>
> ---
> v3:
> - add missing compatible for the rk3568 to grf.yaml
> 
>  .../bindings/power/rockchip-io-domain.yaml    | 30 +++++++++++++++++++
>  .../devicetree/bindings/soc/rockchip/grf.yaml |  1 +
>  2 files changed, 31 insertions(+)
> 

Reviewed-by: Rob Herring <robh@kernel.org>

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

Re: [PATCH v3 0/7] arm64: dts: rockchip: rk3568-evb1-v10: add sd card support

[Heiko Stuebner]

On Thu, 5 Aug 2021 14:01:00 +0200, Michael Riesch wrote:
> This series enables the SD card reader on the RK3568 EVB1
> and completes the support for the on-board eMMC.
> 
> As the PMU IO domains are required, the patch series that
> introduces support for the RK3568 PMU IO domains [1] has been
> revised and integrated in this series.
> Additionally, the required voltage regulators of the RK809
> PMIC are enabled.
> 
> [...]

Applied, thanks!

[1/7] dt-bindings: power: add rk3568-pmu-io-domain support
      commit: fadbd4e7847905d61dd333a0d3d31654f4510bc6
[2/7] soc: rockchip: io-domain: add rk3568 support
      commit: 28b05a64e47cbceebb8a5f3f643033148d5c06c3
[3/7] arm64: dts: rockchip: enable io domains for rk356x
      commit: 2e9ce86bbea81022540ede98cac152df5566205e
[4/7] arm64: dts: rockchip: rk3568-evb1-v10: enable io domains
      commit: 915186bd99a55642ae77d7f9c46e295b3fd9dc1c
[5/7] arm64: dts: rockchip: rk3568-evb1-v10: add regulators of rk809 pmic
      commit: e3f6b997b6b17810583af79f458b35fc0a34d939
[6/7] arm64: dts: rockchip: rk3568-evb1-v10: add node for sd card
      commit: ef180dba76f583efc19c7d5f3d2809e0aa8856e8
[7/7] arm64: dts: rockchip: rk3568-evb1-v10: add pinctrl and alias to emmc node
      commit: eb8d07586e13fc7aa4ed68820240d36a03418193

Best regards,
-- 
Heiko Stuebner <heiko@sntech.de>

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

Re: Re: [PATCH v3 2/7] soc: rockchip: io-domain: add rk3568 support

[jay.xu]

Hi，
--------------
jay.xu@rock-chips.com
>On Fri, Aug 6, 2021 at 6:28 AM Robin Murphy <robin.murphy@arm.com> wrote:
>>
>> On 2021-08-06 10:46, jay.xu@rock-chips.com wrote:
>> > Hi Heiko and Robin
>> >
>> > --------------
>> > jay.xu@rock-chips.com
>> >> Hi Robin,
>> >>
>> >> Am Donnerstag, 5. August 2021, 18:27:36 CEST schrieb Robin Murphy:
>> >>> On 2021-08-05 13:01, Michael Riesch wrote:
>> >>>> From: Jianqun Xu <jay.xu@rock-chips.com>
>> >>>>
>> >>>> The io-domain registers on RK3568 SoCs have three separated bits to
>> >>>> enable/disable the 1.8v/2.5v/3.3v power.
>> >>>>
>> >>>> This patch make the write to be a operation, allow rk3568 uses a private
>> >>>> register set function.
>> >>>>
>> >>>> Since the 2.5v is not used on RK3568, so the driver only set
>> >>>
>> >>> FWIW, this seems at odds with what the first paragraph says - can anyone
>> >>> clarify what exactly "not used" means here? Is it that the I/O domain
>> >>> controller has been redesigned to support more than two logic levels on
>> >>> the new generation of SoCs, but RK3568's I/O pads still only physically
>> >>> support 1.8v and 3.3v; or is it that it *can* support 2.5v as well but
>> >>> no currently-known RK3568-based designs use that?
>> >>>
>> >>> In the former case it's just a wording issue in the commit message, but
>> >>> in the latter it's arguably worth implementing support now for the sake
>> >>> of future compatibility.
>> >>
>> >> I hadn't looked that deeply into the rk356x io-domain config, but at least
>> >> on a register level in the TRM it seems there are separate bits for
>> >> "3.3V control", "2.5V control", "1.8V control" [0] for each io-domain.
>> >>
>> >> Of course the documentation is otherwise somewhat sparse.
>> >>
>> >> Maybe Jay or Kever [added] can explain a bit more about the 3 voltage
>> >> levels.
>> >>
>> >>
>> >> In general though, I tend to find the approach good enough for now.
>> >>
>> >> Especially as the io-domain stuff is always said to "can cause damage
>> >> to the soc if used incorrectly" and it looks like nobody (including
>> >> Rockchip) seems to have actual hardware using these 2.5V levels right now.
>> >>
>> >> So having code in there that no-one ever tested doesn't feel too good ;-)
>> >>
>> > yes
>> >
>> > about the 3bit
>> >
>> > case     V33  V25  V18       result
>> > 0          0      0       0           IO safe, but cannot work
>> > 1          0      0       1           IO require 1.8V, should < 1.98V, otherwise IO may damage
>> > 2          0      1       0           IO require 2.5V, should < 2.75V, otherwise IO may damage
>> > 3          0      1       1           Invalid state, should avoid
>> > 4          1      0       0           IO require 3.3V, should < 3.63V, otherwise IO may damage
>> > 5          1      0       1           IO require 1.8V, should < 1.98V, otherwise IO may damage
>> > 6          1      1       0           IO require 2.5V, should < 2.75V, otherwise IO may damage
>> > 7          1      1       1           Invalid state, should avoid
>>
>> Thanks Jay, that's useful to know.
>>
>> Fair enough if it's the case that 2.5V mode hasn't been validated with
>> the BSP kernel either - I'd have no objection to clarifying the commit
>> message that way instead, I'm just a curious reviewer who noticed some
>> ambiguity :)
>>
>> >> Adding this later when needed should be somewhat easy, as it really only
>> >> needs adding of handling that 3rd control bit per domain.
>>
>> I'm mostly just thinking ahead a year or two when board designers have
>> ventured further away from the reference design and *are* using 2.5V
>> external components, then a user puts an older stable mainline kernel on
>> their board and starts tearing their hair out trying to figure out why
>> things are flaky. For instance I recall from my RK3328 box that if the
>> I/O domain setting for the GMAC is too high for the actual supply
>> voltage (such that it never detects MDIO responses from the external
>> phy) you end up getting an utterly nonsensical DMA error. In that case I
>> eventually figured out (by chance) that it was because I didn't have the
>> I/O domain driver enabled in my config, but it would be a whole other
>> level of frustration if the driver appeared to be working but was
>> quietly doing the wrong thing.
>
>I too have experienced the joys of io-domains breaking things.
>Perhaps the driver should warn when the voltages aren't expected,
>instead of when they are simply too high.
> 
The io-domain driver is so special, it is only rockchip soc driver, but it's so important for rockchip
system, lack of io-domain driver or wrong setting for system both breaking things

The one problem is lack of io-domain driver, since the dt node is defaultly be "disabled" in core.dtsi
If the board developer doesn't notice to enable it, the system will work without io-domain and can
hard to debug it.

So, could I summit a patch to set the dt node defaultly to be "okay" with empty property, and then
do a WARN when nothing property is found ?

>>
>> Cheers,
>> Robin.
>>
>> >>
>> >>
>> >> Heiko
>> >>
>> >>
>> >>
>> >> [0] what happens if none of the 3 is active? ;-)
>> >>
>> >>
>> >>>
>> >>> Robin.
>> >>>
>> >>>> 1.8v [enable] + 3.3v [disable] for 1.8v mode
>> >>>> 1.8v [disable] + 3.3v [enable] for 3.3v mode
>> >>>>
>> >>>> There is not register order requirement which has been cleared by our IC
>> >>>> team.
>> >>>>
>> >>>> Signed-off-by: Jianqun Xu <jay.xu@rock-chips.com>
>> >>>> ---
>> >>>>     drivers/soc/rockchip/io-domain.c | 88 +++++++++++++++++++++++++++++---
>> >>>>     1 file changed, 80 insertions(+), 8 deletions(-)
>> >>>>
>> >>>> diff --git a/drivers/soc/rockchip/io-domain.c b/drivers/soc/rockchip/io-domain.c
>> >>>> index cf8182fc3642..13c446fd33a9 100644
>> >>>> --- a/drivers/soc/rockchip/io-domain.c
>> >>>> +++ b/drivers/soc/rockchip/io-domain.c
>> >>>> @@ -51,13 +51,11 @@
>> >>>>     #define RK3399_PMUGRF_CON0_VSEL        BIT(8)
>> >>>>     #define RK3399_PMUGRF_VSEL_SUPPLY_NUM  9
>> >>>>
>> >>>> -struct rockchip_iodomain;
>> >>>> +#define RK3568_PMU_GRF_IO_VSEL0   (0x0140)
>> >>>> +#define RK3568_PMU_GRF_IO_VSEL1   (0x0144)
>> >>>> +#define RK3568_PMU_GRF_IO_VSEL2   (0x0148)
>> >>>>
>> >>>> -struct rockchip_iodomain_soc_data {
>> >>>> -  int grf_offset;
>> >>>> -  const char *supply_names[MAX_SUPPLIES];
>> >>>> -  void (*init)(struct rockchip_iodomain *iod);
>> >>>> -};
>> >>>> +struct rockchip_iodomain;
>> >>>>
>> >>>>     struct rockchip_iodomain_supply {
>> >>>>     struct rockchip_iodomain *iod;
>> >>>> @@ -66,13 +64,62 @@ struct rockchip_iodomain_supply {
>> >>>>     int idx;
>> >>>>     };
>> >>>>
>> >>>> +struct rockchip_iodomain_soc_data {
>> >>>> +  int grf_offset;
>> >>>> +  const char *supply_names[MAX_SUPPLIES];
>> >>>> +  void (*init)(struct rockchip_iodomain *iod);
>> >>>> +  int (*write)(struct rockchip_iodomain_supply *supply, int uV);
>> >>>> +};
>> >>>> +
>> >>>>     struct rockchip_iodomain {
>> >>>>     struct device *dev;
>> >>>>     struct regmap *grf;
>> >>>>     const struct rockchip_iodomain_soc_data *soc_data;
>> >>>>     struct rockchip_iodomain_supply supplies[MAX_SUPPLIES];
>> >>>> +  int (*write)(struct rockchip_iodomain_supply *supply, int uV);
>> >>>>     };
>> >>>>
>> >>>> +static int rk3568_iodomain_write(struct rockchip_iodomain_supply *supply, int uV)
>> >>>> +{
>> >>>> +  struct rockchip_iodomain *iod = supply->iod;
>> >>>> +  u32 is_3v3 = uV > MAX_VOLTAGE_1_8;
>> >>>> +  u32 val0, val1;
>> >>>> +  int b;
>> >>>> +
>> >>>> +  switch (supply->idx) {
>> >>>> +  case 0: /* pmuio1 */
>> >>>> +  break;
>> >>>> +  case 1: /* pmuio2 */
>> >>>> +  b = supply->idx;
>> >>>> +  val0 = BIT(16 + b) | (is_3v3 ? 0 : BIT(b));
>> >>>> +  b = supply->idx + 4;
>> >>>> +  val1 = BIT(16 + b) | (is_3v3 ? BIT(b) : 0);
>> >>>> +
>> >>>> +  regmap_write(iod->grf, RK3568_PMU_GRF_IO_VSEL2, val0);
>> >>>> +  regmap_write(iod->grf, RK3568_PMU_GRF_IO_VSEL2, val1);
>> >>>> +  break;
>> >>>> +  case 3: /* vccio2 */
>> >>>> +  break;
>> >>>> +  case 2: /* vccio1 */
>> >>>> +  case 4: /* vccio3 */
>> >>>> +  case 5: /* vccio4 */
>> >>>> +  case 6: /* vccio5 */
>> >>>> +  case 7: /* vccio6 */
>> >>>> +  case 8: /* vccio7 */
>> >>>> +  b = supply->idx - 1;
>> >>>> +  val0 = BIT(16 + b) | (is_3v3 ? 0 : BIT(b));
>> >>>> +  val1 = BIT(16 + b) | (is_3v3 ? BIT(b) : 0);
>> >>>> +
>> >>>> +  regmap_write(iod->grf, RK3568_PMU_GRF_IO_VSEL0, val0);
>> >>>> +  regmap_write(iod->grf, RK3568_PMU_GRF_IO_VSEL1, val1);
>> >>>> +  break;
>> >>>> +  default:
>> >>>> +  return -EINVAL;
>> >>>> +  };
>> >>>> +
>> >>>> +  return 0;
>> >>>> +}
>> >>>> +
>> >>>>     static int rockchip_iodomain_write(struct rockchip_iodomain_supply *supply,
>> >>>>        int uV)
>> >>>>     {
>> >>>> @@ -136,7 +183,7 @@ static int rockchip_iodomain_notify(struct notifier_block *nb,
>> >>>>     return NOTIFY_BAD;
>> >>>>     }
>> >>>>
>> >>>> -  ret = rockchip_iodomain_write(supply, uV);
>> >>>> +  ret = supply->iod->write(supply, uV);
>> >>>>     if (ret && event == REGULATOR_EVENT_PRE_VOLTAGE_CHANGE)
>> >>>>     return NOTIFY_BAD;
>> >>>>
>> >>>> @@ -398,6 +445,22 @@ static const struct rockchip_iodomain_soc_data soc_data_rk3399_pmu = {
>> >>>>     .init = rk3399_pmu_iodomain_init,
>> >>>>     };
>> >>>>
>> >>>> +static const struct rockchip_iodomain_soc_data soc_data_rk3568_pmu = {
>> >>>> +  .grf_offset = 0x140,
>> >>>> +  .supply_names = {
>> >>>> +  "pmuio1",
>> >>>> +  "pmuio2",
>> >>>> +  "vccio1",
>> >>>> +  "vccio2",
>> >>>> +  "vccio3",
>> >>>> +  "vccio4",
>> >>>> +  "vccio5",
>> >>>> +  "vccio6",
>> >>>> +  "vccio7",
>> >>>> +  },
>> >>>> +  .write = rk3568_iodomain_write,
>> >>>> +};
>> >>>> +
>> >>>>     static const struct rockchip_iodomain_soc_data soc_data_rv1108 = {
>> >>>>     .grf_offset = 0x404,
>> >>>>     .supply_names = {
>> >>>> @@ -469,6 +532,10 @@ static const struct of_device_id rockchip_iodomain_match[] = {
>> >>>>     .compatible = "rockchip,rk3399-pmu-io-voltage-domain",
>> >>>>     .data = &soc_data_rk3399_pmu
>> >>>>     },
>> >>>> +  {
>> >>>> +  .compatible = "rockchip,rk3568-pmu-io-voltage-domain",
>> >>>> +  .data = &soc_data_rk3568_pmu
>> >>>> +  },
>> >>>>     {
>> >>>>     .compatible = "rockchip,rv1108-io-voltage-domain",
>> >>>>     .data = &soc_data_rv1108
>> >>>> @@ -502,6 +569,11 @@ static int rockchip_iodomain_probe(struct platform_device *pdev)
>> >>>>     match = of_match_node(rockchip_iodomain_match, np);
>> >>>>     iod->soc_data = match->data;
>> >>>>
>> >>>> +  if (iod->soc_data->write)
>> >>>> +  iod->write = iod->soc_data->write;
>> >>>> +  else
>> >>>> +  iod->write = rockchip_iodomain_write;
>> >>>> +
>> >>>>     parent = pdev->dev.parent;
>> >>>>     if (parent && parent->of_node) {
>> >>>>     iod->grf = syscon_node_to_regmap(parent->of_node);
>> >>>> @@ -562,7 +634,7 @@ static int rockchip_iodomain_probe(struct platform_device *pdev)
>> >>>>     supply->reg = reg;
>> >>>>     supply->nb.notifier_call = rockchip_iodomain_notify;
>> >>>>
>> >>>> -  ret = rockchip_iodomain_write(supply, uV);
>> >>>> +  ret = iod->write(supply, uV);
>> >>>>     if (ret) {
>> >>>>     supply->reg = NULL;
>> >>>>     goto unreg_notify;
>> >>>>
>> >>>
>> >>
>> >>
>> >>
>> >>
>> >>
>> >>
>> >>
>> >
>
>
>
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel