* [PATCH v3 0/3] Update Broadcom Stingray clock entries
From: Ray Jui @ 2018-06-02 0:56 UTC (permalink / raw)
To: Michael Turquette, Stephen Boyd, Rob Herring, Mark Rutland
Cc: linux-clk, linux-kernel, bcm-kernel-feedback-list, devicetree,
linux-arm-kernel, Pramod Kumar, Ray Jui
This patch series updates Broadcom Stingray clock entries so they match the
latest ASIC datasheet
This patch series is based off v4.17-rc5 and is available on GIHUB:
repo: https://github.com/Broadcom/arm64-linux.git
branch: sr-clk-v3
Changes since v2:
- Move dt-binding header change to the same patch with the binding doc
update
Changes since v1:
- Fix patch author to Pramod Kumar on all 3 patches
- Fix patch subject spelling error on patch 2/3
Pramod Kumar (3):
dt-bindings: clk: Update Stingray binding doc
clk: bcm: Update and add Stingray clock entries
arm64: dts: Update Stingray clock DT nodes
.../bindings/clock/brcm,iproc-clocks.txt | 26 ++--
.../boot/dts/broadcom/stingray/stingray-clock.dtsi | 26 ++--
drivers/clk/bcm/clk-sr.c | 135 ++++++++++++++++++---
include/dt-bindings/clock/bcm-sr.h | 24 ++--
4 files changed, 170 insertions(+), 41 deletions(-)
--
2.1.4
^ permalink raw reply
* [PATCH v3 1/3] dt-bindings: clk: Update Stingray binding doc
From: Ray Jui @ 2018-06-02 0:56 UTC (permalink / raw)
To: Michael Turquette, Stephen Boyd, Rob Herring, Mark Rutland
Cc: devicetree, linux-kernel, Pramod Kumar, bcm-kernel-feedback-list,
Ray Jui, linux-clk, linux-arm-kernel
In-Reply-To: <1527900968-12017-1-git-send-email-ray.jui@broadcom.com>
From: Pramod Kumar <pramod.kumar@broadcom.com>
Update Stingray clock binding document to add additional clock entries
with names matching the latest ASIC datasheet. Also modify a few existing
entries to make their naming more consistent with the rest of the entries
Signed-off-by: Pramod Kumar <pramod.kumar@broadcom.com>
Signed-off-by: Ray Jui <ray.jui@broadcom.com>
---
.../bindings/clock/brcm,iproc-clocks.txt | 26 ++++++++++++----------
include/dt-bindings/clock/bcm-sr.h | 24 ++++++++++++++------
2 files changed, 31 insertions(+), 19 deletions(-)
diff --git a/Documentation/devicetree/bindings/clock/brcm,iproc-clocks.txt b/Documentation/devicetree/bindings/clock/brcm,iproc-clocks.txt
index f8e4a93..ab730ea 100644
--- a/Documentation/devicetree/bindings/clock/brcm,iproc-clocks.txt
+++ b/Documentation/devicetree/bindings/clock/brcm,iproc-clocks.txt
@@ -276,36 +276,38 @@ These clock IDs are defined in:
clk_ts_500_ref genpll2 2 BCM_SR_GENPLL2_TS_500_REF_CLK
clk_125_nitro genpll2 3 BCM_SR_GENPLL2_125_NITRO_CLK
clk_chimp genpll2 4 BCM_SR_GENPLL2_CHIMP_CLK
- clk_nic_flash genpll2 5 BCM_SR_GENPLL2_NIC_FLASH
+ clk_nic_flash genpll2 5 BCM_SR_GENPLL2_NIC_FLASH_CLK
+ clk_fs genpll2 6 BCM_SR_GENPLL2_FS_CLK
genpll3 crystal 0 BCM_SR_GENPLL3
clk_hsls genpll3 1 BCM_SR_GENPLL3_HSLS_CLK
clk_sdio genpll3 2 BCM_SR_GENPLL3_SDIO_CLK
genpll4 crystal 0 BCM_SR_GENPLL4
- ccn genpll4 1 BCM_SR_GENPLL4_CCN_CLK
+ clk_ccn genpll4 1 BCM_SR_GENPLL4_CCN_CLK
clk_tpiu_pll genpll4 2 BCM_SR_GENPLL4_TPIU_PLL_CLK
- noc_clk genpll4 3 BCM_SR_GENPLL4_NOC_CLK
+ clk_noc genpll4 3 BCM_SR_GENPLL4_NOC_CLK
clk_chclk_fs4 genpll4 4 BCM_SR_GENPLL4_CHCLK_FS4_CLK
clk_bridge_fscpu genpll4 5 BCM_SR_GENPLL4_BRIDGE_FSCPU_CLK
-
genpll5 crystal 0 BCM_SR_GENPLL5
- fs4_hf_clk genpll5 1 BCM_SR_GENPLL5_FS4_HF_CLK
- crypto_ae_clk genpll5 2 BCM_SR_GENPLL5_CRYPTO_AE_CLK
- raid_ae_clk genpll5 3 BCM_SR_GENPLL5_RAID_AE_CLK
+ clk_fs4_hf genpll5 1 BCM_SR_GENPLL5_FS4_HF_CLK
+ clk_crypto_ae genpll5 2 BCM_SR_GENPLL5_CRYPTO_AE_CLK
+ clk_raid_ae genpll5 3 BCM_SR_GENPLL5_RAID_AE_CLK
genpll6 crystal 0 BCM_SR_GENPLL6
- 48_usb genpll6 1 BCM_SR_GENPLL6_48_USB_CLK
+ clk_48_usb genpll6 1 BCM_SR_GENPLL6_48_USB_CLK
lcpll0 crystal 0 BCM_SR_LCPLL0
clk_sata_refp lcpll0 1 BCM_SR_LCPLL0_SATA_REFP_CLK
clk_sata_refn lcpll0 2 BCM_SR_LCPLL0_SATA_REFN_CLK
- clk_usb_ref lcpll0 3 BCM_SR_LCPLL0_USB_REF_CLK
- sata_refpn lcpll0 3 BCM_SR_LCPLL0_SATA_REFPN_CLK
+ clk_sata_350 lcpll0 3 BCM_SR_LCPLL0_SATA_350_CLK
+ clk_sata_500 lcpll0 4 BCM_SR_LCPLL0_SATA_500_CLK
lcpll1 crystal 0 BCM_SR_LCPLL1
- wan lcpll1 1 BCM_SR_LCPLL0_WAN_CLK
+ clk_wan lcpll1 1 BCM_SR_LCPLL1_WAN_CLK
+ clk_usb_ref lcpll1 2 BCM_SR_LCPLL1_USB_REF_CLK
+ clk_crmu_ts lcpll1 3 BCM_SR_LCPLL1_CRMU_TS_CLK
lcpll_pcie crystal 0 BCM_SR_LCPLL_PCIE
- pcie_phy_ref lcpll1 1 BCM_SR_LCPLL_PCIE_PHY_REF_CLK
+ clk_pcie_phy_ref lcpll1 1 BCM_SR_LCPLL_PCIE_PHY_REF_CLK
diff --git a/include/dt-bindings/clock/bcm-sr.h b/include/dt-bindings/clock/bcm-sr.h
index cff6c6f..419011b 100644
--- a/include/dt-bindings/clock/bcm-sr.h
+++ b/include/dt-bindings/clock/bcm-sr.h
@@ -35,7 +35,7 @@
/* GENPLL 0 clock channel ID SCR HSLS FS PCIE */
#define BCM_SR_GENPLL0 0
-#define BCM_SR_GENPLL0_SATA_CLK 1
+#define BCM_SR_GENPLL0_125M_CLK 1
#define BCM_SR_GENPLL0_SCR_CLK 2
#define BCM_SR_GENPLL0_250M_CLK 3
#define BCM_SR_GENPLL0_PCIE_AXI_CLK 4
@@ -50,9 +50,11 @@
/* GENPLL 2 clock channel ID NITRO MHB*/
#define BCM_SR_GENPLL2 0
#define BCM_SR_GENPLL2_NIC_CLK 1
-#define BCM_SR_GENPLL2_250_NITRO_CLK 2
+#define BCM_SR_GENPLL2_TS_500_CLK 2
#define BCM_SR_GENPLL2_125_NITRO_CLK 3
#define BCM_SR_GENPLL2_CHIMP_CLK 4
+#define BCM_SR_GENPLL2_NIC_FLASH_CLK 5
+#define BCM_SR_GENPLL2_FS4_CLK 6
/* GENPLL 3 HSLS clock channel ID */
#define BCM_SR_GENPLL3 0
@@ -62,11 +64,16 @@
/* GENPLL 4 SCR clock channel ID */
#define BCM_SR_GENPLL4 0
#define BCM_SR_GENPLL4_CCN_CLK 1
+#define BCM_SR_GENPLL4_TPIU_PLL_CLK 2
+#define BCM_SR_GENPLL4_NOC_CLK 3
+#define BCM_SR_GENPLL4_CHCLK_FS4_CLK 4
+#define BCM_SR_GENPLL4_BRIDGE_FSCPU_CLK 5
/* GENPLL 5 FS4 clock channel ID */
#define BCM_SR_GENPLL5 0
-#define BCM_SR_GENPLL5_FS_CLK 1
-#define BCM_SR_GENPLL5_SPU_CLK 2
+#define BCM_SR_GENPLL5_FS4_HF_CLK 1
+#define BCM_SR_GENPLL5_CRYPTO_AE_CLK 2
+#define BCM_SR_GENPLL5_RAID_AE_CLK 3
/* GENPLL 6 NITRO clock channel ID */
#define BCM_SR_GENPLL6 0
@@ -74,13 +81,16 @@
/* LCPLL0 clock channel ID */
#define BCM_SR_LCPLL0 0
-#define BCM_SR_LCPLL0_SATA_REF_CLK 1
-#define BCM_SR_LCPLL0_USB_REF_CLK 2
-#define BCM_SR_LCPLL0_SATA_REFPN_CLK 3
+#define BCM_SR_LCPLL0_SATA_REFP_CLK 1
+#define BCM_SR_LCPLL0_SATA_REFN_CLK 2
+#define BCM_SR_LCPLL0_SATA_350_CLK 3
+#define BCM_SR_LCPLL0_SATA_500_CLK 4
/* LCPLL1 clock channel ID */
#define BCM_SR_LCPLL1 0
#define BCM_SR_LCPLL1_WAN_CLK 1
+#define BCM_SR_LCPLL1_USB_REF_CLK 2
+#define BCM_SR_LCPLL1_CRMU_TS_CLK 3
/* LCPLL PCIE clock channel ID */
#define BCM_SR_LCPLL_PCIE 0
--
2.1.4
^ permalink raw reply related
* [PATCH v3 2/3] clk: bcm: Update and add Stingray clock entries
From: Ray Jui @ 2018-06-02 0:56 UTC (permalink / raw)
To: Michael Turquette, Stephen Boyd, Rob Herring, Mark Rutland
Cc: linux-clk, linux-kernel, bcm-kernel-feedback-list, devicetree,
linux-arm-kernel, Pramod Kumar, Ray Jui
In-Reply-To: <1527900968-12017-1-git-send-email-ray.jui@broadcom.com>
From: Pramod Kumar <pramod.kumar@broadcom.com>
Update and add Stingray clock definitions and tables so they match the
binding document and the latest ASIC datasheet
Signed-off-by: Pramod Kumar <pramod.kumar@broadcom.com>
Signed-off-by: Ray Jui <ray.jui@broadcom.com>
---
drivers/clk/bcm/clk-sr.c | 135 +++++++++++++++++++++++++++++++++++++++++------
1 file changed, 120 insertions(+), 15 deletions(-)
diff --git a/drivers/clk/bcm/clk-sr.c b/drivers/clk/bcm/clk-sr.c
index adc74f4..7b9efc0 100644
--- a/drivers/clk/bcm/clk-sr.c
+++ b/drivers/clk/bcm/clk-sr.c
@@ -56,8 +56,8 @@ static const struct iproc_pll_ctrl sr_genpll0 = {
};
static const struct iproc_clk_ctrl sr_genpll0_clk[] = {
- [BCM_SR_GENPLL0_SATA_CLK] = {
- .channel = BCM_SR_GENPLL0_SATA_CLK,
+ [BCM_SR_GENPLL0_125M_CLK] = {
+ .channel = BCM_SR_GENPLL0_125M_CLK,
.flags = IPROC_CLK_AON,
.enable = ENABLE_VAL(0x4, 6, 0, 12),
.mdiv = REG_VAL(0x18, 0, 9),
@@ -102,6 +102,65 @@ static int sr_genpll0_clk_init(struct platform_device *pdev)
return 0;
}
+static const struct iproc_pll_ctrl sr_genpll2 = {
+ .flags = IPROC_CLK_AON | IPROC_CLK_PLL_HAS_NDIV_FRAC |
+ IPROC_CLK_PLL_NEEDS_SW_CFG,
+ .aon = AON_VAL(0x0, 1, 13, 12),
+ .reset = RESET_VAL(0x0, 12, 11),
+ .dig_filter = DF_VAL(0x0, 4, 3, 0, 4, 7, 3),
+ .sw_ctrl = SW_CTRL_VAL(0x10, 31),
+ .ndiv_int = REG_VAL(0x10, 20, 10),
+ .ndiv_frac = REG_VAL(0x10, 0, 20),
+ .pdiv = REG_VAL(0x14, 0, 4),
+ .status = REG_VAL(0x30, 12, 1),
+};
+
+static const struct iproc_clk_ctrl sr_genpll2_clk[] = {
+ [BCM_SR_GENPLL2_NIC_CLK] = {
+ .channel = BCM_SR_GENPLL2_NIC_CLK,
+ .flags = IPROC_CLK_AON,
+ .enable = ENABLE_VAL(0x4, 6, 0, 12),
+ .mdiv = REG_VAL(0x18, 0, 9),
+ },
+ [BCM_SR_GENPLL2_TS_500_CLK] = {
+ .channel = BCM_SR_GENPLL2_TS_500_CLK,
+ .flags = IPROC_CLK_AON,
+ .enable = ENABLE_VAL(0x4, 7, 1, 13),
+ .mdiv = REG_VAL(0x18, 10, 9),
+ },
+ [BCM_SR_GENPLL2_125_NITRO_CLK] = {
+ .channel = BCM_SR_GENPLL2_125_NITRO_CLK,
+ .flags = IPROC_CLK_AON,
+ .enable = ENABLE_VAL(0x4, 8, 2, 14),
+ .mdiv = REG_VAL(0x18, 20, 9),
+ },
+ [BCM_SR_GENPLL2_CHIMP_CLK] = {
+ .channel = BCM_SR_GENPLL2_CHIMP_CLK,
+ .flags = IPROC_CLK_AON,
+ .enable = ENABLE_VAL(0x4, 9, 3, 15),
+ .mdiv = REG_VAL(0x1c, 0, 9),
+ },
+ [BCM_SR_GENPLL2_NIC_FLASH_CLK] = {
+ .channel = BCM_SR_GENPLL2_NIC_FLASH_CLK,
+ .flags = IPROC_CLK_AON,
+ .enable = ENABLE_VAL(0x4, 10, 4, 16),
+ .mdiv = REG_VAL(0x1c, 10, 9),
+ },
+ [BCM_SR_GENPLL2_FS4_CLK] = {
+ .channel = BCM_SR_GENPLL2_FS4_CLK,
+ .enable = ENABLE_VAL(0x4, 11, 5, 17),
+ .mdiv = REG_VAL(0x1c, 20, 9),
+ },
+};
+
+static int sr_genpll2_clk_init(struct platform_device *pdev)
+{
+ iproc_pll_clk_setup(pdev->dev.of_node,
+ &sr_genpll2, NULL, 0, sr_genpll2_clk,
+ ARRAY_SIZE(sr_genpll2_clk));
+ return 0;
+}
+
static const struct iproc_pll_ctrl sr_genpll3 = {
.flags = IPROC_CLK_AON | IPROC_CLK_PLL_HAS_NDIV_FRAC |
IPROC_CLK_PLL_NEEDS_SW_CFG,
@@ -157,6 +216,30 @@ static const struct iproc_clk_ctrl sr_genpll4_clk[] = {
.enable = ENABLE_VAL(0x4, 6, 0, 12),
.mdiv = REG_VAL(0x18, 0, 9),
},
+ [BCM_SR_GENPLL4_TPIU_PLL_CLK] = {
+ .channel = BCM_SR_GENPLL4_TPIU_PLL_CLK,
+ .flags = IPROC_CLK_AON,
+ .enable = ENABLE_VAL(0x4, 7, 1, 13),
+ .mdiv = REG_VAL(0x18, 10, 9),
+ },
+ [BCM_SR_GENPLL4_NOC_CLK] = {
+ .channel = BCM_SR_GENPLL4_NOC_CLK,
+ .flags = IPROC_CLK_AON,
+ .enable = ENABLE_VAL(0x4, 8, 2, 14),
+ .mdiv = REG_VAL(0x18, 20, 9),
+ },
+ [BCM_SR_GENPLL4_CHCLK_FS4_CLK] = {
+ .channel = BCM_SR_GENPLL4_CHCLK_FS4_CLK,
+ .flags = IPROC_CLK_AON,
+ .enable = ENABLE_VAL(0x4, 9, 3, 15),
+ .mdiv = REG_VAL(0x1c, 0, 9),
+ },
+ [BCM_SR_GENPLL4_BRIDGE_FSCPU_CLK] = {
+ .channel = BCM_SR_GENPLL4_BRIDGE_FSCPU_CLK,
+ .flags = IPROC_CLK_AON,
+ .enable = ENABLE_VAL(0x4, 10, 4, 16),
+ .mdiv = REG_VAL(0x1c, 10, 9),
+ },
};
static int sr_genpll4_clk_init(struct platform_device *pdev)
@@ -181,18 +264,21 @@ static const struct iproc_pll_ctrl sr_genpll5 = {
};
static const struct iproc_clk_ctrl sr_genpll5_clk[] = {
- [BCM_SR_GENPLL5_FS_CLK] = {
- .channel = BCM_SR_GENPLL5_FS_CLK,
- .flags = IPROC_CLK_AON,
+ [BCM_SR_GENPLL5_FS4_HF_CLK] = {
+ .channel = BCM_SR_GENPLL5_FS4_HF_CLK,
.enable = ENABLE_VAL(0x4, 6, 0, 12),
.mdiv = REG_VAL(0x18, 0, 9),
},
- [BCM_SR_GENPLL5_SPU_CLK] = {
- .channel = BCM_SR_GENPLL5_SPU_CLK,
- .flags = IPROC_CLK_AON,
- .enable = ENABLE_VAL(0x4, 6, 0, 12),
+ [BCM_SR_GENPLL5_CRYPTO_AE_CLK] = {
+ .channel = BCM_SR_GENPLL5_CRYPTO_AE_CLK,
+ .enable = ENABLE_VAL(0x4, 7, 1, 12),
.mdiv = REG_VAL(0x18, 10, 9),
},
+ [BCM_SR_GENPLL5_RAID_AE_CLK] = {
+ .channel = BCM_SR_GENPLL5_RAID_AE_CLK,
+ .enable = ENABLE_VAL(0x4, 8, 2, 14),
+ .mdiv = REG_VAL(0x18, 20, 9),
+ },
};
static int sr_genpll5_clk_init(struct platform_device *pdev)
@@ -214,24 +300,30 @@ static const struct iproc_pll_ctrl sr_lcpll0 = {
};
static const struct iproc_clk_ctrl sr_lcpll0_clk[] = {
- [BCM_SR_LCPLL0_SATA_REF_CLK] = {
- .channel = BCM_SR_LCPLL0_SATA_REF_CLK,
+ [BCM_SR_LCPLL0_SATA_REFP_CLK] = {
+ .channel = BCM_SR_LCPLL0_SATA_REFP_CLK,
.flags = IPROC_CLK_AON,
.enable = ENABLE_VAL(0x0, 7, 1, 13),
.mdiv = REG_VAL(0x14, 0, 9),
},
- [BCM_SR_LCPLL0_USB_REF_CLK] = {
- .channel = BCM_SR_LCPLL0_USB_REF_CLK,
+ [BCM_SR_LCPLL0_SATA_REFN_CLK] = {
+ .channel = BCM_SR_LCPLL0_SATA_REFN_CLK,
.flags = IPROC_CLK_AON,
.enable = ENABLE_VAL(0x0, 8, 2, 14),
.mdiv = REG_VAL(0x14, 10, 9),
},
- [BCM_SR_LCPLL0_SATA_REFPN_CLK] = {
- .channel = BCM_SR_LCPLL0_SATA_REFPN_CLK,
+ [BCM_SR_LCPLL0_SATA_350_CLK] = {
+ .channel = BCM_SR_LCPLL0_SATA_350_CLK,
.flags = IPROC_CLK_AON,
.enable = ENABLE_VAL(0x0, 9, 3, 15),
.mdiv = REG_VAL(0x14, 20, 9),
},
+ [BCM_SR_LCPLL0_SATA_500_CLK] = {
+ .channel = BCM_SR_LCPLL0_SATA_500_CLK,
+ .flags = IPROC_CLK_AON,
+ .enable = ENABLE_VAL(0x0, 10, 4, 16),
+ .mdiv = REG_VAL(0x18, 0, 9),
+ },
};
static int sr_lcpll0_clk_init(struct platform_device *pdev)
@@ -259,6 +351,18 @@ static const struct iproc_clk_ctrl sr_lcpll1_clk[] = {
.enable = ENABLE_VAL(0x0, 7, 1, 13),
.mdiv = REG_VAL(0x14, 0, 9),
},
+ [BCM_SR_LCPLL1_USB_REF_CLK] = {
+ .channel = BCM_SR_LCPLL1_USB_REF_CLK,
+ .flags = IPROC_CLK_AON,
+ .enable = ENABLE_VAL(0x0, 8, 2, 14),
+ .mdiv = REG_VAL(0x14, 10, 9),
+ },
+ [BCM_SR_LCPLL1_CRMU_TS_CLK] = {
+ .channel = BCM_SR_LCPLL1_CRMU_TS_CLK,
+ .flags = IPROC_CLK_AON,
+ .enable = ENABLE_VAL(0x0, 9, 3, 15),
+ .mdiv = REG_VAL(0x14, 20, 9),
+ },
};
static int sr_lcpll1_clk_init(struct platform_device *pdev)
@@ -298,6 +402,7 @@ static int sr_lcpll_pcie_clk_init(struct platform_device *pdev)
static const struct of_device_id sr_clk_dt_ids[] = {
{ .compatible = "brcm,sr-genpll0", .data = sr_genpll0_clk_init },
+ { .compatible = "brcm,sr-genpll2", .data = sr_genpll2_clk_init },
{ .compatible = "brcm,sr-genpll4", .data = sr_genpll4_clk_init },
{ .compatible = "brcm,sr-genpll5", .data = sr_genpll5_clk_init },
{ .compatible = "brcm,sr-lcpll0", .data = sr_lcpll0_clk_init },
--
2.1.4
^ permalink raw reply related
* [PATCH v3 3/3] arm64: dts: Update Stingray clock DT nodes
From: Ray Jui @ 2018-06-02 0:56 UTC (permalink / raw)
To: Michael Turquette, Stephen Boyd, Rob Herring, Mark Rutland
Cc: linux-clk, linux-kernel, bcm-kernel-feedback-list, devicetree,
linux-arm-kernel, Pramod Kumar, Ray Jui
In-Reply-To: <1527900968-12017-1-git-send-email-ray.jui@broadcom.com>
From: Pramod Kumar <pramod.kumar@broadcom.com>
Update clock output names in the Stingray clock DT nodes so they match
the binding document and the latest ASIC datasheet. Also add entries
for LCPLL2
Signed-off-by: Pramod Kumar <pramod.kumar@broadcom.com>
Signed-off-by: Ray Jui <ray.jui@broadcom.com>
---
.../boot/dts/broadcom/stingray/stingray-clock.dtsi | 26 ++++++++++++++++------
1 file changed, 19 insertions(+), 7 deletions(-)
diff --git a/arch/arm64/boot/dts/broadcom/stingray/stingray-clock.dtsi b/arch/arm64/boot/dts/broadcom/stingray/stingray-clock.dtsi
index 3a4d452..10a106a 100644
--- a/arch/arm64/boot/dts/broadcom/stingray/stingray-clock.dtsi
+++ b/arch/arm64/boot/dts/broadcom/stingray/stingray-clock.dtsi
@@ -52,12 +52,24 @@
reg = <0x0001d104 0x32>,
<0x0001c854 0x4>;
clocks = <&osc>;
- clock-output-names = "genpll0", "clk_125", "clk_scr",
+ clock-output-names = "genpll0", "clk_125m", "clk_scr",
"clk_250", "clk_pcie_axi",
"clk_paxc_axi_x2",
"clk_paxc_axi";
};
+ genpll2: genpll2@1d1ac {
+ #clock-cells = <1>;
+ compatible = "brcm,sr-genpll2";
+ reg = <0x0001d1ac 0x32>,
+ <0x0001c854 0x4>;
+ clocks = <&osc>;
+ clock-output-names = "genpll2", "clk_nic",
+ "clk_ts_500_ref", "clk_125_nitro",
+ "clk_chimp", "clk_nic_flash",
+ "clk_fs";
+ };
+
genpll3: genpll3@1d1e0 {
#clock-cells = <1>;
compatible = "brcm,sr-genpll3";
@@ -75,8 +87,8 @@
<0x0001c854 0x4>;
clocks = <&osc>;
clock-output-names = "genpll4", "clk_ccn",
- "clk_tpiu_pll", "noc_clk",
- "pll_chclk_fs4",
+ "clk_tpiu_pll", "clk_noc",
+ "clk_chclk_fs4",
"clk_bridge_fscpu";
};
@@ -86,8 +98,8 @@
reg = <0x0001d248 0x32>,
<0x0001c870 0x4>;
clocks = <&osc>;
- clock-output-names = "genpll5", "fs4_hf_clk",
- "crypto_ae_clk", "raid_ae_clk";
+ clock-output-names = "genpll5", "clk_fs4_hf",
+ "clk_crypto_ae", "clk_raid_ae";
};
lcpll0: lcpll0@1d0c4 {
@@ -107,9 +119,9 @@
reg = <0x0001d138 0x3c>,
<0x0001c870 0x4>;
clocks = <&osc>;
- clock-output-names = "lcpll1", "clk_wanpn",
+ clock-output-names = "lcpll1", "clk_wan",
"clk_usb_ref",
- "timesync_evt_clk";
+ "clk_crmu_ts";
};
hsls_clk: hsls_clk {
--
2.1.4
^ permalink raw reply related
* [PATCH v3 1/2] power: supply: sbs-battery: don't assume MANUFACTURER_DATA formats
From: Brian Norris @ 2018-06-02 1:28 UTC (permalink / raw)
To: Sebastian Reichel
Cc: linux-kernel, Rob Herring, linux-pm, devicetree, Rhyland Klein,
Alexandru Stan, Guenter Roeck, Doug Anderson, Brian Norris
This driver was originally submitted for the TI BQ20Z75 battery IC
(commit a7640bfa10c5 ("power_supply: Add driver for TI BQ20Z75 gas gauge
IC")) and later renamed to express generic SBS support. While it's
mostly true that this driver implemented a standard SBS command set, it
takes liberties with the REG_MANUFACTURER_DATA register. This register
is specified in the SBS spec, but it doesn't make any mention of what
its actual contents are.
We've sort of noticed this optionality previously, with commit
17c6d3979e5b ("sbs-battery: make writes to ManufacturerAccess
optional"), where we found that some batteries NAK writes to this
register.
What this really means is that so far, we've just been lucky that most
batteries have either been compatible with the TI chip, or else at least
haven't reported highly-unexpected values.
For instance, one battery I have here seems to report either 0x0000 or
0x0100 to the MANUFACTURER_ACCESS_STATUS command -- while this seems to
match either Wake Up (bits[11:8] = 0000b) or Normal Discharge
(bits[11:8] = 0001b) status for the TI part [1], they don't seem to
actually correspond to real states (for instance, I never see 0101b =
Charge, even when charging).
On other batteries, I'm getting apparently random data in return, which
means that occasionally, we interpret this as "battery not present" or
"battery is not healthy".
All in all, it seems to be a really bad idea to make assumptions about
REG_MANUFACTURER_DATA, unless we already know what battery we're using.
Therefore, this patch reimplements the "present" and "health" checks to
the following on most SBS batteries:
1. HEALTH: report "unknown" -- I couldn't find a standard SBS command
that gives us much useful here
2. PRESENT: just send a REG_STATUS command; if it succeeds, then the
battery is present
Also, we stop sending MANUFACTURER_ACCESS_SLEEP to non-TI parts. I have
no proof that this is useful and supported.
If someone explicitly provided a 'ti,bq20z75' compatible property, then
we retain the existing TI command behaviors.
[1] http://www.ti.com/lit/er/sluu265a/sluu265a.pdf
Signed-off-by: Brian Norris <briannorris@chromium.org>
Reviewed-by: Guenter Roeck <linux@roeck-us.net>
Acked-by: Rhyland Klein <rklein@nvidia.com>
---
v2:
* don't stub out POWER_SUPPLY_PROP_PRESENT from sbs_data[]
* use if/else instead of switch/case
v3:
* pull 'return 0' out of if/else, to satisfy braindead tooling
---
drivers/power/supply/sbs-battery.c | 54 +++++++++++++++++++++++++-----
1 file changed, 46 insertions(+), 8 deletions(-)
diff --git a/drivers/power/supply/sbs-battery.c b/drivers/power/supply/sbs-battery.c
index 83d7b4115857..a9691ea42f44 100644
--- a/drivers/power/supply/sbs-battery.c
+++ b/drivers/power/supply/sbs-battery.c
@@ -23,6 +23,7 @@
#include <linux/kernel.h>
#include <linux/module.h>
#include <linux/of.h>
+#include <linux/of_device.h>
#include <linux/power/sbs-battery.h>
#include <linux/power_supply.h>
#include <linux/slab.h>
@@ -156,6 +157,9 @@ static enum power_supply_property sbs_properties[] = {
POWER_SUPPLY_PROP_MODEL_NAME
};
+/* Supports special manufacturer commands from TI BQ20Z75 IC. */
+#define SBS_FLAGS_TI_BQ20Z75 BIT(0)
+
struct sbs_info {
struct i2c_client *client;
struct power_supply *power_supply;
@@ -168,6 +172,7 @@ struct sbs_info {
u32 poll_retry_count;
struct delayed_work work;
struct mutex mode_lock;
+ u32 flags;
};
static char model_name[I2C_SMBUS_BLOCK_MAX + 1];
@@ -315,6 +320,27 @@ static int sbs_status_correct(struct i2c_client *client, int *intval)
static int sbs_get_battery_presence_and_health(
struct i2c_client *client, enum power_supply_property psp,
union power_supply_propval *val)
+{
+ int ret;
+
+ if (psp == POWER_SUPPLY_PROP_PRESENT) {
+ /* Dummy command; if it succeeds, battery is present. */
+ ret = sbs_read_word_data(client, sbs_data[REG_STATUS].addr);
+ if (ret < 0)
+ val->intval = 0; /* battery disconnected */
+ else
+ val->intval = 1; /* battery present */
+ } else { /* POWER_SUPPLY_PROP_HEALTH */
+ /* SBS spec doesn't have a general health command. */
+ val->intval = POWER_SUPPLY_HEALTH_UNKNOWN;
+ }
+
+ return 0;
+}
+
+static int sbs_get_ti_battery_presence_and_health(
+ struct i2c_client *client, enum power_supply_property psp,
+ union power_supply_propval *val)
{
s32 ret;
@@ -600,7 +626,12 @@ static int sbs_get_property(struct power_supply *psy,
switch (psp) {
case POWER_SUPPLY_PROP_PRESENT:
case POWER_SUPPLY_PROP_HEALTH:
- ret = sbs_get_battery_presence_and_health(client, psp, val);
+ if (client->flags & SBS_FLAGS_TI_BQ20Z75)
+ ret = sbs_get_ti_battery_presence_and_health(client,
+ psp, val);
+ else
+ ret = sbs_get_battery_presence_and_health(client, psp,
+ val);
if (psp == POWER_SUPPLY_PROP_PRESENT)
return 0;
break;
@@ -806,6 +837,7 @@ static int sbs_probe(struct i2c_client *client,
if (!chip)
return -ENOMEM;
+ chip->flags = (u32)(uintptr_t)of_device_get_match_data(&client->dev);
chip->client = client;
chip->enable_detection = false;
psy_cfg.of_node = client->dev.of_node;
@@ -915,12 +947,15 @@ static int sbs_suspend(struct device *dev)
if (chip->poll_time > 0)
cancel_delayed_work_sync(&chip->work);
- /*
- * Write to manufacturer access with sleep command.
- * Support is manufacturer dependend, so ignore errors.
- */
- sbs_write_word_data(client, sbs_data[REG_MANUFACTURER_DATA].addr,
- MANUFACTURER_ACCESS_SLEEP);
+ if (chip->flags & SBS_FLAGS_TI_BQ20Z75) {
+ /*
+ * Write to manufacturer access with sleep command.
+ * Support is manufacturer dependent, so ignore errors.
+ */
+ sbs_write_word_data(client,
+ sbs_data[REG_MANUFACTURER_DATA].addr,
+ MANUFACTURER_ACCESS_SLEEP);
+ }
return 0;
}
@@ -941,7 +976,10 @@ MODULE_DEVICE_TABLE(i2c, sbs_id);
static const struct of_device_id sbs_dt_ids[] = {
{ .compatible = "sbs,sbs-battery" },
- { .compatible = "ti,bq20z75" },
+ {
+ .compatible = "ti,bq20z75",
+ .data = (void *)SBS_FLAGS_TI_BQ20Z75,
+ },
{ }
};
MODULE_DEVICE_TABLE(of, sbs_dt_ids);
--
2.17.1.1185.g55be947832-goog
^ permalink raw reply related
* [PATCH v3 2/2] dt-bindings: power: sbs-battery: re-document "ti,bq20z75"
From: Brian Norris @ 2018-06-02 1:29 UTC (permalink / raw)
To: Sebastian Reichel
Cc: linux-kernel, Rob Herring, linux-pm, devicetree, Rhyland Klein,
Alexandru Stan, Guenter Roeck, Doug Anderson, Brian Norris
In-Reply-To: <20180602012900.181352-1-briannorris@chromium.org>
This compatible property was documented before the driver was renamed to
"SBS" (see commit e57f1b68c406 ("devicetree-bindings: Propagate
bq20z75->sbs rename to dt bindings")). The driver has continued to
support this property as an alternative to "sbs,sbs-battery", and
because we've noticed there are some lingering TI specifics (in the
manufacturer-specific portion of the SBS spec), we'd like to start using
this property again to differentiate.
Signed-off-by: Brian Norris <briannorris@chromium.org>
Acked-by: Rhyland Klein <rklein@nvidia.com>
---
v2: add Rhyland's Acked-by
v3: no change
---
.../devicetree/bindings/power/supply/sbs_sbs-battery.txt | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/Documentation/devicetree/bindings/power/supply/sbs_sbs-battery.txt b/Documentation/devicetree/bindings/power/supply/sbs_sbs-battery.txt
index c40e8926facf..a7a9c3366f82 100644
--- a/Documentation/devicetree/bindings/power/supply/sbs_sbs-battery.txt
+++ b/Documentation/devicetree/bindings/power/supply/sbs_sbs-battery.txt
@@ -2,7 +2,7 @@ SBS sbs-battery
~~~~~~~~~~
Required properties :
- - compatible : "sbs,sbs-battery"
+ - compatible : "sbs,sbs-battery" or "ti,bq20z75"
Optional properties :
- sbs,i2c-retry-count : The number of times to retry i2c transactions on i2c
--
2.17.1.1185.g55be947832-goog
^ permalink raw reply related
* [PATCH v5 0/2] regulator: add QCOM RPMh regulator driver
From: David Collins @ 2018-06-02 1:34 UTC (permalink / raw)
To: broonie, lgirdwood, robh+dt, mark.rutland
Cc: David Collins, linux-arm-msm, linux-arm-kernel, devicetree,
linux-kernel, rnayak, sboyd, dianders
This patch series adds a driver and device tree binding documentation for
PMIC regulator control via Resource Power Manager-hardened (RPMh) on some
Qualcomm Technologies, Inc. SoCs such as SDM845. RPMh is a hardware block
which contains several accelerators which are used to manage various
hardware resources that are shared between the processors of the SoC. The
final hardware state of a regulator is determined within RPMh by performing
max aggregation of the requests made by all of the processors.
The RPMh regulator driver depends upon the RPMh driver [1] and command DB
driver [2] which are both still undergoing review. It also depends upon
three recent regulator changes: [3], [4], and [5].
Changes since v4 [6]:
- Removed support for DT properties qcom,regulator-drms-modes and
qcom,drms-mode-max-microamps
- Specified fixed DRMS high power mode minimum limits for LDO type
regulators
- Removed DRMS support for SMPS and BOB type regulators
- Simplified voltage caching logic
Changes since v3 [7]:
- Removed support for DT properties qcom,regulator-initial-microvolt
and qcom,headroom-microvolt
- Renamed DT property qcom,allowed-drms-modes to be
qcom,regulator-drms-modes
- Updated DT binding documentation to mention which common regulator
bindings can be used for qcom-rpmh-regulator devices
- Added voltage caching so that voltage requests are only sent to RPMh
after the regulator has been enabled at least once
- Changed 'voltage_selector' default value to be -ENOTRECOVERABLE to
interact with [5]
- Initialized 'enabled' to -EINVAL so that unused regulators are
disabled by regulator_late_cleanup()
- Removed rpmh_regulator_load_default_parameters() as it is no longer
needed
- Updated the mode usage description in qcom,rpmh-regulator.h
Changes since v2 [8]:
- Replaced '_' with '-' in device tree supply property names
- Renamed qcom_rpmh-regulator.c to be qcom-rpmh-regulator.c
- Updated various DT property names to use "microvolt" and "microamp"
- Moved allowed modes constraint specification out of the driver [4]
- Replaced rpmh_client with device pointer to match new RPMh API [1]
- Corrected drms mode threshold checking
- Initialized voltage_selector to -EINVAL when not specified in DT
- Added constants for PMIC regulator hardware modes
- Corrected type sign of mode mapping tables
- Made variable names for mode arrays plural
- Simplified Kconfig depends on
- Removed unnecessary constants and struct fields
- Added some descriptive comments
Changes since v1 [9]:
- Addressed review feedback from Doug, Mark, and Stephen
- Replaced set_voltage()/get_voltage() callbacks with set_voltage_sel()/
get_voltage_sel()
- Added set_bypass()/get_bypass() callbacks for BOB pass-through mode
control
- Removed top-level PMIC data structures
- Removed initialization variables from structs and passed them as
function parameters
- Removed various comments and error messages
- Simplified mode handling
- Refactored per-PMIC rpmh-regulator data specification
- Simplified probe function
- Moved header into DT patch
- Removed redundant property listings from DT binding documentation
[1]: https://lkml.org/lkml/2018/5/9/729
[2]: https://lkml.org/lkml/2018/4/10/714
[3]: https://lkml.org/lkml/2018/4/18/556
[4]: https://lkml.org/lkml/2018/5/11/696
[5]: https://lkml.org/lkml/2018/5/15/1005
[6]: https://lkml.org/lkml/2018/5/22/1168
[7]: https://lkml.org/lkml/2018/5/11/701
[8]: https://lkml.org/lkml/2018/4/13/687
[9]: https://lkml.org/lkml/2018/3/16/1431
David Collins (2):
regulator: dt-bindings: add QCOM RPMh regulator bindings
regulator: add QCOM RPMh regulator driver
.../bindings/regulator/qcom,rpmh-regulator.txt | 160 +++++
drivers/regulator/Kconfig | 9 +
drivers/regulator/Makefile | 1 +
drivers/regulator/qcom-rpmh-regulator.c | 770 +++++++++++++++++++++
.../dt-bindings/regulator/qcom,rpmh-regulator.h | 36 +
5 files changed, 976 insertions(+)
create mode 100644 Documentation/devicetree/bindings/regulator/qcom,rpmh-regulator.txt
create mode 100644 drivers/regulator/qcom-rpmh-regulator.c
create mode 100644 include/dt-bindings/regulator/qcom,rpmh-regulator.h
--
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,
a Linux Foundation Collaborative Project
^ permalink raw reply
* [PATCH v5 1/2] regulator: dt-bindings: add QCOM RPMh regulator bindings
From: David Collins @ 2018-06-02 1:34 UTC (permalink / raw)
To: broonie, lgirdwood, robh+dt, mark.rutland
Cc: David Collins, linux-arm-msm, linux-arm-kernel, devicetree,
linux-kernel, rnayak, sboyd, dianders
In-Reply-To: <cover.1527901471.git.collinsd@codeaurora.org>
Introduce bindings for RPMh regulator devices found on some
Qualcomm Technlogies, Inc. SoCs. These devices allow a given
processor within the SoC to make PMIC regulator requests which
are aggregated within the RPMh hardware block along with requests
from other processors in the SoC to determine the final PMIC
regulator hardware state.
Signed-off-by: David Collins <collinsd@codeaurora.org>
---
.../bindings/regulator/qcom,rpmh-regulator.txt | 160 +++++++++++++++++++++
.../dt-bindings/regulator/qcom,rpmh-regulator.h | 36 +++++
2 files changed, 196 insertions(+)
create mode 100644 Documentation/devicetree/bindings/regulator/qcom,rpmh-regulator.txt
create mode 100644 include/dt-bindings/regulator/qcom,rpmh-regulator.h
diff --git a/Documentation/devicetree/bindings/regulator/qcom,rpmh-regulator.txt b/Documentation/devicetree/bindings/regulator/qcom,rpmh-regulator.txt
new file mode 100644
index 0000000..7ef2dbe
--- /dev/null
+++ b/Documentation/devicetree/bindings/regulator/qcom,rpmh-regulator.txt
@@ -0,0 +1,160 @@
+Qualcomm Technologies, Inc. RPMh Regulators
+
+rpmh-regulator devices support PMIC regulator management via the Voltage
+Regulator Manager (VRM) and Oscillator Buffer (XOB) RPMh accelerators. The APPS
+processor communicates with these hardware blocks via a Resource State
+Coordinator (RSC) using command packets. The VRM allows changing three
+parameters for a given regulator: enable state, output voltage, and operating
+mode. The XOB allows changing only a single parameter for a given regulator:
+its enable state. Despite its name, the XOB is capable of controlling the
+enable state of any PMIC peripheral. It is used for clock buffers, low-voltage
+switches, and LDO/SMPS regulators which have a fixed voltage and mode.
+
+=======================
+Required Node Structure
+=======================
+
+RPMh regulators must be described in two levels of device nodes. The first
+level describes the PMIC containing the regulators and must reside within an
+RPMh device node. The second level describes each regulator within the PMIC
+which is to be used on the board. Each of these regulators maps to a single
+RPMh resource.
+
+The names used for regulator nodes must match those supported by a given PMIC.
+Supported regulator node names:
+ PM8998: smps1 - smps13, ldo1 - ldo28, lvs1 - lvs2
+ PMI8998: bob
+ PM8005: smps1 - smps4
+
+========================
+First Level Nodes - PMIC
+========================
+
+- compatible
+ Usage: required
+ Value type: <string>
+ Definition: Must be one of: "qcom,pm8998-rpmh-regulators",
+ "qcom,pmi8998-rpmh-regulators" or
+ "qcom,pm8005-rpmh-regulators".
+
+- qcom,pmic-id
+ Usage: required
+ Value type: <string>
+ Definition: RPMh resource name suffix used for the regulators found on
+ this PMIC. Typical values: "a", "b", "c", "d", "e", "f".
+
+- vdd-s1-supply
+- vdd-s2-supply
+- vdd-s3-supply
+- vdd-s4-supply
+ Usage: optional (PM8998 and PM8005 only)
+ Value type: <phandle>
+ Definition: phandle of the parent supply regulator of one or more of the
+ regulators for this PMIC.
+
+- vdd-s5-supply
+- vdd-s6-supply
+- vdd-s7-supply
+- vdd-s8-supply
+- vdd-s9-supply
+- vdd-s10-supply
+- vdd-s11-supply
+- vdd-s12-supply
+- vdd-s13-supply
+- vdd-l1-l27-supply
+- vdd-l2-l8-l17-supply
+- vdd-l3-l11-supply
+- vdd-l4-l5-supply
+- vdd-l6-supply
+- vdd-l7-l12-l14-l15-supply
+- vdd-l9-supply
+- vdd-l10-l23-l25-supply
+- vdd-l13-l19-l21-supply
+- vdd-l16-l28-supply
+- vdd-l18-l22-supply
+- vdd-l20-l24-supply
+- vdd-l26-supply
+- vin-lvs-1-2-supply
+ Usage: optional (PM8998 only)
+ Value type: <phandle>
+ Definition: phandle of the parent supply regulator of one or more of the
+ regulators for this PMIC.
+
+- vdd-bob-supply
+ Usage: optional (PMI8998 only)
+ Value type: <phandle>
+ Definition: BOB regulator parent supply phandle
+
+===============================
+Second Level Nodes - Regulators
+===============================
+
+- qcom,always-wait-for-ack
+ Usage: optional
+ Value type: <empty>
+ Definition: Boolean flag which indicates that the application processor
+ must wait for an ACK or a NACK from RPMh for every request
+ sent for this regulator including those which are for a
+ strictly lower power state.
+
+Other properties defined in Documentation/devicetree/bindings/regulator.txt
+may also be used. regulator-initial-mode and regulator-allowed-modes may be
+specified for VRM regulators using mode values from
+include/dt-bindings/regulator/qcom,rpmh-regulator.h. regulator-allow-bypass
+may be specified for BOB type regulators managed via VRM.
+regulator-allow-set-load may be specified for LDO type regulators managed via
+VRM.
+
+========
+Examples
+========
+
+#include <dt-bindings/regulator/qcom,rpmh-regulator.h>
+
+&apps_rsc {
+ pm8998-rpmh-regulators {
+ compatible = "qcom,pm8998-rpmh-regulators";
+ qcom,pmic-id = "a";
+
+ vdd-l7-l12-l14-l15-supply = <&pm8998_s5>;
+
+ smps2 {
+ regulator-min-microvolt = <1100000>;
+ regulator-max-microvolt = <1100000>;
+ };
+
+ pm8998_s5: smps5 {
+ regulator-min-microvolt = <1904000>;
+ regulator-max-microvolt = <2040000>;
+ };
+
+ ldo7 {
+ regulator-min-microvolt = <1800000>;
+ regulator-max-microvolt = <1800000>;
+ regulator-initial-mode = <RPMH_REGULATOR_MODE_HPM>;
+ regulator-allowed-modes =
+ <RPMH_REGULATOR_MODE_LPM
+ RPMH_REGULATOR_MODE_HPM>;
+ regulator-allow-set-load;
+ };
+
+ lvs1 {
+ regulator-min-microvolt = <1800000>;
+ regulator-max-microvolt = <1800000>;
+ };
+ };
+
+ pmi8998-rpmh-regulators {
+ compatible = "qcom,pmi8998-rpmh-regulators";
+ qcom,pmic-id = "b";
+
+ bob {
+ regulator-min-microvolt = <3312000>;
+ regulator-max-microvolt = <3600000>;
+ regulator-allowed-modes =
+ <RPMH_REGULATOR_MODE_AUTO
+ RPMH_REGULATOR_MODE_HPM>;
+ regulator-initial-mode = <RPMH_REGULATOR_MODE_AUTO>;
+ };
+ };
+};
diff --git a/include/dt-bindings/regulator/qcom,rpmh-regulator.h b/include/dt-bindings/regulator/qcom,rpmh-regulator.h
new file mode 100644
index 0000000..86713dc
--- /dev/null
+++ b/include/dt-bindings/regulator/qcom,rpmh-regulator.h
@@ -0,0 +1,36 @@
+/* SPDX-License-Identifier: GPL-2.0 */
+/* Copyright (c) 2018, The Linux Foundation. All rights reserved. */
+
+#ifndef __QCOM_RPMH_REGULATOR_H
+#define __QCOM_RPMH_REGULATOR_H
+
+/*
+ * These mode constants may be used to specify modes for various RPMh regulator
+ * device tree properties (e.g. regulator-initial-mode). Each type of regulator
+ * supports a subset of the possible modes.
+ *
+ * %RPMH_REGULATOR_MODE_RET: Retention mode in which only an extremely small
+ * load current is allowed. This mode is supported
+ * by LDO and SMPS type regulators.
+ * %RPMH_REGULATOR_MODE_LPM: Low power mode in which a small load current is
+ * allowed. This mode corresponds to PFM for SMPS
+ * and BOB type regulators. This mode is supported
+ * by LDO, HFSMPS, BOB, and PMIC4 FTSMPS type
+ * regulators.
+ * %RPMH_REGULATOR_MODE_AUTO: Auto mode in which the regulator hardware
+ * automatically switches between LPM and HPM based
+ * upon the real-time load current. This mode is
+ * supported by HFSMPS, BOB, and PMIC4 FTSMPS type
+ * regulators.
+ * %RPMH_REGULATOR_MODE_HPM: High power mode in which the full rated current
+ * of the regulator is allowed. This mode
+ * corresponds to PWM for SMPS and BOB type
+ * regulators. This mode is supported by all types
+ * of regulators.
+ */
+#define RPMH_REGULATOR_MODE_RET 0
+#define RPMH_REGULATOR_MODE_LPM 1
+#define RPMH_REGULATOR_MODE_AUTO 2
+#define RPMH_REGULATOR_MODE_HPM 3
+
+#endif
--
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,
a Linux Foundation Collaborative Project
^ permalink raw reply related
* [PATCH v5 2/2] regulator: add QCOM RPMh regulator driver
From: David Collins @ 2018-06-02 1:34 UTC (permalink / raw)
To: broonie, lgirdwood, robh+dt, mark.rutland
Cc: David Collins, linux-arm-msm, linux-arm-kernel, devicetree,
linux-kernel, rnayak, sboyd, dianders
In-Reply-To: <cover.1527901471.git.collinsd@codeaurora.org>
Add the QCOM RPMh regulator driver to manage PMIC regulators
which are controlled via RPMh on some Qualcomm Technologies, Inc.
SoCs. RPMh is a hardware block which contains several
accelerators which are used to manage various hardware resources
that are shared between the processors of the SoC. The final
hardware state of a regulator is determined within RPMh by
performing max aggregation of the requests made by all of the
processors.
Add support for PMIC regulator control via the voltage regulator
manager (VRM) and oscillator buffer (XOB) RPMh accelerators.
VRM supports manipulation of enable state, voltage, and mode.
XOB supports manipulation of enable state.
Signed-off-by: David Collins <collinsd@codeaurora.org>
---
drivers/regulator/Kconfig | 9 +
drivers/regulator/Makefile | 1 +
drivers/regulator/qcom-rpmh-regulator.c | 770 ++++++++++++++++++++++++++++++++
3 files changed, 780 insertions(+)
create mode 100644 drivers/regulator/qcom-rpmh-regulator.c
diff --git a/drivers/regulator/Kconfig b/drivers/regulator/Kconfig
index 5dbccf5..96b701f 100644
--- a/drivers/regulator/Kconfig
+++ b/drivers/regulator/Kconfig
@@ -682,6 +682,15 @@ config REGULATOR_QCOM_RPM
Qualcomm RPM as a module. The module will be named
"qcom_rpm-regulator".
+config REGULATOR_QCOM_RPMH
+ tristate "Qualcomm Technologies, Inc. RPMh regulator driver"
+ depends on QCOM_RPMH || COMPILE_TEST
+ help
+ This driver supports control of PMIC regulators via the RPMh hardware
+ block found on Qualcomm Technologies Inc. SoCs. RPMh regulator
+ control allows for voting on regulator state between multiple
+ processors within the SoC.
+
config REGULATOR_QCOM_SMD_RPM
tristate "Qualcomm SMD based RPM regulator driver"
depends on QCOM_SMD_RPM
diff --git a/drivers/regulator/Makefile b/drivers/regulator/Makefile
index bd818ce..06e76a6 100644
--- a/drivers/regulator/Makefile
+++ b/drivers/regulator/Makefile
@@ -78,6 +78,7 @@ obj-$(CONFIG_REGULATOR_MT6323) += mt6323-regulator.o
obj-$(CONFIG_REGULATOR_MT6380) += mt6380-regulator.o
obj-$(CONFIG_REGULATOR_MT6397) += mt6397-regulator.o
obj-$(CONFIG_REGULATOR_QCOM_RPM) += qcom_rpm-regulator.o
+obj-$(CONFIG_REGULATOR_QCOM_RPMH) += qcom-rpmh-regulator.o
obj-$(CONFIG_REGULATOR_QCOM_SMD_RPM) += qcom_smd-regulator.o
obj-$(CONFIG_REGULATOR_QCOM_SPMI) += qcom_spmi-regulator.o
obj-$(CONFIG_REGULATOR_PALMAS) += palmas-regulator.o
diff --git a/drivers/regulator/qcom-rpmh-regulator.c b/drivers/regulator/qcom-rpmh-regulator.c
new file mode 100644
index 0000000..b2af35a
--- /dev/null
+++ b/drivers/regulator/qcom-rpmh-regulator.c
@@ -0,0 +1,770 @@
+// SPDX-License-Identifier: GPL-2.0
+/* Copyright (c) 2018, The Linux Foundation. All rights reserved. */
+
+#define pr_fmt(fmt) "%s: " fmt, __func__
+
+#include <linux/err.h>
+#include <linux/kernel.h>
+#include <linux/module.h>
+#include <linux/of.h>
+#include <linux/of_device.h>
+#include <linux/platform_device.h>
+#include <linux/slab.h>
+#include <linux/string.h>
+#include <linux/regulator/driver.h>
+#include <linux/regulator/machine.h>
+#include <linux/regulator/of_regulator.h>
+
+#include <soc/qcom/cmd-db.h>
+#include <soc/qcom/rpmh.h>
+
+#include <dt-bindings/regulator/qcom,rpmh-regulator.h>
+
+/**
+ * enum rpmh_regulator_type - supported RPMh accelerator types
+ * %VRM: RPMh VRM accelerator which supports voting on enable, voltage,
+ * and mode of LDO, SMPS, and BOB type PMIC regulators.
+ * %XOB: RPMh XOB accelerator which supports voting on the enable state
+ * of PMIC regulators.
+ */
+enum rpmh_regulator_type {
+ VRM,
+ XOB,
+};
+
+#define RPMH_VRM_HEADROOM_MAX_UV 511000
+
+#define RPMH_REGULATOR_REG_VRM_VOLTAGE 0x0
+#define RPMH_REGULATOR_REG_ENABLE 0x4
+#define RPMH_REGULATOR_REG_VRM_MODE 0x8
+#define RPMH_REGULATOR_REG_VRM_HEADROOM 0xC
+
+#define RPMH_REGULATOR_MODE_COUNT 4
+
+#define PMIC4_LDO_MODE_RETENTION 4
+#define PMIC4_LDO_MODE_LPM 5
+#define PMIC4_LDO_MODE_HPM 7
+
+#define PMIC4_SMPS_MODE_RETENTION 4
+#define PMIC4_SMPS_MODE_PFM 5
+#define PMIC4_SMPS_MODE_AUTO 6
+#define PMIC4_SMPS_MODE_PWM 7
+
+#define PMIC4_BOB_MODE_PASS 0
+#define PMIC4_BOB_MODE_PFM 1
+#define PMIC4_BOB_MODE_AUTO 2
+#define PMIC4_BOB_MODE_PWM 3
+
+/**
+ * struct rpmh_vreg_hw_data - RPMh regulator hardware configurations
+ * @regulator_type: RPMh accelerator type used to manage this
+ * regulator
+ * @ops: Pointer to regulator ops callback structure
+ * @voltage_range: The single range of voltages supported by this
+ * PMIC regulator type
+ * @n_voltages: The number of unique voltage set points defined
+ * by voltage_range
+ * @hpm_min_load_uA: Minimum load current in microamps that requires
+ * high power mode (HPM) operation. This is used
+ * for LDO hardware type regulators only.
+ * @pmic_mode_map: Array indexed by regulator framework mode
+ * containing PMIC hardware modes. Must be large
+ * enough to index all framework modes supported
+ * by this regulator hardware type.
+ * @of_map_mode: Maps an RPMH_REGULATOR_MODE_* mode value defined
+ * in device tree to a regulator framework mode
+ */
+struct rpmh_vreg_hw_data {
+ enum rpmh_regulator_type regulator_type;
+ const struct regulator_ops *ops;
+ const struct regulator_linear_range voltage_range;
+ int n_voltages;
+ int hpm_min_load_uA;
+ const int *pmic_mode_map;
+ unsigned int (*of_map_mode)(unsigned int mode);
+};
+
+/**
+ * struct rpmh_vreg - individual RPMh regulator data structure encapsulating a
+ * single regulator device
+ * @dev: Device pointer for the top-level PMIC RPMh
+ * regulator parent device. This is used as a
+ * handle in RPMh write requests.
+ * @addr: Base address of the regulator resource within
+ * an RPMh accelerator
+ * @rdesc: Regulator descriptor
+ * @hw_data: PMIC regulator configuration data for this RPMh
+ * regulator
+ * @always_wait_for_ack: Boolean flag indicating if a request must always
+ * wait for an ACK from RPMh before continuing even
+ * if it corresponds to a strictly lower power
+ * state (e.g. enabled --> disabled).
+ * @enabled: Flag indicating if the regulator is enabled or
+ * not
+ * @bypassed: Boolean indicating if the regulator is in
+ * bypass (pass-through) mode or not. This is
+ * only used by BOB rpmh-regulator resources.
+ * @voltage_selector: Selector used for get_voltage_sel() and
+ * set_voltage_sel() callbacks
+ * @mode: RPMh VRM regulator current framework mode
+ */
+struct rpmh_vreg {
+ struct device *dev;
+ u32 addr;
+ struct regulator_desc rdesc;
+ const struct rpmh_vreg_hw_data *hw_data;
+ bool always_wait_for_ack;
+
+ int enabled;
+ bool bypassed;
+ int voltage_selector;
+ unsigned int mode;
+};
+
+/**
+ * struct rpmh_vreg_init_data - initialization data for an RPMh regulator
+ * @name: Name for the regulator which also corresponds
+ * to the device tree subnode name of the regulator
+ * @resource_name: RPMh regulator resource name format string.
+ * This must include exactly one field: '%s' which
+ * is filled at run-time with the PMIC ID provided
+ * by device tree property qcom,pmic-id. Example:
+ * "ldo%s1" for RPMh resource "ldoa1".
+ * @supply_name: Parent supply regulator name
+ * @hw_data: Configuration data for this PMIC regulator type
+ */
+struct rpmh_vreg_init_data {
+ const char *name;
+ const char *resource_name;
+ const char *supply_name;
+ const struct rpmh_vreg_hw_data *hw_data;
+};
+
+/**
+ * rpmh_regulator_send_request() - send the request to RPMh
+ * @vreg: Pointer to the RPMh regulator
+ * @cmd: RPMh commands to send
+ * @count: Size of cmd array
+ * @wait_for_ack: Boolean indicating if execution must wait until the
+ * request has been acknowledged as complete
+ *
+ * Return: 0 on success, errno on failure
+ */
+static int rpmh_regulator_send_request(struct rpmh_vreg *vreg,
+ struct tcs_cmd *cmd, int count, bool wait_for_ack)
+{
+ int ret;
+
+ if (wait_for_ack || vreg->always_wait_for_ack)
+ ret = rpmh_write(vreg->dev, RPMH_ACTIVE_ONLY_STATE, cmd, count);
+ else
+ ret = rpmh_write_async(vreg->dev, RPMH_ACTIVE_ONLY_STATE, cmd,
+ count);
+
+ return ret;
+}
+
+static int _rpmh_regulator_vrm_set_voltage_sel(struct regulator_dev *rdev,
+ unsigned int selector, bool wait_for_ack)
+{
+ struct rpmh_vreg *vreg = rdev_get_drvdata(rdev);
+ struct tcs_cmd cmd = {
+ .addr = vreg->addr + RPMH_REGULATOR_REG_VRM_VOLTAGE,
+ };
+ int ret;
+
+ /* VRM voltage control register is set with voltage in millivolts. */
+ cmd.data = DIV_ROUND_UP(regulator_list_voltage_linear_range(rdev,
+ selector), 1000);
+
+ ret = rpmh_regulator_send_request(vreg, &cmd, 1, wait_for_ack);
+ if (!ret)
+ vreg->voltage_selector = selector;
+
+ return 0;
+}
+
+static int rpmh_regulator_vrm_set_voltage_sel(struct regulator_dev *rdev,
+ unsigned int selector)
+{
+ struct rpmh_vreg *vreg = rdev_get_drvdata(rdev);
+
+ if (vreg->enabled == -EINVAL) {
+ /*
+ * Cache the voltage and send it later when the regulator is
+ * enabled or disabled.
+ */
+ vreg->voltage_selector = selector;
+ return 0;
+ }
+
+ return _rpmh_regulator_vrm_set_voltage_sel(rdev, selector,
+ selector > vreg->voltage_selector);
+}
+
+static int rpmh_regulator_vrm_get_voltage_sel(struct regulator_dev *rdev)
+{
+ struct rpmh_vreg *vreg = rdev_get_drvdata(rdev);
+
+ return vreg->voltage_selector;
+}
+
+static int rpmh_regulator_is_enabled(struct regulator_dev *rdev)
+{
+ struct rpmh_vreg *vreg = rdev_get_drvdata(rdev);
+
+ return vreg->enabled;
+}
+
+static int rpmh_regulator_enable(struct regulator_dev *rdev)
+{
+ struct rpmh_vreg *vreg = rdev_get_drvdata(rdev);
+ struct tcs_cmd cmd = {
+ .addr = vreg->addr + RPMH_REGULATOR_REG_ENABLE,
+ .data = 1,
+ };
+ int ret;
+
+ if (vreg->enabled == -EINVAL &&
+ vreg->voltage_selector != -ENOTRECOVERABLE) {
+ ret = _rpmh_regulator_vrm_set_voltage_sel(rdev,
+ vreg->voltage_selector, true);
+ if (ret < 0)
+ return ret;
+ }
+
+ ret = rpmh_regulator_send_request(vreg, &cmd, 1, true);
+ if (!ret)
+ vreg->enabled = true;
+
+ return ret;
+}
+
+static int rpmh_regulator_disable(struct regulator_dev *rdev)
+{
+ struct rpmh_vreg *vreg = rdev_get_drvdata(rdev);
+ struct tcs_cmd cmd = {
+ .addr = vreg->addr + RPMH_REGULATOR_REG_ENABLE,
+ .data = 0,
+ };
+ int ret;
+
+ if (vreg->enabled == -EINVAL &&
+ vreg->voltage_selector != -ENOTRECOVERABLE) {
+ ret = _rpmh_regulator_vrm_set_voltage_sel(rdev,
+ vreg->voltage_selector, true);
+ if (ret < 0)
+ return ret;
+ }
+
+ ret = rpmh_regulator_send_request(vreg, &cmd, 1, false);
+ if (!ret)
+ vreg->enabled = false;
+
+ return ret;
+}
+
+static int rpmh_regulator_vrm_set_mode_bypass(struct rpmh_vreg *vreg,
+ unsigned int mode, bool bypassed)
+{
+ struct tcs_cmd cmd = {
+ .addr = vreg->addr + RPMH_REGULATOR_REG_VRM_MODE,
+ };
+ int pmic_mode;
+
+ if (mode > REGULATOR_MODE_STANDBY)
+ return -EINVAL;
+
+ pmic_mode = vreg->hw_data->pmic_mode_map[mode];
+ if (pmic_mode < 0)
+ return pmic_mode;
+
+ cmd.data = bypassed ? PMIC4_BOB_MODE_PASS : pmic_mode;
+
+ return rpmh_regulator_send_request(vreg, &cmd, 1, true);
+}
+
+static int rpmh_regulator_vrm_set_mode(struct regulator_dev *rdev,
+ unsigned int mode)
+{
+ struct rpmh_vreg *vreg = rdev_get_drvdata(rdev);
+ int ret;
+
+ if (mode == vreg->mode)
+ return 0;
+
+ ret = rpmh_regulator_vrm_set_mode_bypass(vreg, mode, vreg->bypassed);
+ if (!ret)
+ vreg->mode = mode;
+
+ return ret;
+}
+
+static unsigned int rpmh_regulator_vrm_get_mode(struct regulator_dev *rdev)
+{
+ struct rpmh_vreg *vreg = rdev_get_drvdata(rdev);
+
+ return vreg->mode;
+}
+
+/**
+ * rpmh_regulator_vrm_set_load() - set the regulator mode based upon the load
+ * current requested
+ * @rdev: Regulator device pointer for the rpmh-regulator
+ * @load_uA: Aggregated load current in microamps
+ *
+ * This function is used in the regulator_ops for VRM type RPMh regulator
+ * devices.
+ *
+ * Return: 0 on success, errno on failure
+ */
+static int rpmh_regulator_vrm_set_load(struct regulator_dev *rdev, int load_uA)
+{
+ struct rpmh_vreg *vreg = rdev_get_drvdata(rdev);
+ unsigned int mode;
+
+ if (load_uA >= vreg->hw_data->hpm_min_load_uA)
+ mode = REGULATOR_MODE_FAST;
+ else
+ mode = REGULATOR_MODE_IDLE;
+
+ return rpmh_regulator_vrm_set_mode(rdev, mode);
+}
+
+static int rpmh_regulator_vrm_set_bypass(struct regulator_dev *rdev,
+ bool enable)
+{
+ struct rpmh_vreg *vreg = rdev_get_drvdata(rdev);
+ int ret;
+
+ if (vreg->bypassed == enable)
+ return 0;
+
+ ret = rpmh_regulator_vrm_set_mode_bypass(vreg, vreg->mode, enable);
+ if (!ret)
+ vreg->bypassed = enable;
+
+ return ret;
+}
+
+static int rpmh_regulator_vrm_get_bypass(struct regulator_dev *rdev,
+ bool *enable)
+{
+ struct rpmh_vreg *vreg = rdev_get_drvdata(rdev);
+
+ *enable = vreg->bypassed;
+
+ return 0;
+}
+
+static const struct regulator_ops rpmh_regulator_vrm_ops = {
+ .enable = rpmh_regulator_enable,
+ .disable = rpmh_regulator_disable,
+ .is_enabled = rpmh_regulator_is_enabled,
+ .set_voltage_sel = rpmh_regulator_vrm_set_voltage_sel,
+ .get_voltage_sel = rpmh_regulator_vrm_get_voltage_sel,
+ .list_voltage = regulator_list_voltage_linear_range,
+ .set_mode = rpmh_regulator_vrm_set_mode,
+ .get_mode = rpmh_regulator_vrm_get_mode,
+};
+
+static const struct regulator_ops rpmh_regulator_vrm_drms_ops = {
+ .enable = rpmh_regulator_enable,
+ .disable = rpmh_regulator_disable,
+ .is_enabled = rpmh_regulator_is_enabled,
+ .set_voltage_sel = rpmh_regulator_vrm_set_voltage_sel,
+ .get_voltage_sel = rpmh_regulator_vrm_get_voltage_sel,
+ .list_voltage = regulator_list_voltage_linear_range,
+ .set_mode = rpmh_regulator_vrm_set_mode,
+ .get_mode = rpmh_regulator_vrm_get_mode,
+ .set_load = rpmh_regulator_vrm_set_load,
+};
+
+static const struct regulator_ops rpmh_regulator_vrm_bypass_ops = {
+ .enable = rpmh_regulator_enable,
+ .disable = rpmh_regulator_disable,
+ .is_enabled = rpmh_regulator_is_enabled,
+ .set_voltage_sel = rpmh_regulator_vrm_set_voltage_sel,
+ .get_voltage_sel = rpmh_regulator_vrm_get_voltage_sel,
+ .list_voltage = regulator_list_voltage_linear_range,
+ .set_mode = rpmh_regulator_vrm_set_mode,
+ .get_mode = rpmh_regulator_vrm_get_mode,
+ .set_bypass = rpmh_regulator_vrm_set_bypass,
+ .get_bypass = rpmh_regulator_vrm_get_bypass,
+};
+
+static const struct regulator_ops rpmh_regulator_xob_ops = {
+ .enable = rpmh_regulator_enable,
+ .disable = rpmh_regulator_disable,
+ .is_enabled = rpmh_regulator_is_enabled,
+};
+
+/**
+ * rpmh_regulator_init_vreg() - initialize all attributes of an rpmh-regulator
+ * vreg: Pointer to the individual rpmh-regulator resource
+ * dev: Pointer to the top level rpmh-regulator PMIC device
+ * node: Pointer to the individual rpmh-regulator resource
+ * device node
+ * pmic_id: String used to identify the top level rpmh-regulator
+ * PMIC device on the board
+ * rpmh_data: Pointer to a null-terminated array of rpmh-regulator
+ * resources defined for the top level PMIC device
+ *
+ * Return: 0 on success, errno on failure
+ */
+static int rpmh_regulator_init_vreg(struct rpmh_vreg *vreg, struct device *dev,
+ struct device_node *node, const char *pmic_id,
+ const struct rpmh_vreg_init_data *rpmh_data)
+{
+ struct regulator_config reg_config = {};
+ char rpmh_resource_name[20] = "";
+ struct regulator_dev *rdev;
+ struct regulator_init_data *init_data;
+ int ret;
+
+ vreg->dev = dev;
+
+ for (; rpmh_data->name; rpmh_data++)
+ if (!strcmp(rpmh_data->name, node->name))
+ break;
+
+ if (!rpmh_data->name) {
+ dev_err(dev, "Unknown regulator %s\n", node->name);
+ return -EINVAL;
+ }
+
+ scnprintf(rpmh_resource_name, sizeof(rpmh_resource_name),
+ rpmh_data->resource_name, pmic_id);
+
+ vreg->addr = cmd_db_read_addr(rpmh_resource_name);
+ if (!vreg->addr) {
+ dev_err(dev, "%s: could not find RPMh address for resource %s\n",
+ node->name, rpmh_resource_name);
+ return -ENODEV;
+ }
+
+ vreg->rdesc.name = rpmh_data->name;
+ vreg->rdesc.supply_name = rpmh_data->supply_name;
+ vreg->hw_data = rpmh_data->hw_data;
+
+ vreg->enabled = -EINVAL;
+ vreg->voltage_selector = -ENOTRECOVERABLE;
+ vreg->mode = REGULATOR_MODE_INVALID;
+
+ if (rpmh_data->hw_data->n_voltages) {
+ vreg->rdesc.linear_ranges = &rpmh_data->hw_data->voltage_range;
+ vreg->rdesc.n_linear_ranges = 1;
+ vreg->rdesc.n_voltages = rpmh_data->hw_data->n_voltages;
+ }
+
+ vreg->always_wait_for_ack = of_property_read_bool(node,
+ "qcom,always-wait-for-ack");
+
+ vreg->rdesc.owner = THIS_MODULE;
+ vreg->rdesc.type = REGULATOR_VOLTAGE;
+ vreg->rdesc.ops = vreg->hw_data->ops;
+ vreg->rdesc.of_map_mode = vreg->hw_data->of_map_mode;
+
+ init_data = of_get_regulator_init_data(dev, node, &vreg->rdesc);
+ if (!init_data)
+ return -ENOMEM;
+
+ if (rpmh_data->hw_data->regulator_type == XOB &&
+ init_data->constraints.min_uV &&
+ init_data->constraints.min_uV == init_data->constraints.max_uV) {
+ vreg->rdesc.fixed_uV = init_data->constraints.min_uV;
+ vreg->rdesc.n_voltages = 1;
+ }
+
+ reg_config.dev = dev;
+ reg_config.init_data = init_data;
+ reg_config.of_node = node;
+ reg_config.driver_data = vreg;
+
+ rdev = devm_regulator_register(dev, &vreg->rdesc, ®_config);
+ if (IS_ERR(rdev)) {
+ ret = PTR_ERR(rdev);
+ rdev = NULL;
+ dev_err(dev, "%s: devm_regulator_register() failed, ret=%d\n",
+ node->name, ret);
+ return ret;
+ }
+
+ dev_dbg(dev, "%s regulator registered for RPMh resource %s @ 0x%05X\n",
+ node->name, rpmh_resource_name, vreg->addr);
+
+ return 0;
+}
+
+static const int pmic_mode_map_pmic4_ldo[REGULATOR_MODE_STANDBY + 1] = {
+ [REGULATOR_MODE_INVALID] = -EINVAL,
+ [REGULATOR_MODE_STANDBY] = PMIC4_LDO_MODE_RETENTION,
+ [REGULATOR_MODE_IDLE] = PMIC4_LDO_MODE_LPM,
+ [REGULATOR_MODE_NORMAL] = -EINVAL,
+ [REGULATOR_MODE_FAST] = PMIC4_LDO_MODE_HPM,
+};
+
+static unsigned int rpmh_regulator_pmic4_ldo_of_map_mode(unsigned int mode)
+{
+ static const unsigned int of_mode_map[RPMH_REGULATOR_MODE_COUNT] = {
+ [RPMH_REGULATOR_MODE_RET] = REGULATOR_MODE_STANDBY,
+ [RPMH_REGULATOR_MODE_LPM] = REGULATOR_MODE_IDLE,
+ [RPMH_REGULATOR_MODE_AUTO] = REGULATOR_MODE_INVALID,
+ [RPMH_REGULATOR_MODE_HPM] = REGULATOR_MODE_FAST,
+ };
+
+ if (mode >= RPMH_REGULATOR_MODE_COUNT)
+ return -EINVAL;
+
+ return of_mode_map[mode];
+}
+
+static const int pmic_mode_map_pmic4_smps[REGULATOR_MODE_STANDBY + 1] = {
+ [REGULATOR_MODE_INVALID] = -EINVAL,
+ [REGULATOR_MODE_STANDBY] = PMIC4_SMPS_MODE_RETENTION,
+ [REGULATOR_MODE_IDLE] = PMIC4_SMPS_MODE_PFM,
+ [REGULATOR_MODE_NORMAL] = PMIC4_SMPS_MODE_AUTO,
+ [REGULATOR_MODE_FAST] = PMIC4_SMPS_MODE_PWM,
+};
+
+static unsigned int rpmh_regulator_pmic4_smps_of_map_mode(unsigned int mode)
+{
+ static const unsigned int of_mode_map[RPMH_REGULATOR_MODE_COUNT] = {
+ [RPMH_REGULATOR_MODE_RET] = REGULATOR_MODE_STANDBY,
+ [RPMH_REGULATOR_MODE_LPM] = REGULATOR_MODE_IDLE,
+ [RPMH_REGULATOR_MODE_AUTO] = REGULATOR_MODE_NORMAL,
+ [RPMH_REGULATOR_MODE_HPM] = REGULATOR_MODE_FAST,
+ };
+
+ if (mode >= RPMH_REGULATOR_MODE_COUNT)
+ return -EINVAL;
+
+ return of_mode_map[mode];
+}
+
+static const int pmic_mode_map_pmic4_bob[REGULATOR_MODE_STANDBY + 1] = {
+ [REGULATOR_MODE_INVALID] = -EINVAL,
+ [REGULATOR_MODE_STANDBY] = -EINVAL,
+ [REGULATOR_MODE_IDLE] = PMIC4_BOB_MODE_PFM,
+ [REGULATOR_MODE_NORMAL] = PMIC4_BOB_MODE_AUTO,
+ [REGULATOR_MODE_FAST] = PMIC4_BOB_MODE_PWM,
+};
+
+static unsigned int rpmh_regulator_pmic4_bob_of_map_mode(unsigned int mode)
+{
+ static const unsigned int of_mode_map[RPMH_REGULATOR_MODE_COUNT] = {
+ [RPMH_REGULATOR_MODE_RET] = REGULATOR_MODE_INVALID,
+ [RPMH_REGULATOR_MODE_LPM] = REGULATOR_MODE_IDLE,
+ [RPMH_REGULATOR_MODE_AUTO] = REGULATOR_MODE_NORMAL,
+ [RPMH_REGULATOR_MODE_HPM] = REGULATOR_MODE_FAST,
+ };
+
+ if (mode >= RPMH_REGULATOR_MODE_COUNT)
+ return -EINVAL;
+
+ return of_mode_map[mode];
+}
+
+static const struct rpmh_vreg_hw_data pmic4_pldo = {
+ .regulator_type = VRM,
+ .ops = &rpmh_regulator_vrm_drms_ops,
+ .voltage_range = REGULATOR_LINEAR_RANGE(1664000, 0, 255, 8000),
+ .n_voltages = 256,
+ .hpm_min_load_uA = 10000,
+ .pmic_mode_map = pmic_mode_map_pmic4_ldo,
+ .of_map_mode = rpmh_regulator_pmic4_ldo_of_map_mode,
+};
+
+static const struct rpmh_vreg_hw_data pmic4_pldo_lv = {
+ .regulator_type = VRM,
+ .ops = &rpmh_regulator_vrm_drms_ops,
+ .voltage_range = REGULATOR_LINEAR_RANGE(1256000, 0, 127, 8000),
+ .n_voltages = 128,
+ .hpm_min_load_uA = 10000,
+ .pmic_mode_map = pmic_mode_map_pmic4_ldo,
+ .of_map_mode = rpmh_regulator_pmic4_ldo_of_map_mode,
+};
+
+static const struct rpmh_vreg_hw_data pmic4_nldo = {
+ .regulator_type = VRM,
+ .ops = &rpmh_regulator_vrm_drms_ops,
+ .voltage_range = REGULATOR_LINEAR_RANGE(312000, 0, 127, 8000),
+ .n_voltages = 128,
+ .hpm_min_load_uA = 30000,
+ .pmic_mode_map = pmic_mode_map_pmic4_ldo,
+ .of_map_mode = rpmh_regulator_pmic4_ldo_of_map_mode,
+};
+
+static const struct rpmh_vreg_hw_data pmic4_hfsmps3 = {
+ .regulator_type = VRM,
+ .ops = &rpmh_regulator_vrm_ops,
+ .voltage_range = REGULATOR_LINEAR_RANGE(320000, 0, 215, 8000),
+ .n_voltages = 216,
+ .pmic_mode_map = pmic_mode_map_pmic4_smps,
+ .of_map_mode = rpmh_regulator_pmic4_smps_of_map_mode,
+};
+
+static const struct rpmh_vreg_hw_data pmic4_ftsmps426 = {
+ .regulator_type = VRM,
+ .ops = &rpmh_regulator_vrm_ops,
+ .voltage_range = REGULATOR_LINEAR_RANGE(320000, 0, 258, 4000),
+ .n_voltages = 259,
+ .pmic_mode_map = pmic_mode_map_pmic4_smps,
+ .of_map_mode = rpmh_regulator_pmic4_smps_of_map_mode,
+};
+
+static const struct rpmh_vreg_hw_data pmic4_bob = {
+ .regulator_type = VRM,
+ .ops = &rpmh_regulator_vrm_bypass_ops,
+ .voltage_range = REGULATOR_LINEAR_RANGE(1824000, 0, 83, 32000),
+ .n_voltages = 84,
+ .pmic_mode_map = pmic_mode_map_pmic4_bob,
+ .of_map_mode = rpmh_regulator_pmic4_bob_of_map_mode,
+};
+
+static const struct rpmh_vreg_hw_data pmic4_lvs = {
+ .regulator_type = XOB,
+ .ops = &rpmh_regulator_xob_ops,
+ /* LVS hardware does not support voltage or mode configuration. */
+};
+
+#define RPMH_VREG(_name, _resource_name, _hw_data, _supply_name) \
+{ \
+ .name = _name, \
+ .resource_name = _resource_name, \
+ .hw_data = _hw_data, \
+ .supply_name = _supply_name, \
+}
+
+static const struct rpmh_vreg_init_data pm8998_vreg_data[] = {
+ RPMH_VREG("smps1", "smp%s1", &pmic4_ftsmps426, "vdd-s1"),
+ RPMH_VREG("smps2", "smp%s2", &pmic4_ftsmps426, "vdd-s2"),
+ RPMH_VREG("smps3", "smp%s3", &pmic4_hfsmps3, "vdd-s3"),
+ RPMH_VREG("smps4", "smp%s4", &pmic4_hfsmps3, "vdd-s4"),
+ RPMH_VREG("smps5", "smp%s5", &pmic4_hfsmps3, "vdd-s5"),
+ RPMH_VREG("smps6", "smp%s6", &pmic4_ftsmps426, "vdd-s6"),
+ RPMH_VREG("smps7", "smp%s7", &pmic4_ftsmps426, "vdd-s7"),
+ RPMH_VREG("smps8", "smp%s8", &pmic4_ftsmps426, "vdd-s8"),
+ RPMH_VREG("smps9", "smp%s9", &pmic4_ftsmps426, "vdd-s9"),
+ RPMH_VREG("smps10", "smp%s10", &pmic4_ftsmps426, "vdd-s10"),
+ RPMH_VREG("smps11", "smp%s11", &pmic4_ftsmps426, "vdd-s11"),
+ RPMH_VREG("smps12", "smp%s12", &pmic4_ftsmps426, "vdd-s12"),
+ RPMH_VREG("smps13", "smp%s13", &pmic4_ftsmps426, "vdd-s13"),
+ RPMH_VREG("ldo1", "ldo%s1", &pmic4_nldo, "vdd-l1-l27"),
+ RPMH_VREG("ldo2", "ldo%s2", &pmic4_nldo, "vdd-l2-l8-l17"),
+ RPMH_VREG("ldo3", "ldo%s3", &pmic4_nldo, "vdd-l3-l11"),
+ RPMH_VREG("ldo4", "ldo%s4", &pmic4_nldo, "vdd-l4-l5"),
+ RPMH_VREG("ldo5", "ldo%s5", &pmic4_nldo, "vdd-l4-l5"),
+ RPMH_VREG("ldo6", "ldo%s6", &pmic4_pldo, "vdd-l6"),
+ RPMH_VREG("ldo7", "ldo%s7", &pmic4_pldo_lv, "vdd-l7-l12-l14-l15"),
+ RPMH_VREG("ldo8", "ldo%s8", &pmic4_nldo, "vdd-l2-l8-l17"),
+ RPMH_VREG("ldo9", "ldo%s9", &pmic4_pldo, "vdd-l9"),
+ RPMH_VREG("ldo10", "ldo%s10", &pmic4_pldo, "vdd-l10-l23-l25"),
+ RPMH_VREG("ldo11", "ldo%s11", &pmic4_nldo, "vdd-l3-l11"),
+ RPMH_VREG("ldo12", "ldo%s12", &pmic4_pldo_lv, "vdd-l7-l12-l14-l15"),
+ RPMH_VREG("ldo13", "ldo%s13", &pmic4_pldo, "vdd-l13-l19-l21"),
+ RPMH_VREG("ldo14", "ldo%s14", &pmic4_pldo_lv, "vdd-l7-l12-l14-l15"),
+ RPMH_VREG("ldo15", "ldo%s15", &pmic4_pldo_lv, "vdd-l7-l12-l14-l15"),
+ RPMH_VREG("ldo16", "ldo%s16", &pmic4_pldo, "vdd-l16-l28"),
+ RPMH_VREG("ldo17", "ldo%s17", &pmic4_nldo, "vdd-l2-l8-l17"),
+ RPMH_VREG("ldo18", "ldo%s18", &pmic4_pldo, "vdd-l18-l22"),
+ RPMH_VREG("ldo19", "ldo%s19", &pmic4_pldo, "vdd-l13-l19-l21"),
+ RPMH_VREG("ldo20", "ldo%s20", &pmic4_pldo, "vdd-l20-l24"),
+ RPMH_VREG("ldo21", "ldo%s21", &pmic4_pldo, "vdd-l13-l19-l21"),
+ RPMH_VREG("ldo22", "ldo%s22", &pmic4_pldo, "vdd-l18-l22"),
+ RPMH_VREG("ldo23", "ldo%s23", &pmic4_pldo, "vdd-l10-l23-l25"),
+ RPMH_VREG("ldo24", "ldo%s24", &pmic4_pldo, "vdd-l20-l24"),
+ RPMH_VREG("ldo25", "ldo%s25", &pmic4_pldo, "vdd-l10-l23-l25"),
+ RPMH_VREG("ldo26", "ldo%s26", &pmic4_nldo, "vdd-l26"),
+ RPMH_VREG("ldo27", "ldo%s27", &pmic4_nldo, "vdd-l1-l27"),
+ RPMH_VREG("ldo28", "ldo%s28", &pmic4_pldo, "vdd-l16-l28"),
+ RPMH_VREG("lvs1", "vs%s1", &pmic4_lvs, "vin-lvs-1-2"),
+ RPMH_VREG("lvs2", "vs%s2", &pmic4_lvs, "vin-lvs-1-2"),
+ {},
+};
+
+static const struct rpmh_vreg_init_data pmi8998_vreg_data[] = {
+ RPMH_VREG("bob", "bob%s1", &pmic4_bob, "vdd-bob"),
+ {},
+};
+
+static const struct rpmh_vreg_init_data pm8005_vreg_data[] = {
+ RPMH_VREG("smps1", "smp%s1", &pmic4_ftsmps426, "vdd-s1"),
+ RPMH_VREG("smps2", "smp%s2", &pmic4_ftsmps426, "vdd-s2"),
+ RPMH_VREG("smps3", "smp%s3", &pmic4_ftsmps426, "vdd-s3"),
+ RPMH_VREG("smps4", "smp%s4", &pmic4_ftsmps426, "vdd-s4"),
+ {},
+};
+
+static int rpmh_regulator_probe(struct platform_device *pdev)
+{
+ struct device *dev = &pdev->dev;
+ const struct rpmh_vreg_init_data *vreg_data;
+ struct device_node *node;
+ struct rpmh_vreg *vreg;
+ const char *pmic_id;
+ int ret;
+
+ ret = cmd_db_ready();
+ if (ret < 0) {
+ if (ret != -EPROBE_DEFER)
+ dev_err(dev, "Command DB not available, ret=%d\n", ret);
+ return ret;
+ }
+
+ vreg_data = of_device_get_match_data(dev);
+ if (!vreg_data)
+ return -ENODEV;
+
+ ret = of_property_read_string(dev->of_node, "qcom,pmic-id", &pmic_id);
+ if (ret < 0) {
+ dev_err(dev, "qcom,pmic-id missing in DT node\n");
+ return ret;
+ }
+
+ for_each_available_child_of_node(dev->of_node, node) {
+ vreg = devm_kzalloc(dev, sizeof(*vreg), GFP_KERNEL);
+ if (!vreg) {
+ of_node_put(node);
+ return -ENOMEM;
+ }
+
+ ret = rpmh_regulator_init_vreg(vreg, dev, node, pmic_id,
+ vreg_data);
+ if (ret < 0) {
+ of_node_put(node);
+ return ret;
+ }
+ }
+
+ return 0;
+}
+
+static const struct of_device_id rpmh_regulator_match_table[] = {
+ {
+ .compatible = "qcom,pm8998-rpmh-regulators",
+ .data = pm8998_vreg_data,
+ },
+ {
+ .compatible = "qcom,pmi8998-rpmh-regulators",
+ .data = pmi8998_vreg_data,
+ },
+ {
+ .compatible = "qcom,pm8005-rpmh-regulators",
+ .data = pm8005_vreg_data,
+ },
+ {}
+};
+MODULE_DEVICE_TABLE(of, rpmh_regulator_match_table);
+
+static struct platform_driver rpmh_regulator_driver = {
+ .driver = {
+ .name = "qcom-rpmh-regulator",
+ .of_match_table = of_match_ptr(rpmh_regulator_match_table),
+ },
+ .probe = rpmh_regulator_probe,
+};
+module_platform_driver(rpmh_regulator_driver);
+
+MODULE_DESCRIPTION("Qualcomm RPMh regulator driver");
+MODULE_LICENSE("GPL v2");
--
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,
a Linux Foundation Collaborative Project
^ permalink raw reply related
* Re: [PATCH v3 2/5] clk: imx6: add EPIT clock support
From: Stephen Boyd @ 2018-06-02 2:19 UTC (permalink / raw)
To: Clément Péron, Colin Didier, devicetree,
linux-arm-kernel, linux-clk
Cc: Rob Herring, Sascha Hauer, Clément Peron, NXP Linux Team,
Pengutronix Kernel Team, Fabio Estevam, Vladimir Zapolskiy
In-Reply-To: <20180529170436.22711-3-peron.clem@gmail.com>
Quoting Clément Péron (2018-05-29 10:04:33)
> From: Colin Didier <colin.didier@devialet.com>
>
> Add EPIT clock support to the i.MX6Q clocking infrastructure.
>
> Signed-off-by: Colin Didier <colin.didier@devialet.com>
> Signed-off-by: Clément Peron <clement.peron@devialet.com>
> Reviewed-by: Fabio Estevam <fabio.estevam@nxp.com>
> ---
Applied to clk-next
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH v2 5/8] gnss: add driver for u-blox receivers
From: kbuild test robot @ 2018-06-02 6:07 UTC (permalink / raw)
Cc: kbuild-all, Greg Kroah-Hartman, Rob Herring, Mark Rutland,
Andreas Kemnade, Arnd Bergmann, H . Nikolaus Schaller,
Pavel Machek, Marcel Holtmann, Sebastian Reichel, Tony Lindgren,
linux-kernel, devicetree, Johan Hovold
In-Reply-To: <20180530103242.20773-6-johan@kernel.org>
Hi Johan,
I love your patch! Perhaps something to improve:
[auto build test WARNING on linus/master]
[also build test WARNING on v4.17-rc7 next-20180601]
[if your patch is applied to the wrong git tree, please drop us a note to help improve the system]
url: https://github.com/0day-ci/linux/commits/Johan-Hovold/gnss-add-new-GNSS-subsystem/20180602-020421
reproduce:
# apt-get install sparse
make ARCH=x86_64 allmodconfig
make C=1 CF=-D__CHECK_ENDIAN__
sparse warnings: (new ones prefixed by >>)
>> drivers/gnss/ubx.c:62:30: sparse: symbol 'ubx_gserial_ops' was not declared. Should it be static?
Please review and possibly fold the followup patch.
---
0-DAY kernel test infrastructure Open Source Technology Center
https://lists.01.org/pipermail/kbuild-all Intel Corporation
^ permalink raw reply
* [RFC PATCH] gnss: ubx_gserial_ops can be static
From: kbuild test robot @ 2018-06-02 6:07 UTC (permalink / raw)
Cc: kbuild-all, Greg Kroah-Hartman, Rob Herring, Mark Rutland,
Andreas Kemnade, Arnd Bergmann, H . Nikolaus Schaller,
Pavel Machek, Marcel Holtmann, Sebastian Reichel, Tony Lindgren,
linux-kernel, devicetree, Johan Hovold
In-Reply-To: <20180530103242.20773-6-johan@kernel.org>
Fixes: 45cad4b6d339 ("gnss: add driver for u-blox receivers")
Signed-off-by: kbuild test robot <fengguang.wu@intel.com>
---
ubx.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/gnss/ubx.c b/drivers/gnss/ubx.c
index ecddfb3..c7dcfdc 100644
--- a/drivers/gnss/ubx.c
+++ b/drivers/gnss/ubx.c
@@ -59,7 +59,7 @@ static int ubx_set_power(struct gnss_serial *gserial,
return -EINVAL;
}
-const struct gnss_serial_ops ubx_gserial_ops = {
+static const struct gnss_serial_ops ubx_gserial_ops = {
.set_power = ubx_set_power,
};
^ permalink raw reply related
* Re: [PATCH v2 2/2] clk: Add driver for MAX9485
From: Stephen Boyd @ 2018-06-02 6:13 UTC (permalink / raw)
To: Daniel Mack, mturquette; +Cc: linux-clk, robh, devicetree, Daniel Mack
In-Reply-To: <20180525182058.25969-3-daniel@zonque.org>
Quoting Daniel Mack (2018-05-25 11:20:58)
> diff --git a/drivers/clk/Kconfig b/drivers/clk/Kconfig
> index 34968a381d0f..f8ab54c41d16 100644
> --- a/drivers/clk/Kconfig
> +++ b/drivers/clk/Kconfig
> @@ -45,6 +45,14 @@ config COMMON_CLK_MAX77686
> This driver supports Maxim 77620/77686/77802 crystal oscillator
> clock.
>
> +config COMMON_CLK_MAX9485
> + tristate "Clock driver for Maxim 9485 Programmable Clock Generator"
> + depends on I2C
> + depends on OF
Drop this depends? Probably not needed to compile this driver.
> + depends on GPIOLIB || COMPILE_TEST
Is this common? I never knew.
> + ---help---
> + This driver supports Maxim 9485 Programmable Audio Clock Generator
> +
> config COMMON_CLK_RK808
> tristate "Clock driver for RK805/RK808/RK818"
> depends on MFD_RK808
> diff --git a/drivers/clk/clk-max9485.c b/drivers/clk/clk-max9485.c
> new file mode 100644
> index 000000000000..9bbf2fee49c5
> --- /dev/null
> +++ b/drivers/clk/clk-max9485.c
> @@ -0,0 +1,408 @@
> +// SPDX-License-Identifier: GPL-2.0
> +/*
> + * clk-max9485.c: MAX9485 Programmable Audio Clock Generator
> + *
> + * (c) 2018 Daniel Mack <daniel@zonque.org>
> + *
> + * References:
> + * MAX9485 Datasheet
> + * http://www.maximintegrated.com/datasheet/index.mvp/id/4421
> + *
> + * This program is free software; you can redistribute it and/or modify it
> + * under the terms of the GNU General Public License as published by the
> + * Free Software Foundation; either version 2 of the License, or (at your
> + * option) any later version.
> + */
> +
> +#include <linux/module.h>
> +#include <linux/kernel.h>
> +#include <linux/clkdev.h>
Is this used?
> +#include <linux/clk.h>
> +#include <linux/clk-provider.h>
> +#include <linux/err.h>
> +#include <linux/errno.h>
> +#include <linux/gpio/consumer.h>
> +#include <linux/i2c.h>
> +#include <linux/regulator/consumer.h>
> +
> +#include <dt-bindings/clock/maxim,max9485.h>
> +
> +#define MAX9485_INPUT_FREQ 27000000UL
> +#define MAX9485_NUM_CLKS 4
> +
> +/* This chip has only one register of 8 bit width. */
So efficient!
> +
> +enum {
> + MAX9485_FS_12KHZ = 0 << 0,
> + MAX9485_FS_32KHZ = 1 << 0,
> + MAX9485_FS_44_1KHZ = 2 << 0,
> + MAX9485_FS_48KHZ = 3 << 0,
> +};
> +
> +enum {
> + MAX9485_SCALE_256 = 0 << 2,
> + MAX9485_SCALE_384 = 1 << 2,
> + MAX9485_SCALE_768 = 2 << 2,
> +};
Any reason to be an enum? Maybe they can just be #defines.
> +
> +#define MAX9485_DOUBLE BIT(4)
> +#define MAX9485_CLKOUT1_ENABLE BIT(5)
> +#define MAX9485_CLKOUT2_ENABLE BIT(6)
> +#define MAX9485_MCLK_ENABLE BIT(7)
> +#define MAX9485_FREQ_MASK 0x1f
> +
> +struct max9485_rate {
> + unsigned long out;
> + u8 reg_value;
> +};
> +
> +/*
> + * Ordered by frequency. For frequency the hardware can generate with
> + * multiple settings, only the one with lowest jitter is listed.
> + */
> +static const struct max9485_rate max9485_rates[] = {
> + { 3072000, MAX9485_FS_12KHZ | MAX9485_SCALE_256 },
> + { 4608000, MAX9485_FS_12KHZ | MAX9485_SCALE_384 },
> + { 8192000, MAX9485_FS_32KHZ | MAX9485_SCALE_256 },
> + { 9126000, MAX9485_FS_12KHZ | MAX9485_SCALE_768 },
> + { 11289600, MAX9485_FS_44_1KHZ | MAX9485_SCALE_256 },
> + { 12288000, MAX9485_FS_48KHZ | MAX9485_SCALE_256 },
> + { 16384000, MAX9485_FS_32KHZ | MAX9485_SCALE_256 | MAX9485_DOUBLE },
> + { 16934400, MAX9485_FS_44_1KHZ | MAX9485_SCALE_384 },
> + { 18384000, MAX9485_FS_48KHZ | MAX9485_SCALE_384 },
> + { 22579200, MAX9485_FS_44_1KHZ | MAX9485_SCALE_256 | MAX9485_DOUBLE },
> + { 24576000, MAX9485_FS_48KHZ | MAX9485_SCALE_256 | MAX9485_DOUBLE },
> + { 33868800, MAX9485_FS_44_1KHZ | MAX9485_SCALE_384 | MAX9485_DOUBLE },
> + { 36864000, MAX9485_FS_48KHZ | MAX9485_SCALE_384 | MAX9485_DOUBLE },
> + { 49152000, MAX9485_FS_32KHZ | MAX9485_SCALE_768 | MAX9485_DOUBLE },
> + { 67737600, MAX9485_FS_44_1KHZ | MAX9485_SCALE_768 | MAX9485_DOUBLE },
> + { 73728000, MAX9485_FS_48KHZ | MAX9485_SCALE_768 | MAX9485_DOUBLE },
> + { } /* sentinel */
> +};
> +
> +struct max9485_driver_data;
> +
> +struct max9485_clk_hw {
> + struct clk_hw hw;
> + struct clk_init_data init;
> + u8 enable_bit;
> + struct max9485_driver_data *drvdata;
> +};
> +
> +struct max9485_driver_data {
> + struct clk *xclk;
> + struct i2c_client *client;
> + u8 reg_value;
> + unsigned long clkout_rate;
> + struct regulator *supply;
> + struct gpio_desc *reset_gpio;
> + struct max9485_clk_hw hw[MAX9485_NUM_CLKS];
> +
> + struct {
> + struct clk_hw_onecell_data data;
> + struct clk_hw *hw[MAX9485_NUM_CLKS];
I don't quite understand this one. There's already an array of clk_hw
pointers inside of clk_hw_onecell_data so just use that? But then
there's also an array of max9485_clk_hw structures, so maybe roll your
own clk_hw getter function?
> + } onecell;
> +};
> +
> +static int max9485_update_bits(struct max9485_driver_data *drvdata,
> + u8 mask, u8 value)
> +{
> + int ret;
> +
> + drvdata->reg_value &= ~mask;
> + drvdata->reg_value |= value;
> +
> + dev_dbg(&drvdata->client->dev,
> + "updating mask %02x value %02x -> %02x\n",
> + mask, value, drvdata->reg_value);
> +
> + ret = i2c_master_send(drvdata->client,
> + &drvdata->reg_value,
> + sizeof(drvdata->reg_value));
Maybe use a regmap instead? Then you could use regmap_update_bits() in
the places you need it.
> +
> + return (ret < 0) ? ret : 0;
> +}
> +
> +static int max9485_clk_prepare(struct clk_hw *hw)
> +{
> + struct max9485_clk_hw *clk_hw =
> + container_of(hw, struct max9485_clk_hw, hw);
Please make a static inline function for this line called something like
to_max8458_clk().
> +
> + return max9485_update_bits(clk_hw->drvdata,
> + clk_hw->enable_bit,
> + clk_hw->enable_bit);
> +}
> +
> +static void max9485_clk_unprepare(struct clk_hw *hw)
> +{
> + struct max9485_clk_hw *clk_hw =
> + container_of(hw, struct max9485_clk_hw, hw);
> +
> + max9485_update_bits(clk_hw->drvdata, clk_hw->enable_bit, 0);
> +}
> +
> +/*
> + * MCLK OUT
> + */
> +
> +/* The MCLK output can only provide the same rate as the input clock */
> +static unsigned long max9485_mclkout_recalc_rate(struct clk_hw *hw,
> + unsigned long parent_rate)
> +{
> + return MAX9485_INPUT_FREQ;
> +}
This clk_op can be dropped and just rely on parent frequency.
> +
> +/*
> + * CLKOUT - configurable clock output
> + */
> +static int max9485_clkout_set_rate(struct clk_hw *hw, unsigned long rate,
> + unsigned long parent_rate)
> +{
> + const struct max9485_rate *entry;
> + struct max9485_clk_hw *clk_hw =
> + container_of(hw, struct max9485_clk_hw, hw);
> +
> + for (entry = max9485_rates; entry->out != 0; entry++)
> + if (entry->out == rate)
> + break;
> +
> + if (entry->out == 0)
> + return -EINVAL;
> +
> + clk_hw->drvdata->clkout_rate = rate;
> +
> + return max9485_update_bits(clk_hw->drvdata,
> + MAX9485_FREQ_MASK,
> + entry->reg_value);
Need to unwind clkout_rate on failure? clkout_rate should go away
actually.
> +}
> +
> +static long max9485_clkout_round_rate(struct clk_hw *hw, unsigned long rate,
> + unsigned long *parent_rate)
> +{
> + const struct max9485_rate *curr, *prev = NULL;
> +
> + for (curr = max9485_rates; curr->out != 0; curr++) {
> + /* Exact matches */
> + if (curr->out == rate)
> + return rate;
> +
> + /*
> + * Find the first entry that has a frequency higher than the
> + * requested one.
> + */
> + if (curr->out > rate) {
> + unsigned int mid;
> +
> + /*
> + * If this is the first entry, clamp the value to the
> + * lowest possible frequency.
> + */
> + if (!prev)
> + return curr->out;
> +
> + /*
> + * Otherwise, determine whether the previous entry or
> + * current one is closer.
> + */
> + mid = prev->out + ((curr->out - prev->out) / 2);
> +
> + return (mid > rate) ? prev->out : curr->out;
> + }
> +
> + prev = curr;
> + }
> +
> + /* If the last entry was still too high, clamp the value */
> + return prev->out;
> +}
> +
> +static unsigned long max9485_clkout_recalc_rate(struct clk_hw *hw,
> + unsigned long parent_rate)
> +{
> + struct max9485_clk_hw *clk_hw =
> + container_of(hw, struct max9485_clk_hw, hw);
> +
> + return clk_hw->drvdata->clkout_rate;
This needs to return the rate of the clk that's determined by reading
the hardware. Caching the rate yourself is hard and error prone, so you
should only do it if you really have to.
> +}
> +
> +struct max9485_clk {
> + const char *name;
> + int parent_index;
> + const struct clk_ops ops;
> + u8 enable_bit;
> +};
> +
> +static const struct max9485_clk max9485_clks[MAX9485_NUM_CLKS] = {
> + [MAX9485_MCLKOUT] = {
> + .name = "mclkout",
> + .parent_index = -1,
> + .enable_bit = MAX9485_MCLK_ENABLE,
> + .ops = {
> + .prepare = max9485_clk_prepare,
> + .unprepare = max9485_clk_unprepare,
> + .recalc_rate = max9485_mclkout_recalc_rate,
> + },
> + },
> + [MAX9485_CLKOUT] = {
> + .name = "clkout",
> + .parent_index = -1,
> + .ops = {
> + .set_rate = max9485_clkout_set_rate,
> + .round_rate = max9485_clkout_round_rate,
> + .recalc_rate = max9485_clkout_recalc_rate,
> + },
> + },
> + [MAX9485_CLKOUT1] = {
> + .name = "clkout1",
> + .parent_index = MAX9485_CLKOUT,
> + .enable_bit = MAX9485_CLKOUT1_ENABLE,
> + .ops = {
> + .prepare = max9485_clk_prepare,
> + .unprepare = max9485_clk_unprepare,
> + .recalc_rate = max9485_clkout_recalc_rate,
> + },
> + },
> + [MAX9485_CLKOUT2] = {
> + .name = "clkout2",
> + .parent_index = MAX9485_CLKOUT,
> + .enable_bit = MAX9485_CLKOUT2_ENABLE,
> + .ops = {
> + .prepare = max9485_clk_prepare,
> + .unprepare = max9485_clk_unprepare,
> + .recalc_rate = max9485_clkout_recalc_rate,
> + },
> + },
> +};
> +
> +static int max9485_i2c_probe(struct i2c_client *client,
> + const struct i2c_device_id *id)
> +{
> + struct max9485_driver_data *drvdata;
> + struct device *dev = &client->dev;
> + unsigned long freq;
> + int i, ret;
> +
> + drvdata = devm_kzalloc(dev, sizeof(*drvdata), GFP_KERNEL);
> + if (drvdata == NULL)
More standard form is
if (!drvdata)
return -ENOMEM;
> + return -ENOMEM;
> +
> + drvdata->xclk = devm_clk_get(dev, "xclk");
> + if (IS_ERR(drvdata->xclk))
> + return PTR_ERR(drvdata->xclk);
> +
> + freq = clk_get_rate(drvdata->xclk);
> + if (freq != MAX9485_INPUT_FREQ) {
> + dev_err(dev, "Illegal xclk frequency of %ld\n", freq);
> + return -EINVAL;
> + }
Is this necessary? Seems pretty useless to do everywhere to make sure
that someone didn't design the hardware incorrectly. It would be better
to return the rate of the parent "xclk" by not having a recalc_rate hook
and relying on the parent's rate.
> +
> + drvdata->supply = devm_regulator_get(dev, "vdd");
> + if (IS_ERR(drvdata->supply))
> + return PTR_ERR(drvdata->supply);
> +
> + ret = regulator_enable(drvdata->supply);
> + if (ret < 0)
> + return ret;
> +
> + drvdata->reset_gpio =
> + devm_gpiod_get_optional(dev, "reset", GPIOD_OUT_HIGH);
> + if (IS_ERR(drvdata->reset_gpio))
> + return PTR_ERR(drvdata->reset_gpio);
> +
> + i2c_set_clientdata(client, drvdata);
> + drvdata->client = client;
> +
> + for (i = 0; i < MAX9485_NUM_CLKS; i++) {
> + int parent_index = max9485_clks[i].parent_index;
> + const char *name;
> +
> + if (of_property_read_string_index(dev->of_node,
> + "clock-output-names",
> + i, &name) == 0)
> + drvdata->hw[i].init.name = name;
> + else
> + drvdata->hw[i].init.name = max9485_clks[i].name;
Add braces on both arms please.
> +
> + drvdata->hw[i].init.ops = &max9485_clks[i].ops;
> + drvdata->hw[i].init.flags = CLK_IS_BASIC;
Don't use this flag unless you need it. Let me go add a comment to that
effect to the code right now.
> +
> + if (parent_index > 0) {
> + drvdata->hw[i].init.parent_names =
> + &drvdata->hw[parent_index].init.name;
> + drvdata->hw[i].init.num_parents = 1;
> + drvdata->hw[i].init.flags |= CLK_SET_RATE_PARENT;
> + }
> +
> + drvdata->hw[i].enable_bit = max9485_clks[i].enable_bit;
> + drvdata->hw[i].hw.init = &drvdata->hw[i].init;
> + drvdata->hw[i].drvdata = drvdata;
> +
> + ret = devm_clk_hw_register(dev, &drvdata->hw[i].hw);
> + if (ret < 0)
> + return ret;
> +
> + drvdata->onecell.hw[i] = &drvdata->hw[i].hw;
> + }
> +
> + drvdata->onecell.data.num = MAX9485_NUM_CLKS;
> +
> + return devm_of_clk_add_hw_provider(dev, of_clk_hw_onecell_get,
> + &drvdata->onecell.data);
> +}
> +
> +static int __maybe_unused max9485_suspend(struct device *dev)
> +{
> + struct i2c_client *client = to_i2c_client(dev);
> + struct max9485_driver_data *drvdata = i2c_get_clientdata(client);
> +
> + if (drvdata->reset_gpio)
> + gpiod_set_value_cansleep(drvdata->reset_gpio, 0);
Looks like you can call this unconditionally if the gpio is not there
because get_optional will return NULL and this function will bail out
early if so.
> +
> + return 0;
> +}
> +
> +static int __maybe_unused max9485_resume(struct device *dev)
> +{
> + struct i2c_client *client = to_i2c_client(dev);
> + struct max9485_driver_data *drvdata = i2c_get_clientdata(client);
> + int ret;
> +
> + if (drvdata->reset_gpio)
> + gpiod_set_value_cansleep(drvdata->reset_gpio, 0);
> +
Same.
> + ret = i2c_master_send(client, &drvdata->reg_value,
> + sizeof(drvdata->reg_value));
> +
> + return (ret < 0) ? ret : 0;
Drop the extra parenthesis please.
> +}
> +
^ permalink raw reply
* Re: [PATCH 1/2] clk: imx6ul: add GPIO clock gates
From: Stephen Boyd @ 2018-06-02 6:19 UTC (permalink / raw)
To: Anson Huang, Stefan Wahren, fabio.estevam, kernel, mark.rutland,
matteo.lisi, michael, mturquette, robh+dt, shawnguo
Cc: linux-clk, Linux-imx, devicetree, linux-kernel, linux-arm-kernel
In-Reply-To: <1439344955.9677.1526991935718@email.1und1.de>
Quoting Stefan Wahren (2018-05-22 05:25:35)
> > +++ b/include/dt-bindings/clock/imx6ul-clock.h
> > @@ -242,20 +242,25 @@
> > #define IMX6UL_CLK_CKO2_PODF 229
> > #define IMX6UL_CLK_CKO2 230
> > #define IMX6UL_CLK_CKO 231
> > +#define IMX6UL_CLK_GPIO1 232
> > +#define IMX6UL_CLK_GPIO2 233
> > +#define IMX6UL_CLK_GPIO3 234
> > +#define IMX6UL_CLK_GPIO4 235
> > +#define IMX6UL_CLK_GPIO5 236
>
> this change looks like a breakage of devicetree ABI. You are changing the mean of the existing clock IDs on i.MX6ULL, which probably regress the combination of older DTBs with newer kernel.
>
Agreed. Why can't we just tack on more numbers at the end?
> >
> > /* For i.MX6ULL */
> > -#define IMX6ULL_CLK_ESAI_PRED 232
^ permalink raw reply
* Re: [PATCH v3 1/3] dt-bindings: clk: Update Stingray binding doc
From: Stephen Boyd @ 2018-06-02 6:26 UTC (permalink / raw)
To: Mark Rutland, Michael Turquette, Rob Herring
Cc: devicetree, linux-kernel, Pramod Kumar, bcm-kernel-feedback-list,
Ray Jui, linux-clk, linux-arm-kernel
In-Reply-To: <1527900968-12017-2-git-send-email-ray.jui@broadcom.com>
Quoting Ray Jui (2018-06-01 17:56:06)
> From: Pramod Kumar <pramod.kumar@broadcom.com>
>
> Update Stingray clock binding document to add additional clock entries
> with names matching the latest ASIC datasheet. Also modify a few existing
> entries to make their naming more consistent with the rest of the entries
>
> Signed-off-by: Pramod Kumar <pramod.kumar@broadcom.com>
> Signed-off-by: Ray Jui <ray.jui@broadcom.com>
> ---
Applied to clk-next
^ permalink raw reply
* Re: [PATCH v3 2/3] clk: bcm: Update and add Stingray clock entries
From: Stephen Boyd @ 2018-06-02 6:26 UTC (permalink / raw)
To: Mark Rutland, Michael Turquette, Rob Herring
Cc: linux-clk, linux-kernel, bcm-kernel-feedback-list, devicetree,
linux-arm-kernel, Pramod Kumar, Ray Jui
In-Reply-To: <1527900968-12017-3-git-send-email-ray.jui@broadcom.com>
Quoting Ray Jui (2018-06-01 17:56:07)
> From: Pramod Kumar <pramod.kumar@broadcom.com>
>
> Update and add Stingray clock definitions and tables so they match the
> binding document and the latest ASIC datasheet
>
> Signed-off-by: Pramod Kumar <pramod.kumar@broadcom.com>
> Signed-off-by: Ray Jui <ray.jui@broadcom.com>
> ---
Applied to clk-next
^ permalink raw reply
* Re: [PATCH v4 2/6] mfd: bd71837: Devicetree bindings for ROHM BD71837 PMIC
From: Stephen Boyd @ 2018-06-02 6:30 UTC (permalink / raw)
Cc: Matti Vaittinen, Rob Herring, Matti Vaittinen, Michael Turquette,
Mark Rutland, Lee Jones, Liam Girdwood, Mark Brown, linux-clk,
devicetree, linux-kernel@vger.kernel.org, mikko.mutanen,
heikki.haikola
In-Reply-To: <20180601105105.GD5150@localhost.localdomain>
Quoting Matti Vaittinen (2018-06-01 03:51:05)
> On Thu, May 31, 2018 at 07:57:53AM -0700, Stephen Boyd wrote:
> > Quoting Rob Herring (2018-05-31 07:07:24)
> > >
> > > I don't think it should. The h/w either has an interrupt controller or
> > > it doesn't. My concern is you added it but nothing uses it which tells
> > > me your binding is incomplete. I'd rather see complete bindings even
> > > if you don't have drivers. For example, as-is, there's not really any
> > > need for the clocks child node. You can just make the parent a clock
> > > provider. But we need a complete picture of the h/w to make that
> > > determination.
> > >
> >
> > I don't see a reason to have the clk subnode either.
>
> After some pondering - do you mean I could:
> 1. remove clk binfing document and clk node.
> 2. add clock-output-names etc to pmic node (and describe them in pmic
> node binding document)
> 3. use parent DT node in clk driver and do something like:
> if (parent->of_node)
> ret = of_clk_add_hw_provider(parent->of_node, of_clk_hw_simple_get,
> hw);
> 4. remove the clkdev
>
This sounds ok to me. As Rob said, a more complete picture of the
hardware would make this easier.
^ permalink raw reply
* Re: [PATCH v2 5/6] ARM: dts: Add generic interconnect target module node for MCAN
From: Stephen Boyd @ 2018-06-02 6:32 UTC (permalink / raw)
To: devicetree, linux-arm-kernel, linux-clk, linux-kernel, linux-omap
Cc: robh+dt, bcousson, tony, paul, t-kristo, faiz_abbas
In-Reply-To: <20180530141133.3711-6-faiz_abbas@ti.com>
Quoting Faiz Abbas (2018-05-30 07:11:32)
> diff --git a/arch/arm/boot/dts/dra76x.dtsi b/arch/arm/boot/dts/dra76x.dtsi
> index bfc82636999c..57b8dc0fe719 100644
> --- a/arch/arm/boot/dts/dra76x.dtsi
> +++ b/arch/arm/boot/dts/dra76x.dtsi
> @@ -11,6 +11,25 @@
> / {
> compatible = "ti,dra762", "ti,dra7";
>
> + ocp {
> +
> + target-module@0x42c00000 {
Drop the 0x on unit address. Also, it should match the first register
property. And what is a "target-module"?
> + compatible = "ti,sysc-dra7-mcan";
> + ranges = <0x0 0x42c00000 0x2000>;
> + #address-cells = <1>;
> + #size-cells = <1>;
> + reg = <0x42c01900 0x4>,
> + <0x42c01904 0x4>,
>
^ permalink raw reply
* [PATCH 0/2] gpio: mediatek: driver for gpio chip in MT7621 SoC
From: Sergio Paracuellos @ 2018-06-02 7:30 UTC (permalink / raw)
To: linus.walleij
Cc: devicetree, gregkh, driverdev-devel, linux-gpio, robh+dt, neil
This patch series add support for gpio driver in mediatek MT7621
SoC. This driver has been in staging for a while and after some
cleanups cycles we consider to git it a try to get mainlined.
The functionality is presented as a single irq-chip but 3 separate
gpio-chips, as this seemed simplest. Is this acceptable, or does it
need to be changed? We'd like to have review comments and feedback
specially for this.
Hope this helps and thanks in advance.
Best regards,
Sergio Paracuellos
Sergio Paracuellos (2):
gpio: mediatek: add driver for MT7621
dt-bindings: document gpio-mt7621 bindings
.../bindings/gpio/mediatek,mt7621-gpio.txt | 68 ++++
drivers/gpio/Kconfig | 7 +
drivers/gpio/Makefile | 1 +
drivers/gpio/gpio-mt7621.c | 370 +++++++++++++++++++++
4 files changed, 446 insertions(+)
create mode 100644 Documentation/devicetree/bindings/gpio/mediatek,mt7621-gpio.txt
create mode 100644 drivers/gpio/gpio-mt7621.c
--
2.7.4
^ permalink raw reply
* [PATCH 1/2] gpio: mediatek: add driver for MT7621
From: Sergio Paracuellos @ 2018-06-02 7:30 UTC (permalink / raw)
To: linus.walleij
Cc: devicetree, gregkh, driverdev-devel, linux-gpio, robh+dt, neil
In-Reply-To: <1527924610-13135-1-git-send-email-sergio.paracuellos@gmail.com>
Add driver support for gpio of MT7621 SoC.
Signed-off-by: Sergio Paracuellos <sergio.paracuellos@gmail.com>
Reviewed-by: NeilBrown <neil@brown.name>
---
drivers/gpio/Kconfig | 7 +
drivers/gpio/Makefile | 1 +
drivers/gpio/gpio-mt7621.c | 370 +++++++++++++++++++++++++++++++++++++++++++++
3 files changed, 378 insertions(+)
create mode 100644 drivers/gpio/gpio-mt7621.c
diff --git a/drivers/gpio/Kconfig b/drivers/gpio/Kconfig
index 71c0ab4..2646949 100644
--- a/drivers/gpio/Kconfig
+++ b/drivers/gpio/Kconfig
@@ -359,6 +359,13 @@ config GPIO_MPC8XXX
Say Y here if you're going to use hardware that connects to the
MPC512x/831x/834x/837x/8572/8610/QorIQ GPIOs.
+config GPIO_MT7621
+ bool "Mediatek GPIO Support"
+ depends on SOC_MT7620 || SOC_MT7621
+ select GPIOLIB_IRQCHIP
+ help
+ Say yes here to support the Mediatek SoC GPIO device
+
config GPIO_MVEBU
def_bool y
depends on PLAT_ORION || ARCH_MVEBU
diff --git a/drivers/gpio/Makefile b/drivers/gpio/Makefile
index 1324c8f..03647ae 100644
--- a/drivers/gpio/Makefile
+++ b/drivers/gpio/Makefile
@@ -88,6 +88,7 @@ obj-$(CONFIG_GPIO_MOCKUP) += gpio-mockup.o
obj-$(CONFIG_GPIO_MPC5200) += gpio-mpc5200.o
obj-$(CONFIG_GPIO_MPC8XXX) += gpio-mpc8xxx.o
obj-$(CONFIG_GPIO_MSIC) += gpio-msic.o
+obj-$(CONFIG_GPIO_MT7621) += gpio-mt7621.o
obj-$(CONFIG_GPIO_MVEBU) += gpio-mvebu.o
obj-$(CONFIG_GPIO_MXC) += gpio-mxc.o
obj-$(CONFIG_GPIO_MXS) += gpio-mxs.o
diff --git a/drivers/gpio/gpio-mt7621.c b/drivers/gpio/gpio-mt7621.c
new file mode 100644
index 0000000..0c4fb4a
--- /dev/null
+++ b/drivers/gpio/gpio-mt7621.c
@@ -0,0 +1,370 @@
+// SPDX-License-Identifier: GPL-2.0
+/*
+ * Copyright (C) 2009-2011 Gabor Juhos <juhosg@openwrt.org>
+ * Copyright (C) 2013 John Crispin <blogic@openwrt.org>
+ */
+
+#include <linux/err.h>
+#include <linux/gpio.h>
+#include <linux/gpio/driver.h>
+#include <linux/interrupt.h>
+#include <linux/io.h>
+#include <linux/irqdomain.h>
+#include <linux/module.h>
+#include <linux/of_irq.h>
+#include <linux/platform_device.h>
+#include <linux/spinlock.h>
+
+#define MTK_BANK_CNT 3
+#define MTK_BANK_WIDTH 32
+#define PIN_MASK(nr) (1UL << ((nr % MTK_BANK_WIDTH)))
+
+enum mediatek_gpio_reg {
+ GPIO_REG_CTRL = 0,
+ GPIO_REG_POL,
+ GPIO_REG_DATA,
+ GPIO_REG_DSET,
+ GPIO_REG_DCLR,
+ GPIO_REG_REDGE,
+ GPIO_REG_FEDGE,
+ GPIO_REG_HLVL,
+ GPIO_REG_LLVL,
+ GPIO_REG_STAT,
+ GPIO_REG_EDGE,
+};
+
+struct mtk_gc {
+ struct gpio_chip chip;
+ spinlock_t lock;
+ int bank;
+ u32 rising;
+ u32 falling;
+};
+
+struct mtk_data {
+ void __iomem *gpio_membase;
+ int gpio_irq;
+ struct irq_domain *gpio_irq_domain;
+ struct mtk_gc gc_map[MTK_BANK_CNT];
+};
+
+static inline struct mtk_gc *
+to_mediatek_gpio(struct gpio_chip *chip)
+{
+ return container_of(chip, struct mtk_gc, chip);
+}
+
+static inline void
+mtk_gpio_w32(struct mtk_gc *rg, u8 reg, u32 val)
+{
+ struct mtk_data *gpio_data = gpiochip_get_data(&rg->chip);
+ u32 offset = (reg * 0x10) + (rg->bank * 0x4);
+
+ iowrite32(val, gpio_data->gpio_membase + offset);
+}
+
+static inline u32
+mtk_gpio_r32(struct mtk_gc *rg, u8 reg)
+{
+ struct mtk_data *gpio_data = gpiochip_get_data(&rg->chip);
+ u32 offset = (reg * 0x10) + (rg->bank * 0x4);
+
+ return ioread32(gpio_data->gpio_membase + offset);
+}
+
+static void
+mediatek_gpio_set(struct gpio_chip *chip, unsigned int offset, int value)
+{
+ struct mtk_gc *rg = to_mediatek_gpio(chip);
+
+ mtk_gpio_w32(rg, (value) ? GPIO_REG_DSET : GPIO_REG_DCLR, BIT(offset));
+}
+
+static int
+mediatek_gpio_get(struct gpio_chip *chip, unsigned int offset)
+{
+ struct mtk_gc *rg = to_mediatek_gpio(chip);
+
+ return !!(mtk_gpio_r32(rg, GPIO_REG_DATA) & BIT(offset));
+}
+
+static int
+mediatek_gpio_direction_input(struct gpio_chip *chip, unsigned int offset)
+{
+ struct mtk_gc *rg = to_mediatek_gpio(chip);
+ unsigned long flags;
+ u32 t;
+
+ spin_lock_irqsave(&rg->lock, flags);
+ t = mtk_gpio_r32(rg, GPIO_REG_CTRL);
+ t &= ~BIT(offset);
+ mtk_gpio_w32(rg, GPIO_REG_CTRL, t);
+ spin_unlock_irqrestore(&rg->lock, flags);
+
+ return 0;
+}
+
+static int
+mediatek_gpio_direction_output(struct gpio_chip *chip,
+ unsigned int offset, int value)
+{
+ struct mtk_gc *rg = to_mediatek_gpio(chip);
+ unsigned long flags;
+ u32 t;
+
+ spin_lock_irqsave(&rg->lock, flags);
+ t = mtk_gpio_r32(rg, GPIO_REG_CTRL);
+ t |= BIT(offset);
+ mtk_gpio_w32(rg, GPIO_REG_CTRL, t);
+ mediatek_gpio_set(chip, offset, value);
+ spin_unlock_irqrestore(&rg->lock, flags);
+
+ return 0;
+}
+
+static int
+mediatek_gpio_get_direction(struct gpio_chip *chip, unsigned int offset)
+{
+ struct mtk_gc *rg = to_mediatek_gpio(chip);
+ u32 t = mtk_gpio_r32(rg, GPIO_REG_CTRL);
+
+ return (t & BIT(offset)) ? GPIOF_DIR_OUT : GPIOF_DIR_IN;
+}
+
+static int
+mediatek_gpio_to_irq(struct gpio_chip *chip, unsigned int pin)
+{
+ struct mtk_data *gpio_data = gpiochip_get_data(chip);
+ struct mtk_gc *rg = to_mediatek_gpio(chip);
+
+ return irq_create_mapping(gpio_data->gpio_irq_domain,
+ pin + (rg->bank * MTK_BANK_WIDTH));
+}
+
+static int
+mediatek_gpio_bank_probe(struct platform_device *pdev, struct device_node *bank)
+{
+ struct mtk_data *gpio_data = dev_get_drvdata(&pdev->dev);
+ const __be32 *id = of_get_property(bank, "reg", NULL);
+ struct mtk_gc *rg;
+ int ret;
+
+ if (!id || be32_to_cpu(*id) >= MTK_BANK_CNT)
+ return -EINVAL;
+
+ rg = &gpio_data->gc_map[be32_to_cpu(*id)];
+ memset(rg, 0, sizeof(*rg));
+
+ spin_lock_init(&rg->lock);
+
+ rg->chip.parent = &pdev->dev;
+ rg->chip.label = dev_name(&pdev->dev);
+ rg->chip.of_node = bank;
+ rg->chip.base = MTK_BANK_WIDTH * be32_to_cpu(*id);
+ rg->chip.ngpio = MTK_BANK_WIDTH;
+ rg->chip.direction_input = mediatek_gpio_direction_input;
+ rg->chip.direction_output = mediatek_gpio_direction_output;
+ rg->chip.get_direction = mediatek_gpio_get_direction;
+ rg->chip.get = mediatek_gpio_get;
+ rg->chip.set = mediatek_gpio_set;
+ if (gpio_data->gpio_irq_domain)
+ rg->chip.to_irq = mediatek_gpio_to_irq;
+ rg->bank = be32_to_cpu(*id);
+
+ ret = devm_gpiochip_add_data(&pdev->dev, &rg->chip, gpio_data);
+ if (ret < 0) {
+ dev_err(&pdev->dev, "Could not register gpio %d, ret=%d\n",
+ rg->chip.ngpio, ret);
+ return ret;
+ }
+
+ /* set polarity to low for all gpios */
+ mtk_gpio_w32(rg, GPIO_REG_POL, 0);
+
+ dev_info(&pdev->dev, "registering %d gpios\n", rg->chip.ngpio);
+
+ return 0;
+}
+
+static void
+mediatek_gpio_irq_handler(struct irq_desc *desc)
+{
+ struct mtk_data *gpio_data = irq_desc_get_handler_data(desc);
+ int i;
+
+ for (i = 0; i < MTK_BANK_CNT; i++) {
+ struct mtk_gc *rg = &gpio_data->gc_map[i];
+ unsigned long pending;
+ int bit;
+
+ if (!rg)
+ continue;
+
+ pending = mtk_gpio_r32(rg, GPIO_REG_STAT);
+
+ for_each_set_bit(bit, &pending, MTK_BANK_WIDTH) {
+ u32 map = irq_find_mapping(gpio_data->gpio_irq_domain,
+ (MTK_BANK_WIDTH * i) + bit);
+
+ generic_handle_irq(map);
+ mtk_gpio_w32(rg, GPIO_REG_STAT, BIT(bit));
+ }
+ }
+}
+
+static void
+mediatek_gpio_irq_unmask(struct irq_data *d)
+{
+ struct mtk_data *gpio_data = irq_data_get_irq_chip_data(d);
+ int pin = d->hwirq;
+ int bank = pin / MTK_BANK_WIDTH;
+ struct mtk_gc *rg = &gpio_data->gc_map[bank];
+ unsigned long flags;
+ u32 rise, fall;
+
+ if (!rg)
+ return;
+
+ spin_lock_irqsave(&rg->lock, flags);
+ rise = mtk_gpio_r32(rg, GPIO_REG_REDGE);
+ fall = mtk_gpio_r32(rg, GPIO_REG_FEDGE);
+ mtk_gpio_w32(rg, GPIO_REG_REDGE, rise | (PIN_MASK(pin) & rg->rising));
+ mtk_gpio_w32(rg, GPIO_REG_FEDGE, fall | (PIN_MASK(pin) & rg->falling));
+ spin_unlock_irqrestore(&rg->lock, flags);
+}
+
+static void
+mediatek_gpio_irq_mask(struct irq_data *d)
+{
+ struct mtk_data *gpio_data = irq_data_get_irq_chip_data(d);
+ int pin = d->hwirq;
+ int bank = pin / MTK_BANK_WIDTH;
+ struct mtk_gc *rg = &gpio_data->gc_map[bank];
+ unsigned long flags;
+ u32 rise, fall;
+
+ if (!rg)
+ return;
+
+ spin_lock_irqsave(&rg->lock, flags);
+ rise = mtk_gpio_r32(rg, GPIO_REG_REDGE);
+ fall = mtk_gpio_r32(rg, GPIO_REG_FEDGE);
+ mtk_gpio_w32(rg, GPIO_REG_FEDGE, fall & ~PIN_MASK(pin));
+ mtk_gpio_w32(rg, GPIO_REG_REDGE, rise & ~PIN_MASK(pin));
+ spin_unlock_irqrestore(&rg->lock, flags);
+}
+
+static int
+mediatek_gpio_irq_type(struct irq_data *d, unsigned int type)
+{
+ struct mtk_data *gpio_data = irq_data_get_irq_chip_data(d);
+ int pin = d->hwirq;
+ int bank = pin / MTK_BANK_WIDTH;
+ struct mtk_gc *rg = &gpio_data->gc_map[bank];
+ u32 mask = PIN_MASK(pin);
+
+ if (!rg)
+ return -1;
+
+ if (type == IRQ_TYPE_PROBE) {
+ if ((rg->rising | rg->falling) & mask)
+ return 0;
+
+ type = IRQ_TYPE_EDGE_RISING | IRQ_TYPE_EDGE_FALLING;
+ }
+
+ if (type & IRQ_TYPE_EDGE_RISING)
+ rg->rising |= mask;
+ else
+ rg->rising &= ~mask;
+
+ if (type & IRQ_TYPE_EDGE_FALLING)
+ rg->falling |= mask;
+ else
+ rg->falling &= ~mask;
+
+ return 0;
+}
+
+static struct irq_chip mediatek_gpio_irq_chip = {
+ .name = "GPIO",
+ .irq_unmask = mediatek_gpio_irq_unmask,
+ .irq_mask = mediatek_gpio_irq_mask,
+ .irq_mask_ack = mediatek_gpio_irq_mask,
+ .irq_set_type = mediatek_gpio_irq_type,
+};
+
+static int
+mediatek_gpio_gpio_map(struct irq_domain *d, unsigned int irq,
+ irq_hw_number_t hw)
+{
+ int ret;
+
+ ret = irq_set_chip_data(irq, d->host_data);
+ if (ret < 0)
+ return ret;
+ irq_set_chip_and_handler(irq, &mediatek_gpio_irq_chip,
+ handle_level_irq);
+ irq_set_handler_data(irq, d);
+
+ return 0;
+}
+
+static const struct irq_domain_ops irq_domain_ops = {
+ .xlate = irq_domain_xlate_twocell,
+ .map = mediatek_gpio_gpio_map,
+};
+
+static int
+mediatek_gpio_probe(struct platform_device *pdev)
+{
+ struct device_node *bank, *np = pdev->dev.of_node;
+ struct resource *res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
+ struct mtk_data *gpio_data;
+
+ gpio_data = devm_kzalloc(&pdev->dev, sizeof(*gpio_data), GFP_KERNEL);
+ if (!gpio_data)
+ return -ENOMEM;
+
+ gpio_data->gpio_membase = devm_ioremap_resource(&pdev->dev, res);
+ if (IS_ERR(gpio_data->gpio_membase))
+ return PTR_ERR(gpio_data->gpio_membase);
+
+ gpio_data->gpio_irq = irq_of_parse_and_map(np, 0);
+ if (gpio_data->gpio_irq) {
+ gpio_data->gpio_irq_domain = irq_domain_add_linear(np,
+ MTK_BANK_CNT * MTK_BANK_WIDTH,
+ &irq_domain_ops, gpio_data);
+ if (!gpio_data->gpio_irq_domain)
+ dev_err(&pdev->dev, "irq_domain_add_linear failed\n");
+ }
+
+ platform_set_drvdata(pdev, gpio_data);
+
+ for_each_child_of_node(np, bank)
+ if (of_device_is_compatible(bank, "mediatek,mt7621-gpio-bank"))
+ mediatek_gpio_bank_probe(pdev, bank);
+
+ if (gpio_data->gpio_irq_domain)
+ irq_set_chained_handler_and_data(gpio_data->gpio_irq,
+ mediatek_gpio_irq_handler,
+ gpio_data);
+
+ return 0;
+}
+
+static const struct of_device_id mediatek_gpio_match[] = {
+ { .compatible = "mediatek,mt7621-gpio" },
+ {},
+};
+MODULE_DEVICE_TABLE(of, mediatek_gpio_match);
+
+static struct platform_driver mediatek_gpio_driver = {
+ .probe = mediatek_gpio_probe,
+ .driver = {
+ .name = "mt7621_gpio",
+ .of_match_table = mediatek_gpio_match,
+ },
+};
+
+module_platform_driver(mediatek_gpio_driver);
--
2.7.4
^ permalink raw reply related
* [PATCH 2/2] dt-bindings: document gpio-mt7621 bindings
From: Sergio Paracuellos @ 2018-06-02 7:30 UTC (permalink / raw)
To: linus.walleij
Cc: devicetree, gregkh, driverdev-devel, linux-gpio, robh+dt, neil
In-Reply-To: <1527924610-13135-1-git-send-email-sergio.paracuellos@gmail.com>
Add a devicetree binding documentation for the mt7621 driver.
Signed-off-by: Sergio Paracuellos <sergio.paracuellos@gmail.com>
Reviewed-by: NeilBrown <neil@brown.name>
---
.../bindings/gpio/mediatek,mt7621-gpio.txt | 68 ++++++++++++++++++++++
1 file changed, 68 insertions(+)
create mode 100644 Documentation/devicetree/bindings/gpio/mediatek,mt7621-gpio.txt
diff --git a/Documentation/devicetree/bindings/gpio/mediatek,mt7621-gpio.txt b/Documentation/devicetree/bindings/gpio/mediatek,mt7621-gpio.txt
new file mode 100644
index 0000000..30d8a02
--- /dev/null
+++ b/Documentation/devicetree/bindings/gpio/mediatek,mt7621-gpio.txt
@@ -0,0 +1,68 @@
+Mediatek SoC GPIO controller bindings
+
+The IP core used inside these SoCs has 3 banks of 32 GPIOs each.
+The registers of all the banks are interwoven inside one single IO range.
+We load one GPIO controller instance per bank. To make this possible
+we support 2 types of nodes. The parent node defines the memory I/O range and
+has 3 children each describing a single bank. Also the GPIO controller can receive
+interrupts on any of the GPIOs, either edge or level. It then interrupts the CPU
+using GIC INT12.
+
+Required properties for the top level node:
+- compatible:
+ - "mediatek,mt7621-gpio" for Mediatek controllers
+- reg : Physical base address and length of the controller's registers
+- interrupt-parent : phandle of the parent interrupt controller.
+- interrupts : Interrupt specifier for the controllers interrupt.
+- interrupt-controller : Mark the device node as an interrupt controller.
+- #interrupt-cells : Should be 2. The first cell defines the interrupt number.
+ The second cell bits[3:0] is used to specify trigger type as follows:
+ - 1 = low-to-high edge triggered.
+ - 2 = high-to-low edge triggered.
+ - 4 = active high level-sensitive.
+ - 8 = active low level-sensitive.
+
+
+Required properties for the GPIO bank node:
+- compatible:
+ - "mediatek,mt7621-gpio-bank" for Mediatek banks
+- #gpio-cells : Should be two. The first cell is the GPIO pin number and the
+ second cell specifies GPIO flags, as defined in <dt-bindings/gpio/gpio.h>.
+ Only the GPIO_ACTIVE_HIGH and GPIO_ACTIVE_LOW flags are supported.
+- gpio-controller : Marks the device node as a GPIO controller.
+- reg : The id of the bank that the node describes.
+
+Example:
+ gpio@600 {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ compatible = "mediatek,mt7621-gpio";
+ reg = <0x600 0x100>;
+
+ interrupt-parent = <&gic>;
+ interrupts = <GIC_SHARED 12 IRQ_TYPE_LEVEL_HIGH>;
+ interrupt-controller;
+ #interrupt-cells = <2>;
+
+ gpio0: bank@0 {
+ reg = <0>;
+ compatible = "mediatek,mt7621-gpio-bank";
+ gpio-controller;
+ #gpio-cells = <2>;
+ };
+
+ gpio1: bank@1 {
+ reg = <1>;
+ compatible = "mediatek,mt7621-gpio-bank";
+ gpio-controller;
+ #gpio-cells = <2>;
+ };
+
+ gpio2: bank@2 {
+ reg = <2>;
+ compatible = "mediatek,mt7621-gpio-bank";
+ gpio-controller;
+ #gpio-cells = <2>;
+ };
+ };
--
2.7.4
^ permalink raw reply related
* Re: [PATCH 1/6] arm64: dts: amlogic: Add missing cooling device properties for CPUs
From: Olof Johansson @ 2018-06-02 8:14 UTC (permalink / raw)
To: Viresh Kumar
Cc: arm, Rob Herring, Mark Rutland, Catalin Marinas, Will Deacon,
Carlo Caione, Kevin Hilman, Vincent Guittot, ionela.voinescu,
Daniel Lezcano, chris.redpath, devicetree, linux-arm-kernel,
linux-amlogic, linux-kernel
In-Reply-To: <20180528111358.meyle364fy6wuruf@vireshk-i7>
On Mon, May 28, 2018 at 04:43:58PM +0530, Viresh Kumar wrote:
> On 25-05-18, 14:10, Olof Johansson wrote:
> > On Fri, May 25, 2018 at 11:10:01AM +0530, Viresh Kumar wrote:
> > > The cooling device properties, like "#cooling-cells" and
> > > "dynamic-power-coefficient", should either be present for all the CPUs
> > > of a cluster or none. If these are present only for a subset of CPUs of
> > > a cluster then things will start falling apart as soon as the CPUs are
> > > brought online in a different order. For example, this will happen
> > > because the operating system looks for such properties in the CPU node
> > > it is trying to bring up, so that it can register a cooling device.
> > >
> > > Add such missing properties.
> >
> > This seems awkward compared to just having one cooling-cells in the /cpus node
> > instead.
>
> Well, we don't allow that property to be present in /cpus node right
> now and it is per device. And then we may not want all the CPUs to be
> cooling devices really.
And what I am saying is that it sounds like a broken binding if you don't allow
that, especially since it'll be a super common case that all CPUs will specify
the same cooling-device specifier.
> > What's it used for? I don't see any properties in the device nodes on meson-gxm
> > that have any cooling-foo cells in them? So why should #cooling-cells be
> > needed?
>
> This property is required to declare a device as a cooling-device and
> the device here is CPU. We use it as a cooling device by limiting its
> higher range of frequencies, so that it doesn't generate too much
> heat.
>
> It is already there for CPU0 and CPU4, but it should really be there
> for all the CPUs, like we have clock, supply, caches, etc.
You have #cooling-cells in the cpu node, but the actual data is in the
thermal-zones nodes. Why isn't #cooling-cells under thermal-zones, next to
cooling-maps?
-Olof
^ permalink raw reply
* Re: [PATCH v3 2/5] gpio: syscon: rockchip: add GPIO_MUTE support for rk3328
From: Levin Du @ 2018-06-02 8:40 UTC (permalink / raw)
To: Rob Herring
Cc: Mark Rutland, devicetree, Wayne Chou, Heiko Stuebner,
open list:GPIO SUBSYSTEM, Linus Walleij,
linux-kernel@vger.kernel.org, open list:ARM/Rockchip SoC...,
moderated list:ARM/FREESCALE IMX / MXC ARM ARCHITECTURE
In-Reply-To: <CAL_JsqKSy4q5dfVfXbRMLa7koTWufpAt3yNdE-9mwyJ-VzVQRQ@mail.gmail.com>
Rob Herring <robh+dt@kernel.org> writes:
> On Thu, May 31, 2018 at 9:05 PM, Levin <djw@t-chip.com.cn>
> wrote:
>> Hi Rob,
>>
>>
>> On 2018-05-31 10:45 PM, Rob Herring wrote:
>>>
>>> On Wed, May 30, 2018 at 10:27 PM, <djw@t-chip.com.cn> wrote:
>>>>
>>>> From: Levin Du <djw@t-chip.com.cn>
>>>>
>>>> In Rockchip RK3328, the output only GPIO_MUTE pin, originally
>>>> for codec
>>>> mute control, can also be used for general purpose. It is
>>>> manipulated by
>>>> the GRF_SOC_CON10 register.
>>>>
>>>> Signed-off-by: Levin Du <djw@t-chip.com.cn>
>>>>
>>>> ---
>>>>
>>>> Changes in v3:
>>>> - Change from general gpio-syscon to specific
>>>> rk3328-gpio-mute
>>>>
>>>> Changes in v2:
>>>> - Rename gpio_syscon10 to gpio_mute in doc
>>>>
>>>> Changes in v1:
>>>> - Refactured for general gpio-syscon usage for Rockchip SoCs.
>>>> - Add doc rockchip,gpio-syscon.txt
>>>>
>>>> .../bindings/gpio/rockchip,rk3328-gpio-mute.txt | 28
>>>> +++++++++++++++++++
>>>> drivers/gpio/gpio-syscon.c | 31
>>>> ++++++++++++++++++++++
>>>> 2 files changed, 59 insertions(+)
>>>> create mode 100644
>>>> Documentation/devicetree/bindings/gpio/rockchip,rk3328-gpio-mute.txt
>>>>
>>>> diff --git
>>>> a/Documentation/devicetree/bindings/gpio/rockchip,rk3328-gpio-mute.txt
>>>> b/Documentation/devicetree/bindings/gpio/rockchip,rk3328-gpio-mute.txt
>>>> new file mode 100644
>>>> index 0000000..10bc632
>>>> --- /dev/null
>>>> +++
>>>> b/Documentation/devicetree/bindings/gpio/rockchip,rk3328-gpio-mute.txt
>>>> @@ -0,0 +1,28 @@
>>>> +Rockchip RK3328 GPIO controller dedicated for the GPIO_MUTE
>>>> pin.
>>>> +
>>>> +In Rockchip RK3328, the output only GPIO_MUTE pin,
>>>> originally for codec
>>>> mute
>>>> +control, can also be used for general purpose. It is
>>>> manipulated by the
>>>> +GRF_SOC_CON10 register.
>>>> +
>>>> +Required properties:
>>>> +- compatible: Should contain "rockchip,rk3328-gpio-mute".
>>>> +- gpio-controller: Marks the device node as a gpio
>>>> controller.
>>>> +- #gpio-cells: Should be 2. The first cell is the pin number
>>>> and
>>>> + the second cell is used to specify the gpio polarity:
>>>> + 0 = Active high,
>>>> + 1 = Active low.
>>>> +
>>>> +Example:
>>>> +
>>>> + grf: syscon@ff100000 {
>>>> + compatible = "rockchip,rk3328-grf", "syscon",
>>>> "simple-mfd";
>>>> +
>>>> + gpio_mute: gpio-mute {
>>>
>>> Node names should be generic:
>>>
>>> gpio {
>>>
>>> This also means you can't add another GPIO node in the future
>>> and
>>> you'll have to live with "rockchip,rk3328-gpio-mute" covering
>>> more
>>> than 1 GPIO if you do need to add more GPIOs.
>>
>>
>> As the first line describes, this GPIO controller is dedicated
>> for the
>> GPIO_MUTE pin.
>> There's only one GPIO pin in the GRF_SOC_CON10 register.
>> Therefore the
>> gpio_mute
>> name is proper IMHO.
>
> It's how many GPIOs in the GRF, not this register. What I'm
> saying is
> when you come along later to add another GPIO in the GRF, you
> had
> better just add it to this same node. I'm not going to accept
> another
> GPIO controller node within the GRF. You have the cells to
> support
> more than 1, so it would only be a driver change. The compatible
> string would then not be ideally named at that point. But
> compatible
> strings are just unique identifiers, so it doesn't really matter
> what
> the string is.
>
I'll try my best to introduce the situation here. The GRF,
GPIO0~GPIO3
are register blocks in the RK3328 Soc. The GPIO0~GPIO3 contain
registers
for GPIO operations like reading/writing data, setting direction,
interruption etc, which corresponds to the GPIO banks
(gpio0~gpio3)
defined in rk3328.dtsi:
pinctrl: pinctrl {
compatible = "rockchip,rk3328-pinctrl";
rockchip,grf = <&grf>;
#address-cells = <2>;
#size-cells = <2>;
ranges;
gpio0: gpio0@ff210000 {
compatible = "rockchip,gpio-bank";
reg = <0x0 0xff210000 0x0 0x100>;
interrupts = <GIC_SPI 51
IRQ_TYPE_LEVEL_HIGH>;
clocks = <&cru PCLK_GPIO0>;
gpio-controller;
#gpio-cells = <2>;
interrupt-controller;
#interrupt-cells = <2>;
};
gpio1: gpio1@ff220000 {
//...
};
gpio2: gpio2@ff230000 {
//...
};
gpio3: gpio3@ff240000 {
//...
};
}
However, these general GPIO pins has multiplexed functions and
their
pull up/down and driving strength can also be configured. These
settings
are manipulated by the GRF registers in pinctrl driver. Quoted
from the
TRM, the GRF has the following function:
- IOMUX control
- Control the state of GPIO in power-down mode
- GPIO PAD pull down and pull up control
- Used for common system control
- Used to record the system state
Therefore the functions of the GRF are messy and scattered in
different
nodes. The so-called GPIO_MUTE does not belong to GPIO0~GPIO3. It
is
manipulated by the GRF_SOC_CON10 register in the GRF block.
> I'm being told both "this is the only GPIO" and "the GRF has too
> many
> different functions for us to tell you what they all are". So
> which is
> it?
>
> Rob
They are both true, but lack of context. See the above
description.
Thanks,
Levin
^ permalink raw reply
* [PATCH] arm64: tegra: Remove unused interrupt properties
From: Bhadram Varka @ 2018-06-02 9:11 UTC (permalink / raw)
To: robh+dt, mark.rutland, catalin.marinas, will.deacon, treding,
mperttunen
Cc: linux-tegra, devicetree, linux-arm-kernel
DWC EQOS on Tegra handles all interrupts through
common interrupt line. So lets remove unused power
and per-channel interrupt properties.
Signed-off-by: Bhadram Varka <vbhadram@nvidia.com>
---
arch/arm64/boot/dts/nvidia/tegra186.dtsi | 11 +----------
1 file changed, 1 insertion(+), 10 deletions(-)
diff --git a/arch/arm64/boot/dts/nvidia/tegra186.dtsi b/arch/arm64/boot/dts/nvidia/tegra186.dtsi
index b762227..252133b 100644
--- a/arch/arm64/boot/dts/nvidia/tegra186.dtsi
+++ b/arch/arm64/boot/dts/nvidia/tegra186.dtsi
@@ -41,16 +41,7 @@
compatible = "nvidia,tegra186-eqos",
"snps,dwc-qos-ethernet-4.10";
reg = <0x0 0x02490000 0x0 0x10000>;
- interrupts = <GIC_SPI 194 IRQ_TYPE_LEVEL_HIGH>, /* common */
- <GIC_SPI 195 IRQ_TYPE_LEVEL_HIGH>, /* power */
- <GIC_SPI 190 IRQ_TYPE_LEVEL_HIGH>, /* rx0 */
- <GIC_SPI 186 IRQ_TYPE_LEVEL_HIGH>, /* tx0 */
- <GIC_SPI 191 IRQ_TYPE_LEVEL_HIGH>, /* rx1 */
- <GIC_SPI 187 IRQ_TYPE_LEVEL_HIGH>, /* tx1 */
- <GIC_SPI 192 IRQ_TYPE_LEVEL_HIGH>, /* rx2 */
- <GIC_SPI 188 IRQ_TYPE_LEVEL_HIGH>, /* tx2 */
- <GIC_SPI 193 IRQ_TYPE_LEVEL_HIGH>, /* rx3 */
- <GIC_SPI 189 IRQ_TYPE_LEVEL_HIGH>; /* tx3 */
+ interrupts = <GIC_SPI 194 IRQ_TYPE_LEVEL_HIGH>; /* common */
clocks = <&bpmp TEGRA186_CLK_AXI_CBB>,
<&bpmp TEGRA186_CLK_EQOS_AXI>,
<&bpmp TEGRA186_CLK_EQOS_RX>,
--
2.7.4
^ permalink raw reply related
* [PATCH 2/3] arm64: tegra: Enable multi-queue for DWC EQOS
From: Bhadram Varka @ 2018-06-02 9:11 UTC (permalink / raw)
To: robh+dt, mark.rutland, catalin.marinas, will.deacon, treding,
mperttunen
Cc: linux-tegra, devicetree, linux-arm-kernel
In-Reply-To: <1527930713-4479-1-git-send-email-vbhadram@nvidia.com>
DWC EQOS supports four MTL queues for Tx and Rx
separately.
Signed-off-by: Bhadram Varka <vbhadram@nvidia.com>
---
arch/arm64/boot/dts/nvidia/tegra186.dtsi | 48 ++++++++++++++++++++++++++++++++
1 file changed, 48 insertions(+)
diff --git a/arch/arm64/boot/dts/nvidia/tegra186.dtsi b/arch/arm64/boot/dts/nvidia/tegra186.dtsi
index 0f4bed8..f27730d 100644
--- a/arch/arm64/boot/dts/nvidia/tegra186.dtsi
+++ b/arch/arm64/boot/dts/nvidia/tegra186.dtsi
@@ -37,6 +37,52 @@
gpio-controller;
};
+ mtl_rx_setup: rx-queues-config {
+ snps,rx-queues-to-use = <4>;
+ snps,rx-sched-sp;
+ queue0 {
+ snps,dcb-algorithm;
+ snps,map-to-dma-channel = <0x0>;
+ snps,priority = <0x0>;
+ };
+ queue1 {
+ snps,dcb-algorithm;
+ snps,map-to-dma-channel = <0x1>;
+ snps,priority = <0x1>;
+ };
+ queue2 {
+ snps,dcb-algorithm;
+ snps,map-to-dma-channel = <0x2>;
+ snps,priority = <0x2>;
+ };
+ queue3 {
+ snps,dcb-algorithm;
+ snps,map-to-dma-channel = <0x2>;
+ snps,priority = <0x3>;
+ };
+ };
+
+ mtl_tx_setup: tx-queues-config {
+ snps,tx-queues-to-use = <4>;
+ snps,tx-sched-sp;
+ queue0 {
+ snps,dcb-algorithm;
+ snps,priority = <0x0>;
+ };
+ queue1 {
+ snps,dcb-algorithm;
+ snps,priority = <0x1>;
+ };
+ queue2 {
+ snps,dcb-algorithm;
+ snps,priority = <0x2>;
+ };
+ queue3 {
+ snps,dcb-algorithm;
+ snps,priority = <0x3>;
+ };
+ };
+
ethernet@2490000 {
compatible = "nvidia,tegra186-eqos",
"snps,dwc-qos-ethernet-4.10";
@@ -57,6 +103,8 @@
snps,burst-map = <0x7>;
snps,txpbl = <32>;
snps,rxpbl = <8>;
+ snps,mtl-rx-config = <&mtl_rx_setup>;
+ snps,mtl-tx-config = <&mtl_tx_setup>;
};
memory-controller@2c00000 {
--
2.7.4
^ permalink raw reply related
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox