* [PATCH v15 04/11] soc: mediatek: Remove infracfg misc driver support
From: Weiyi Lu @ 2020-05-21 9:06 UTC (permalink / raw)
To: Enric Balletbo Serra, Matthias Brugger, Nicolas Boichat,
Rob Herring, Sascha Hauer
Cc: James Liao, Weiyi Lu, srv_heupstream, devicetree, linux-kernel,
Fan Chen, linux-mediatek, linux-arm-kernel
In-Reply-To: <1590051985-29149-1-git-send-email-weiyi.lu@mediatek.com>
The functions provided by infracfg misc driver have no other user except
the scpsys driver so move those into scpsys driver directly.
And then, remove infracfg misc driver which is no longer being used.
BTW, in next patch, we're going to extend the bus protection functions
with more customized arguments.
Signed-off-by: Weiyi Lu <weiyi.lu@mediatek.com>
Reviewed-by: Enric Balletbo i Serra <enric.balletbo@collabora.com>
---
drivers/soc/mediatek/Kconfig | 10 -----
drivers/soc/mediatek/Makefile | 1 -
drivers/soc/mediatek/mtk-infracfg.c | 79 -----------------------------------
drivers/soc/mediatek/mtk-scpsys.c | 66 +++++++++++++++++++++++++----
include/linux/soc/mediatek/infracfg.h | 39 -----------------
5 files changed, 57 insertions(+), 138 deletions(-)
delete mode 100644 drivers/soc/mediatek/mtk-infracfg.c
delete mode 100644 include/linux/soc/mediatek/infracfg.h
diff --git a/drivers/soc/mediatek/Kconfig b/drivers/soc/mediatek/Kconfig
index 2114b56..f837b3c 100644
--- a/drivers/soc/mediatek/Kconfig
+++ b/drivers/soc/mediatek/Kconfig
@@ -10,21 +10,12 @@ config MTK_CMDQ
depends on ARCH_MEDIATEK || COMPILE_TEST
select MAILBOX
select MTK_CMDQ_MBOX
- select MTK_INFRACFG
help
Say yes here to add support for the MediaTek Command Queue (CMDQ)
driver. The CMDQ is used to help read/write registers with critical
time limitation, such as updating display configuration during the
vblank.
-config MTK_INFRACFG
- bool "MediaTek INFRACFG Support"
- select REGMAP
- help
- Say yes here to add support for the MediaTek INFRACFG controller. The
- INFRACFG controller contains various infrastructure registers not
- directly associated to any device.
-
config MTK_PMIC_WRAP
tristate "MediaTek PMIC Wrapper Support"
depends on RESET_CONTROLLER
@@ -38,7 +29,6 @@ config MTK_SCPSYS
bool "MediaTek SCPSYS Support"
default ARCH_MEDIATEK
select REGMAP
- select MTK_INFRACFG
select PM_GENERIC_DOMAINS if PM
help
Say yes here to add support for the MediaTek SCPSYS power domain
diff --git a/drivers/soc/mediatek/Makefile b/drivers/soc/mediatek/Makefile
index b017330..2b2c2537 100644
--- a/drivers/soc/mediatek/Makefile
+++ b/drivers/soc/mediatek/Makefile
@@ -1,5 +1,4 @@
# SPDX-License-Identifier: GPL-2.0-only
obj-$(CONFIG_MTK_CMDQ) += mtk-cmdq-helper.o
-obj-$(CONFIG_MTK_INFRACFG) += mtk-infracfg.o
obj-$(CONFIG_MTK_PMIC_WRAP) += mtk-pmic-wrap.o
obj-$(CONFIG_MTK_SCPSYS) += mtk-scpsys.o
diff --git a/drivers/soc/mediatek/mtk-infracfg.c b/drivers/soc/mediatek/mtk-infracfg.c
deleted file mode 100644
index 341c7ac..0000000
--- a/drivers/soc/mediatek/mtk-infracfg.c
+++ /dev/null
@@ -1,79 +0,0 @@
-// SPDX-License-Identifier: GPL-2.0-only
-/*
- * Copyright (c) 2015 Pengutronix, Sascha Hauer <kernel@pengutronix.de>
- */
-
-#include <linux/export.h>
-#include <linux/jiffies.h>
-#include <linux/regmap.h>
-#include <linux/soc/mediatek/infracfg.h>
-#include <asm/processor.h>
-
-#define MTK_POLL_DELAY_US 10
-#define MTK_POLL_TIMEOUT (jiffies_to_usecs(HZ))
-
-#define INFRA_TOPAXI_PROTECTEN 0x0220
-#define INFRA_TOPAXI_PROTECTSTA1 0x0228
-#define INFRA_TOPAXI_PROTECTEN_SET 0x0260
-#define INFRA_TOPAXI_PROTECTEN_CLR 0x0264
-
-/**
- * mtk_infracfg_set_bus_protection - enable bus protection
- * @regmap: The infracfg regmap
- * @mask: The mask containing the protection bits to be enabled.
- * @reg_update: The boolean flag determines to set the protection bits
- * by regmap_update_bits with enable register(PROTECTEN) or
- * by regmap_write with set register(PROTECTEN_SET).
- *
- * This function enables the bus protection bits for disabled power
- * domains so that the system does not hang when some unit accesses the
- * bus while in power down.
- */
-int mtk_infracfg_set_bus_protection(struct regmap *infracfg, u32 mask,
- bool reg_update)
-{
- u32 val;
- int ret;
-
- if (reg_update)
- regmap_update_bits(infracfg, INFRA_TOPAXI_PROTECTEN, mask,
- mask);
- else
- regmap_write(infracfg, INFRA_TOPAXI_PROTECTEN_SET, mask);
-
- ret = regmap_read_poll_timeout(infracfg, INFRA_TOPAXI_PROTECTSTA1,
- val, (val & mask) == mask,
- MTK_POLL_DELAY_US, MTK_POLL_TIMEOUT);
-
- return ret;
-}
-
-/**
- * mtk_infracfg_clear_bus_protection - disable bus protection
- * @regmap: The infracfg regmap
- * @mask: The mask containing the protection bits to be disabled.
- * @reg_update: The boolean flag determines to clear the protection bits
- * by regmap_update_bits with enable register(PROTECTEN) or
- * by regmap_write with clear register(PROTECTEN_CLR).
- *
- * This function disables the bus protection bits previously enabled with
- * mtk_infracfg_set_bus_protection.
- */
-
-int mtk_infracfg_clear_bus_protection(struct regmap *infracfg, u32 mask,
- bool reg_update)
-{
- int ret;
- u32 val;
-
- if (reg_update)
- regmap_update_bits(infracfg, INFRA_TOPAXI_PROTECTEN, mask, 0);
- else
- regmap_write(infracfg, INFRA_TOPAXI_PROTECTEN_CLR, mask);
-
- ret = regmap_read_poll_timeout(infracfg, INFRA_TOPAXI_PROTECTSTA1,
- val, !(val & mask),
- MTK_POLL_DELAY_US, MTK_POLL_TIMEOUT);
-
- return ret;
-}
diff --git a/drivers/soc/mediatek/mtk-scpsys.c b/drivers/soc/mediatek/mtk-scpsys.c
index c9c3cf7..b603af7 100644
--- a/drivers/soc/mediatek/mtk-scpsys.c
+++ b/drivers/soc/mediatek/mtk-scpsys.c
@@ -10,8 +10,8 @@
#include <linux/of_device.h>
#include <linux/platform_device.h>
#include <linux/pm_domain.h>
+#include <linux/regmap.h>
#include <linux/regulator/consumer.h>
-#include <linux/soc/mediatek/infracfg.h>
#include <dt-bindings/power/mt2701-power.h>
#include <dt-bindings/power/mt2712-power.h>
@@ -78,6 +78,29 @@
#define PWR_STATUS_HIF1 BIT(26) /* MT7622 */
#define PWR_STATUS_WB BIT(27) /* MT7622 */
+#define INFRA_TOPAXI_PROTECTEN 0x0220
+#define INFRA_TOPAXI_PROTECTSTA1 0x0228
+#define INFRA_TOPAXI_PROTECTEN_SET 0x0260
+#define INFRA_TOPAXI_PROTECTEN_CLR 0x0264
+
+#define MT2701_TOP_AXI_PROT_EN_MM_M0 BIT(1)
+#define MT2701_TOP_AXI_PROT_EN_CONN_M BIT(2)
+#define MT2701_TOP_AXI_PROT_EN_CONN_S BIT(8)
+
+#define MT7622_TOP_AXI_PROT_EN_ETHSYS (BIT(3) | BIT(17))
+#define MT7622_TOP_AXI_PROT_EN_HIF0 (BIT(24) | BIT(25))
+#define MT7622_TOP_AXI_PROT_EN_HIF1 (BIT(26) | BIT(27) | \
+ BIT(28))
+#define MT7622_TOP_AXI_PROT_EN_WB (BIT(2) | BIT(6) | \
+ BIT(7) | BIT(8))
+
+#define MT8173_TOP_AXI_PROT_EN_MM_M0 BIT(1)
+#define MT8173_TOP_AXI_PROT_EN_MM_M1 BIT(2)
+#define MT8173_TOP_AXI_PROT_EN_MFG_S BIT(14)
+#define MT8173_TOP_AXI_PROT_EN_MFG_M0 BIT(21)
+#define MT8173_TOP_AXI_PROT_EN_MFG_M1 BIT(22)
+#define MT8173_TOP_AXI_PROT_EN_MFG_SNOOP_OUT BIT(23)
+
#define MAX_CLKS 3
/**
@@ -251,25 +274,50 @@ static int scpsys_sram_disable(struct scp_domain *scpd, void __iomem *ctl_addr)
static int scpsys_bus_protect_enable(struct scp_domain *scpd)
{
struct scp *scp = scpd->scp;
+ struct regmap *infracfg = scp->infracfg;
+ u32 mask = scpd->data->bus_prot_mask;
+ bool reg_update = scp->bus_prot_reg_update;
+ u32 val;
+ int ret;
- if (!scpd->data->bus_prot_mask)
+ if (!mask)
return 0;
- return mtk_infracfg_set_bus_protection(scp->infracfg,
- scpd->data->bus_prot_mask,
- scp->bus_prot_reg_update);
+ if (reg_update)
+ regmap_update_bits(infracfg, INFRA_TOPAXI_PROTECTEN, mask,
+ mask);
+ else
+ regmap_write(infracfg, INFRA_TOPAXI_PROTECTEN_SET, mask);
+
+ ret = regmap_read_poll_timeout(infracfg, INFRA_TOPAXI_PROTECTSTA1,
+ val, (val & mask) == mask,
+ MTK_POLL_DELAY_US, MTK_POLL_TIMEOUT);
+
+ return ret;
}
static int scpsys_bus_protect_disable(struct scp_domain *scpd)
{
struct scp *scp = scpd->scp;
+ struct regmap *infracfg = scp->infracfg;
+ u32 mask = scpd->data->bus_prot_mask;
+ bool reg_update = scp->bus_prot_reg_update;
+ u32 val;
+ int ret;
- if (!scpd->data->bus_prot_mask)
+ if (!mask)
return 0;
- return mtk_infracfg_clear_bus_protection(scp->infracfg,
- scpd->data->bus_prot_mask,
- scp->bus_prot_reg_update);
+ if (reg_update)
+ regmap_update_bits(infracfg, INFRA_TOPAXI_PROTECTEN, mask, 0);
+ else
+ regmap_write(infracfg, INFRA_TOPAXI_PROTECTEN_CLR, mask);
+
+ ret = regmap_read_poll_timeout(infracfg, INFRA_TOPAXI_PROTECTSTA1,
+ val, !(val & mask),
+ MTK_POLL_DELAY_US, MTK_POLL_TIMEOUT);
+
+ return ret;
}
static int scpsys_power_on(struct generic_pm_domain *genpd)
diff --git a/include/linux/soc/mediatek/infracfg.h b/include/linux/soc/mediatek/infracfg.h
deleted file mode 100644
index fd25f01..0000000
--- a/include/linux/soc/mediatek/infracfg.h
+++ /dev/null
@@ -1,39 +0,0 @@
-/* SPDX-License-Identifier: GPL-2.0 */
-#ifndef __SOC_MEDIATEK_INFRACFG_H
-#define __SOC_MEDIATEK_INFRACFG_H
-
-#define MT8173_TOP_AXI_PROT_EN_MCI_M2 BIT(0)
-#define MT8173_TOP_AXI_PROT_EN_MM_M0 BIT(1)
-#define MT8173_TOP_AXI_PROT_EN_MM_M1 BIT(2)
-#define MT8173_TOP_AXI_PROT_EN_MMAPB_S BIT(6)
-#define MT8173_TOP_AXI_PROT_EN_L2C_M2 BIT(9)
-#define MT8173_TOP_AXI_PROT_EN_L2SS_SMI BIT(11)
-#define MT8173_TOP_AXI_PROT_EN_L2SS_ADD BIT(12)
-#define MT8173_TOP_AXI_PROT_EN_CCI_M2 BIT(13)
-#define MT8173_TOP_AXI_PROT_EN_MFG_S BIT(14)
-#define MT8173_TOP_AXI_PROT_EN_PERI_M0 BIT(15)
-#define MT8173_TOP_AXI_PROT_EN_PERI_M1 BIT(16)
-#define MT8173_TOP_AXI_PROT_EN_DEBUGSYS BIT(17)
-#define MT8173_TOP_AXI_PROT_EN_CQ_DMA BIT(18)
-#define MT8173_TOP_AXI_PROT_EN_GCPU BIT(19)
-#define MT8173_TOP_AXI_PROT_EN_IOMMU BIT(20)
-#define MT8173_TOP_AXI_PROT_EN_MFG_M0 BIT(21)
-#define MT8173_TOP_AXI_PROT_EN_MFG_M1 BIT(22)
-#define MT8173_TOP_AXI_PROT_EN_MFG_SNOOP_OUT BIT(23)
-
-#define MT2701_TOP_AXI_PROT_EN_MM_M0 BIT(1)
-#define MT2701_TOP_AXI_PROT_EN_CONN_M BIT(2)
-#define MT2701_TOP_AXI_PROT_EN_CONN_S BIT(8)
-
-#define MT7622_TOP_AXI_PROT_EN_ETHSYS (BIT(3) | BIT(17))
-#define MT7622_TOP_AXI_PROT_EN_HIF0 (BIT(24) | BIT(25))
-#define MT7622_TOP_AXI_PROT_EN_HIF1 (BIT(26) | BIT(27) | \
- BIT(28))
-#define MT7622_TOP_AXI_PROT_EN_WB (BIT(2) | BIT(6) | \
- BIT(7) | BIT(8))
-
-int mtk_infracfg_set_bus_protection(struct regmap *infracfg, u32 mask,
- bool reg_update);
-int mtk_infracfg_clear_bus_protection(struct regmap *infracfg, u32 mask,
- bool reg_update);
-#endif /* __SOC_MEDIATEK_INFRACFG_H */
--
1.8.1.1.dirty
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply related
* [PATCH v15 03/11] soc: mediatek: Add basic_clk_name to scp_power_data
From: Weiyi Lu @ 2020-05-21 9:06 UTC (permalink / raw)
To: Enric Balletbo Serra, Matthias Brugger, Nicolas Boichat,
Rob Herring, Sascha Hauer
Cc: James Liao, Weiyi Lu, srv_heupstream, devicetree, linux-kernel,
Fan Chen, linux-mediatek, linux-arm-kernel
In-Reply-To: <1590051985-29149-1-git-send-email-weiyi.lu@mediatek.com>
Try to stop extending the clk_id or clk_names if there are
more and more new BASIC clocks. To get its own clocks by the
basic_clk_name of each power domain.
And then use basic_clk_name strings for all compatibles, instead of
mixing clk_id and clk_name.
Signed-off-by: Weiyi Lu <weiyi.lu@mediatek.com>
Reviewed-by: Nicolas Boichat <drinkcat@chromium.org>
---
drivers/soc/mediatek/mtk-scpsys.c | 134 ++++++++++++--------------------------
1 file changed, 41 insertions(+), 93 deletions(-)
diff --git a/drivers/soc/mediatek/mtk-scpsys.c b/drivers/soc/mediatek/mtk-scpsys.c
index f669d37..c9c3cf7 100644
--- a/drivers/soc/mediatek/mtk-scpsys.c
+++ b/drivers/soc/mediatek/mtk-scpsys.c
@@ -78,34 +78,6 @@
#define PWR_STATUS_HIF1 BIT(26) /* MT7622 */
#define PWR_STATUS_WB BIT(27) /* MT7622 */
-enum clk_id {
- CLK_NONE,
- CLK_MM,
- CLK_MFG,
- CLK_VENC,
- CLK_VENC_LT,
- CLK_ETHIF,
- CLK_VDEC,
- CLK_HIFSEL,
- CLK_JPGDEC,
- CLK_AUDIO,
- CLK_MAX,
-};
-
-static const char * const clk_names[] = {
- NULL,
- "mm",
- "mfg",
- "venc",
- "venc_lt",
- "ethif",
- "vdec",
- "hif_sel",
- "jpgdec",
- "audio",
- NULL,
-};
-
#define MAX_CLKS 3
/**
@@ -116,7 +88,7 @@ enum clk_id {
* @sram_pdn_bits: The mask for sram power control bits.
* @sram_pdn_ack_bits: The mask for sram power control acked bits.
* @bus_prot_mask: The mask for single step bus protection.
- * @clk_id: The basic clocks required by this power domain.
+ * @basic_clk_name: The basic clocks required by this power domain.
* @caps: The flag for active wake-up action.
*/
struct scp_domain_data {
@@ -126,7 +98,7 @@ struct scp_domain_data {
u32 sram_pdn_bits;
u32 sram_pdn_ack_bits;
u32 bus_prot_mask;
- enum clk_id clk_id[MAX_CLKS];
+ const char *basic_clk_name[MAX_CLKS];
u8 caps;
};
@@ -411,12 +383,19 @@ static int scpsys_power_off(struct generic_pm_domain *genpd)
return ret;
}
-static void init_clks(struct platform_device *pdev, struct clk **clk)
+static int init_basic_clks(struct platform_device *pdev, struct clk **clk,
+ const char * const *name)
{
int i;
- for (i = CLK_NONE + 1; i < CLK_MAX; i++)
- clk[i] = devm_clk_get(&pdev->dev, clk_names[i]);
+ for (i = 0; i < MAX_CLKS && name[i]; i++) {
+ clk[i] = devm_clk_get(&pdev->dev, name[i]);
+
+ if (IS_ERR(clk[i]))
+ return PTR_ERR(clk[i]);
+ }
+
+ return 0;
}
static struct scp *init_scp(struct platform_device *pdev,
@@ -426,9 +405,8 @@ static struct scp *init_scp(struct platform_device *pdev,
{
struct genpd_onecell_data *pd_data;
struct resource *res;
- int i, j;
+ int i, ret;
struct scp *scp;
- struct clk *clk[CLK_MAX];
scp = devm_kzalloc(&pdev->dev, sizeof(*scp), GFP_KERNEL);
if (!scp)
@@ -481,8 +459,6 @@ static struct scp *init_scp(struct platform_device *pdev,
pd_data->num_domains = num;
- init_clks(pdev, clk);
-
for (i = 0; i < num; i++) {
struct scp_domain *scpd = &scp->domains[i];
struct generic_pm_domain *genpd = &scpd->genpd;
@@ -493,17 +469,9 @@ static struct scp *init_scp(struct platform_device *pdev,
scpd->data = data;
- for (j = 0; j < MAX_CLKS && data->clk_id[j]; j++) {
- struct clk *c = clk[data->clk_id[j]];
-
- if (IS_ERR(c)) {
- dev_err(&pdev->dev, "%s: clk unavailable\n",
- data->name);
- return ERR_CAST(c);
- }
-
- scpd->clk[j] = c;
- }
+ ret = init_basic_clks(pdev, scpd->clk, data->basic_clk_name);
+ if (ret)
+ return ERR_PTR(ret);
genpd->name = data->name;
genpd->power_off = scpsys_power_off;
@@ -560,7 +528,6 @@ static void mtk_register_power_domains(struct platform_device *pdev,
.ctl_offs = SPM_CONN_PWR_CON,
.bus_prot_mask = MT2701_TOP_AXI_PROT_EN_CONN_M |
MT2701_TOP_AXI_PROT_EN_CONN_S,
- .clk_id = {CLK_NONE},
.caps = MTK_SCPD_ACTIVE_WAKEUP,
},
[MT2701_POWER_DOMAIN_DISP] = {
@@ -568,7 +535,7 @@ static void mtk_register_power_domains(struct platform_device *pdev,
.sta_mask = PWR_STATUS_DISP,
.ctl_offs = SPM_DIS_PWR_CON,
.sram_pdn_bits = GENMASK(11, 8),
- .clk_id = {CLK_MM},
+ .basic_clk_name = {"mm"},
.bus_prot_mask = MT2701_TOP_AXI_PROT_EN_MM_M0,
.caps = MTK_SCPD_ACTIVE_WAKEUP,
},
@@ -578,7 +545,7 @@ static void mtk_register_power_domains(struct platform_device *pdev,
.ctl_offs = SPM_MFG_PWR_CON,
.sram_pdn_bits = GENMASK(11, 8),
.sram_pdn_ack_bits = GENMASK(12, 12),
- .clk_id = {CLK_MFG},
+ .basic_clk_name = {"mfg"},
.caps = MTK_SCPD_ACTIVE_WAKEUP,
},
[MT2701_POWER_DOMAIN_VDEC] = {
@@ -587,7 +554,7 @@ static void mtk_register_power_domains(struct platform_device *pdev,
.ctl_offs = SPM_VDE_PWR_CON,
.sram_pdn_bits = GENMASK(11, 8),
.sram_pdn_ack_bits = GENMASK(12, 12),
- .clk_id = {CLK_MM},
+ .basic_clk_name = {"mm"},
.caps = MTK_SCPD_ACTIVE_WAKEUP,
},
[MT2701_POWER_DOMAIN_ISP] = {
@@ -596,7 +563,7 @@ static void mtk_register_power_domains(struct platform_device *pdev,
.ctl_offs = SPM_ISP_PWR_CON,
.sram_pdn_bits = GENMASK(11, 8),
.sram_pdn_ack_bits = GENMASK(13, 12),
- .clk_id = {CLK_MM},
+ .basic_clk_name = {"mm"},
.caps = MTK_SCPD_ACTIVE_WAKEUP,
},
[MT2701_POWER_DOMAIN_BDP] = {
@@ -604,7 +571,6 @@ static void mtk_register_power_domains(struct platform_device *pdev,
.sta_mask = PWR_STATUS_BDP,
.ctl_offs = SPM_BDP_PWR_CON,
.sram_pdn_bits = GENMASK(11, 8),
- .clk_id = {CLK_NONE},
.caps = MTK_SCPD_ACTIVE_WAKEUP,
},
[MT2701_POWER_DOMAIN_ETH] = {
@@ -613,7 +579,7 @@ static void mtk_register_power_domains(struct platform_device *pdev,
.ctl_offs = SPM_ETH_PWR_CON,
.sram_pdn_bits = GENMASK(11, 8),
.sram_pdn_ack_bits = GENMASK(15, 12),
- .clk_id = {CLK_ETHIF},
+ .basic_clk_name = {"ethif"},
.caps = MTK_SCPD_ACTIVE_WAKEUP,
},
[MT2701_POWER_DOMAIN_HIF] = {
@@ -622,14 +588,13 @@ static void mtk_register_power_domains(struct platform_device *pdev,
.ctl_offs = SPM_HIF_PWR_CON,
.sram_pdn_bits = GENMASK(11, 8),
.sram_pdn_ack_bits = GENMASK(15, 12),
- .clk_id = {CLK_ETHIF},
+ .basic_clk_name = {"ethif"},
.caps = MTK_SCPD_ACTIVE_WAKEUP,
},
[MT2701_POWER_DOMAIN_IFR_MSC] = {
.name = "ifr_msc",
.sta_mask = PWR_STATUS_IFR_MSC,
.ctl_offs = SPM_IFR_MSC_PWR_CON,
- .clk_id = {CLK_NONE},
.caps = MTK_SCPD_ACTIVE_WAKEUP,
},
};
@@ -644,7 +609,7 @@ static void mtk_register_power_domains(struct platform_device *pdev,
.ctl_offs = SPM_DIS_PWR_CON,
.sram_pdn_bits = GENMASK(8, 8),
.sram_pdn_ack_bits = GENMASK(12, 12),
- .clk_id = {CLK_MM},
+ .basic_clk_name = {"mm"},
.caps = MTK_SCPD_ACTIVE_WAKEUP,
},
[MT2712_POWER_DOMAIN_VDEC] = {
@@ -653,7 +618,7 @@ static void mtk_register_power_domains(struct platform_device *pdev,
.ctl_offs = SPM_VDE_PWR_CON,
.sram_pdn_bits = GENMASK(8, 8),
.sram_pdn_ack_bits = GENMASK(12, 12),
- .clk_id = {CLK_MM, CLK_VDEC},
+ .basic_clk_name = {"mm", "vdec"},
.caps = MTK_SCPD_ACTIVE_WAKEUP,
},
[MT2712_POWER_DOMAIN_VENC] = {
@@ -662,7 +627,7 @@ static void mtk_register_power_domains(struct platform_device *pdev,
.ctl_offs = SPM_VEN_PWR_CON,
.sram_pdn_bits = GENMASK(11, 8),
.sram_pdn_ack_bits = GENMASK(15, 12),
- .clk_id = {CLK_MM, CLK_VENC, CLK_JPGDEC},
+ .basic_clk_name = {"mm", "venc", "jpgdec"},
.caps = MTK_SCPD_ACTIVE_WAKEUP,
},
[MT2712_POWER_DOMAIN_ISP] = {
@@ -671,7 +636,7 @@ static void mtk_register_power_domains(struct platform_device *pdev,
.ctl_offs = SPM_ISP_PWR_CON,
.sram_pdn_bits = GENMASK(11, 8),
.sram_pdn_ack_bits = GENMASK(13, 12),
- .clk_id = {CLK_MM},
+ .basic_clk_name = {"mm"},
.caps = MTK_SCPD_ACTIVE_WAKEUP,
},
[MT2712_POWER_DOMAIN_AUDIO] = {
@@ -680,7 +645,7 @@ static void mtk_register_power_domains(struct platform_device *pdev,
.ctl_offs = SPM_AUDIO_PWR_CON,
.sram_pdn_bits = GENMASK(11, 8),
.sram_pdn_ack_bits = GENMASK(15, 12),
- .clk_id = {CLK_AUDIO},
+ .basic_clk_name = {"audio"},
.caps = MTK_SCPD_ACTIVE_WAKEUP,
},
[MT2712_POWER_DOMAIN_USB] = {
@@ -689,7 +654,6 @@ static void mtk_register_power_domains(struct platform_device *pdev,
.ctl_offs = SPM_USB_PWR_CON,
.sram_pdn_bits = GENMASK(10, 8),
.sram_pdn_ack_bits = GENMASK(14, 12),
- .clk_id = {CLK_NONE},
.caps = MTK_SCPD_ACTIVE_WAKEUP,
},
[MT2712_POWER_DOMAIN_USB2] = {
@@ -698,7 +662,6 @@ static void mtk_register_power_domains(struct platform_device *pdev,
.ctl_offs = SPM_USB2_PWR_CON,
.sram_pdn_bits = GENMASK(10, 8),
.sram_pdn_ack_bits = GENMASK(14, 12),
- .clk_id = {CLK_NONE},
.caps = MTK_SCPD_ACTIVE_WAKEUP,
},
[MT2712_POWER_DOMAIN_MFG] = {
@@ -707,7 +670,7 @@ static void mtk_register_power_domains(struct platform_device *pdev,
.ctl_offs = SPM_MFG_PWR_CON,
.sram_pdn_bits = GENMASK(8, 8),
.sram_pdn_ack_bits = GENMASK(16, 16),
- .clk_id = {CLK_MFG},
+ .basic_clk_name = {"mfg"},
.bus_prot_mask = BIT(14) | BIT(21) | BIT(23),
.caps = MTK_SCPD_ACTIVE_WAKEUP,
},
@@ -717,7 +680,6 @@ static void mtk_register_power_domains(struct platform_device *pdev,
.ctl_offs = 0x02c0,
.sram_pdn_bits = GENMASK(8, 8),
.sram_pdn_ack_bits = GENMASK(16, 16),
- .clk_id = {CLK_NONE},
.caps = MTK_SCPD_ACTIVE_WAKEUP,
},
[MT2712_POWER_DOMAIN_MFG_SC2] = {
@@ -726,7 +688,6 @@ static void mtk_register_power_domains(struct platform_device *pdev,
.ctl_offs = 0x02c4,
.sram_pdn_bits = GENMASK(8, 8),
.sram_pdn_ack_bits = GENMASK(16, 16),
- .clk_id = {CLK_NONE},
.caps = MTK_SCPD_ACTIVE_WAKEUP,
},
[MT2712_POWER_DOMAIN_MFG_SC3] = {
@@ -735,7 +696,6 @@ static void mtk_register_power_domains(struct platform_device *pdev,
.ctl_offs = 0x01f8,
.sram_pdn_bits = GENMASK(8, 8),
.sram_pdn_ack_bits = GENMASK(16, 16),
- .clk_id = {CLK_NONE},
.caps = MTK_SCPD_ACTIVE_WAKEUP,
},
};
@@ -760,7 +720,7 @@ static void mtk_register_power_domains(struct platform_device *pdev,
.ctl_offs = 0x300,
.sram_pdn_bits = GENMASK(8, 8),
.sram_pdn_ack_bits = GENMASK(12, 12),
- .clk_id = {CLK_VDEC},
+ .basic_clk_name = {"vdec"},
},
[MT6797_POWER_DOMAIN_VENC] = {
.name = "venc",
@@ -768,7 +728,6 @@ static void mtk_register_power_domains(struct platform_device *pdev,
.ctl_offs = 0x304,
.sram_pdn_bits = GENMASK(11, 8),
.sram_pdn_ack_bits = GENMASK(15, 12),
- .clk_id = {CLK_NONE},
},
[MT6797_POWER_DOMAIN_ISP] = {
.name = "isp",
@@ -776,7 +735,6 @@ static void mtk_register_power_domains(struct platform_device *pdev,
.ctl_offs = 0x308,
.sram_pdn_bits = GENMASK(9, 8),
.sram_pdn_ack_bits = GENMASK(13, 12),
- .clk_id = {CLK_NONE},
},
[MT6797_POWER_DOMAIN_MM] = {
.name = "mm",
@@ -784,7 +742,7 @@ static void mtk_register_power_domains(struct platform_device *pdev,
.ctl_offs = 0x30C,
.sram_pdn_bits = GENMASK(8, 8),
.sram_pdn_ack_bits = GENMASK(12, 12),
- .clk_id = {CLK_MM},
+ .basic_clk_name = {"mm"},
.bus_prot_mask = (BIT(1) | BIT(2)),
},
[MT6797_POWER_DOMAIN_AUDIO] = {
@@ -793,7 +751,6 @@ static void mtk_register_power_domains(struct platform_device *pdev,
.ctl_offs = 0x314,
.sram_pdn_bits = GENMASK(11, 8),
.sram_pdn_ack_bits = GENMASK(15, 12),
- .clk_id = {CLK_NONE},
},
[MT6797_POWER_DOMAIN_MFG_ASYNC] = {
.name = "mfg_async",
@@ -801,7 +758,7 @@ static void mtk_register_power_domains(struct platform_device *pdev,
.ctl_offs = 0x334,
.sram_pdn_bits = 0,
.sram_pdn_ack_bits = 0,
- .clk_id = {CLK_MFG},
+ .basic_clk_name = {"mfg"},
},
[MT6797_POWER_DOMAIN_MJC] = {
.name = "mjc",
@@ -809,7 +766,6 @@ static void mtk_register_power_domains(struct platform_device *pdev,
.ctl_offs = 0x310,
.sram_pdn_bits = GENMASK(8, 8),
.sram_pdn_ack_bits = GENMASK(12, 12),
- .clk_id = {CLK_NONE},
},
};
@@ -834,7 +790,6 @@ static void mtk_register_power_domains(struct platform_device *pdev,
.ctl_offs = SPM_ETHSYS_PWR_CON,
.sram_pdn_bits = GENMASK(11, 8),
.sram_pdn_ack_bits = GENMASK(15, 12),
- .clk_id = {CLK_NONE},
.bus_prot_mask = MT7622_TOP_AXI_PROT_EN_ETHSYS,
.caps = MTK_SCPD_ACTIVE_WAKEUP,
},
@@ -844,7 +799,7 @@ static void mtk_register_power_domains(struct platform_device *pdev,
.ctl_offs = SPM_HIF0_PWR_CON,
.sram_pdn_bits = GENMASK(11, 8),
.sram_pdn_ack_bits = GENMASK(15, 12),
- .clk_id = {CLK_HIFSEL},
+ .basic_clk_name = {"hif_sel"},
.bus_prot_mask = MT7622_TOP_AXI_PROT_EN_HIF0,
.caps = MTK_SCPD_ACTIVE_WAKEUP,
},
@@ -854,7 +809,7 @@ static void mtk_register_power_domains(struct platform_device *pdev,
.ctl_offs = SPM_HIF1_PWR_CON,
.sram_pdn_bits = GENMASK(11, 8),
.sram_pdn_ack_bits = GENMASK(15, 12),
- .clk_id = {CLK_HIFSEL},
+ .basic_clk_name = {"hif_sel"},
.bus_prot_mask = MT7622_TOP_AXI_PROT_EN_HIF1,
.caps = MTK_SCPD_ACTIVE_WAKEUP,
},
@@ -864,7 +819,6 @@ static void mtk_register_power_domains(struct platform_device *pdev,
.ctl_offs = SPM_WB_PWR_CON,
.sram_pdn_bits = 0,
.sram_pdn_ack_bits = 0,
- .clk_id = {CLK_NONE},
.bus_prot_mask = MT7622_TOP_AXI_PROT_EN_WB,
.caps = MTK_SCPD_ACTIVE_WAKEUP | MTK_SCPD_FWAIT_SRAM,
},
@@ -881,7 +835,6 @@ static void mtk_register_power_domains(struct platform_device *pdev,
.ctl_offs = SPM_CONN_PWR_CON,
.bus_prot_mask = MT2701_TOP_AXI_PROT_EN_CONN_M |
MT2701_TOP_AXI_PROT_EN_CONN_S,
- .clk_id = {CLK_NONE},
.caps = MTK_SCPD_ACTIVE_WAKEUP,
},
[MT7623A_POWER_DOMAIN_ETH] = {
@@ -890,7 +843,7 @@ static void mtk_register_power_domains(struct platform_device *pdev,
.ctl_offs = SPM_ETH_PWR_CON,
.sram_pdn_bits = GENMASK(11, 8),
.sram_pdn_ack_bits = GENMASK(15, 12),
- .clk_id = {CLK_ETHIF},
+ .basic_clk_name = {"ethif"},
.caps = MTK_SCPD_ACTIVE_WAKEUP,
},
[MT7623A_POWER_DOMAIN_HIF] = {
@@ -899,14 +852,13 @@ static void mtk_register_power_domains(struct platform_device *pdev,
.ctl_offs = SPM_HIF_PWR_CON,
.sram_pdn_bits = GENMASK(11, 8),
.sram_pdn_ack_bits = GENMASK(15, 12),
- .clk_id = {CLK_ETHIF},
+ .basic_clk_name = {"ethif"},
.caps = MTK_SCPD_ACTIVE_WAKEUP,
},
[MT7623A_POWER_DOMAIN_IFR_MSC] = {
.name = "ifr_msc",
.sta_mask = PWR_STATUS_IFR_MSC,
.ctl_offs = SPM_IFR_MSC_PWR_CON,
- .clk_id = {CLK_NONE},
.caps = MTK_SCPD_ACTIVE_WAKEUP,
},
};
@@ -922,7 +874,7 @@ static void mtk_register_power_domains(struct platform_device *pdev,
.ctl_offs = SPM_VDE_PWR_CON,
.sram_pdn_bits = GENMASK(11, 8),
.sram_pdn_ack_bits = GENMASK(12, 12),
- .clk_id = {CLK_MM},
+ .basic_clk_name = {"mm"},
},
[MT8173_POWER_DOMAIN_VENC] = {
.name = "venc",
@@ -930,7 +882,7 @@ static void mtk_register_power_domains(struct platform_device *pdev,
.ctl_offs = SPM_VEN_PWR_CON,
.sram_pdn_bits = GENMASK(11, 8),
.sram_pdn_ack_bits = GENMASK(15, 12),
- .clk_id = {CLK_MM, CLK_VENC},
+ .basic_clk_name = {"mm", "venc"},
},
[MT8173_POWER_DOMAIN_ISP] = {
.name = "isp",
@@ -938,7 +890,7 @@ static void mtk_register_power_domains(struct platform_device *pdev,
.ctl_offs = SPM_ISP_PWR_CON,
.sram_pdn_bits = GENMASK(11, 8),
.sram_pdn_ack_bits = GENMASK(13, 12),
- .clk_id = {CLK_MM},
+ .basic_clk_name = {"mm"},
},
[MT8173_POWER_DOMAIN_MM] = {
.name = "mm",
@@ -946,7 +898,7 @@ static void mtk_register_power_domains(struct platform_device *pdev,
.ctl_offs = SPM_DIS_PWR_CON,
.sram_pdn_bits = GENMASK(11, 8),
.sram_pdn_ack_bits = GENMASK(12, 12),
- .clk_id = {CLK_MM},
+ .basic_clk_name = {"mm"},
.bus_prot_mask = MT8173_TOP_AXI_PROT_EN_MM_M0 |
MT8173_TOP_AXI_PROT_EN_MM_M1,
},
@@ -956,7 +908,7 @@ static void mtk_register_power_domains(struct platform_device *pdev,
.ctl_offs = SPM_VEN2_PWR_CON,
.sram_pdn_bits = GENMASK(11, 8),
.sram_pdn_ack_bits = GENMASK(15, 12),
- .clk_id = {CLK_MM, CLK_VENC_LT},
+ .basic_clk_name = {"mm", "venc_lt"},
},
[MT8173_POWER_DOMAIN_AUDIO] = {
.name = "audio",
@@ -964,7 +916,6 @@ static void mtk_register_power_domains(struct platform_device *pdev,
.ctl_offs = SPM_AUDIO_PWR_CON,
.sram_pdn_bits = GENMASK(11, 8),
.sram_pdn_ack_bits = GENMASK(15, 12),
- .clk_id = {CLK_NONE},
},
[MT8173_POWER_DOMAIN_USB] = {
.name = "usb",
@@ -972,7 +923,6 @@ static void mtk_register_power_domains(struct platform_device *pdev,
.ctl_offs = SPM_USB_PWR_CON,
.sram_pdn_bits = GENMASK(11, 8),
.sram_pdn_ack_bits = GENMASK(15, 12),
- .clk_id = {CLK_NONE},
.caps = MTK_SCPD_ACTIVE_WAKEUP,
},
[MT8173_POWER_DOMAIN_MFG_ASYNC] = {
@@ -981,7 +931,7 @@ static void mtk_register_power_domains(struct platform_device *pdev,
.ctl_offs = SPM_MFG_ASYNC_PWR_CON,
.sram_pdn_bits = GENMASK(11, 8),
.sram_pdn_ack_bits = 0,
- .clk_id = {CLK_MFG},
+ .basic_clk_name = {"mfg"},
},
[MT8173_POWER_DOMAIN_MFG_2D] = {
.name = "mfg_2d",
@@ -989,7 +939,6 @@ static void mtk_register_power_domains(struct platform_device *pdev,
.ctl_offs = SPM_MFG_2D_PWR_CON,
.sram_pdn_bits = GENMASK(11, 8),
.sram_pdn_ack_bits = GENMASK(13, 12),
- .clk_id = {CLK_NONE},
},
[MT8173_POWER_DOMAIN_MFG] = {
.name = "mfg",
@@ -997,7 +946,6 @@ static void mtk_register_power_domains(struct platform_device *pdev,
.ctl_offs = SPM_MFG_PWR_CON,
.sram_pdn_bits = GENMASK(13, 8),
.sram_pdn_ack_bits = GENMASK(21, 16),
- .clk_id = {CLK_NONE},
.bus_prot_mask = MT8173_TOP_AXI_PROT_EN_MFG_S |
MT8173_TOP_AXI_PROT_EN_MFG_M0 |
MT8173_TOP_AXI_PROT_EN_MFG_M1 |
--
1.8.1.1.dirty
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply related
* [PATCH v15 06/11] soc: mediatek: Add subsys clock control for bus protection
From: Weiyi Lu @ 2020-05-21 9:06 UTC (permalink / raw)
To: Enric Balletbo Serra, Matthias Brugger, Nicolas Boichat,
Rob Herring, Sascha Hauer
Cc: James Liao, Weiyi Lu, srv_heupstream, devicetree, linux-kernel,
Fan Chen, linux-mediatek, linux-arm-kernel
In-Reply-To: <1590051985-29149-1-git-send-email-weiyi.lu@mediatek.com>
For the bus protection operations, some subsys clocks need to be enabled
before releasing the protection, and vice versa.
But those subsys clocks could only be controlled once its corresponding
power domain is turned on first.
In this patch, we add the subsys clock control into its relevant steps.
Signed-off-by: Weiyi Lu <weiyi.lu@mediatek.com>
---
drivers/soc/mediatek/mtk-scpsys.c | 62 +++++++++++++++++++++++++++++++++++++--
1 file changed, 60 insertions(+), 2 deletions(-)
diff --git a/drivers/soc/mediatek/mtk-scpsys.c b/drivers/soc/mediatek/mtk-scpsys.c
index 59a525a..ef2c668 100644
--- a/drivers/soc/mediatek/mtk-scpsys.c
+++ b/drivers/soc/mediatek/mtk-scpsys.c
@@ -97,6 +97,7 @@
#define MT8173_TOP_AXI_PROT_EN_MFG_SNOOP_OUT BIT(23)
#define MAX_CLKS 3
+#define MAX_SUBSYS_CLKS 10
#define MAX_STEPS 4
@@ -145,6 +146,8 @@ struct bus_prot {
* @sram_pdn_bits: The mask for sram power control bits.
* @sram_pdn_ack_bits: The mask for sram power control acked bits.
* @basic_clk_name: The basic clocks required by this power domain.
+ * @subsys_clk_prefix: The prefix name of the clocks need to be enabled
+ * before releasing bus protection.
* @caps: The flag for active wake-up action.
* @bp_table: The mask table for multiple step bus protection.
*/
@@ -155,6 +158,7 @@ struct scp_domain_data {
u32 sram_pdn_bits;
u32 sram_pdn_ack_bits;
const char *basic_clk_name[MAX_CLKS];
+ const char *subsys_clk_prefix;
u8 caps;
struct bus_prot bp_table[MAX_STEPS];
};
@@ -165,6 +169,7 @@ struct scp_domain {
struct generic_pm_domain genpd;
struct scp *scp;
struct clk *clk[MAX_CLKS];
+ struct clk *subsys_clk[MAX_SUBSYS_CLKS];
const struct scp_domain_data *data;
struct regulator *supply;
};
@@ -425,16 +430,22 @@ static int scpsys_power_on(struct generic_pm_domain *genpd)
val |= PWR_RST_B_BIT;
writel(val, ctl_addr);
- ret = scpsys_sram_enable(scpd, ctl_addr);
+ ret = scpsys_clk_enable(scpd->subsys_clk, MAX_SUBSYS_CLKS);
if (ret < 0)
goto err_pwr_ack;
+ ret = scpsys_sram_enable(scpd, ctl_addr);
+ if (ret < 0)
+ goto err_sram;
+
ret = scpsys_bus_protect_disable(scpd);
if (ret < 0)
- goto err_pwr_ack;
+ goto err_sram;
return 0;
+err_sram:
+ scpsys_clk_disable(scpd->subsys_clk, MAX_SUBSYS_CLKS);
err_pwr_ack:
scpsys_clk_disable(scpd->clk, MAX_CLKS);
err_clk:
@@ -461,6 +472,8 @@ static int scpsys_power_off(struct generic_pm_domain *genpd)
if (ret < 0)
goto out;
+ scpsys_clk_disable(scpd->subsys_clk, MAX_SUBSYS_CLKS);
+
/* subsys power off */
val = readl(ctl_addr);
val |= PWR_ISO_BIT;
@@ -498,6 +511,39 @@ static int scpsys_power_off(struct generic_pm_domain *genpd)
return ret;
}
+static int init_subsys_clks(struct platform_device *pdev,
+ const char *prefix, struct clk **clk)
+{
+ struct device_node *node = pdev->dev.of_node;
+ u32 prefix_len, sub_clk_cnt = 0;
+ struct property *prop;
+ const char *clk_name;
+
+ prefix_len = strlen(prefix);
+
+ of_property_for_each_string(node, "clock-names", prop, clk_name) {
+ if (!strncmp(clk_name, prefix, prefix_len) &&
+ (clk_name[prefix_len] == '-')) {
+ if (sub_clk_cnt >= MAX_SUBSYS_CLKS) {
+ dev_err(&pdev->dev,
+ "subsys clk out of range %d\n",
+ sub_clk_cnt);
+ return -EINVAL;
+ }
+
+ clk[sub_clk_cnt] = devm_clk_get(&pdev->dev,
+ clk_name);
+
+ if (IS_ERR(clk[sub_clk_cnt]))
+ return PTR_ERR(clk[sub_clk_cnt]);
+
+ sub_clk_cnt++;
+ }
+ }
+
+ return sub_clk_cnt;
+}
+
static int init_basic_clks(struct platform_device *pdev, struct clk **clk,
const char * const *name)
{
@@ -596,6 +642,18 @@ static struct scp *init_scp(struct platform_device *pdev,
if (ret)
return ERR_PTR(ret);
+ if (data->subsys_clk_prefix) {
+ ret = init_subsys_clks(pdev,
+ data->subsys_clk_prefix,
+ scpd->subsys_clk);
+ if (ret < 0) {
+ dev_err(&pdev->dev,
+ "%s: subsys clk unavailable\n",
+ data->name);
+ return ERR_PTR(ret);
+ }
+ }
+
genpd->name = data->name;
genpd->power_off = scpsys_power_off;
genpd->power_on = scpsys_power_on;
--
1.8.1.1.dirty
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply related
* [PATCH v15 10/11] arm64: dts: Add power controller device node of MT8183
From: Weiyi Lu @ 2020-05-21 9:06 UTC (permalink / raw)
To: Enric Balletbo Serra, Matthias Brugger, Nicolas Boichat,
Rob Herring, Sascha Hauer
Cc: James Liao, Weiyi Lu, srv_heupstream, devicetree, linux-kernel,
Fan Chen, linux-mediatek, linux-arm-kernel
In-Reply-To: <1590051985-29149-1-git-send-email-weiyi.lu@mediatek.com>
Add power controller node and smi-common node for MT8183
In scpsys node, it contains clocks and regmapping of
infracfg and smi-common for bus protection.
Signed-off-by: Weiyi Lu <weiyi.lu@mediatek.com>
---
arch/arm64/boot/dts/mediatek/mt8183.dtsi | 62 ++++++++++++++++++++++++++++++++
1 file changed, 62 insertions(+)
diff --git a/arch/arm64/boot/dts/mediatek/mt8183.dtsi b/arch/arm64/boot/dts/mediatek/mt8183.dtsi
index 97863ad..ff7fe0c 100644
--- a/arch/arm64/boot/dts/mediatek/mt8183.dtsi
+++ b/arch/arm64/boot/dts/mediatek/mt8183.dtsi
@@ -8,6 +8,7 @@
#include <dt-bindings/clock/mt8183-clk.h>
#include <dt-bindings/interrupt-controller/arm-gic.h>
#include <dt-bindings/interrupt-controller/irq.h>
+#include <dt-bindings/power/mt8183-power.h>
#include <dt-bindings/reset-controller/mt8183-resets.h>
#include "mt8183-pinfunc.h"
@@ -301,6 +302,62 @@
#interrupt-cells = <2>;
};
+ scpsys: power-controller@10006000 {
+ compatible = "mediatek,mt8183-scpsys", "syscon";
+ #power-domain-cells = <1>;
+ reg = <0 0x10006000 0 0x1000>;
+ clocks = <&topckgen CLK_TOP_MUX_AUD_INTBUS>,
+ <&infracfg CLK_INFRA_AUDIO>,
+ <&infracfg CLK_INFRA_AUDIO_26M_BCLK>,
+ <&topckgen CLK_TOP_MUX_MFG>,
+ <&topckgen CLK_TOP_MUX_MM>,
+ <&topckgen CLK_TOP_MUX_CAM>,
+ <&topckgen CLK_TOP_MUX_IMG>,
+ <&topckgen CLK_TOP_MUX_IPU_IF>,
+ <&topckgen CLK_TOP_MUX_DSP>,
+ <&topckgen CLK_TOP_MUX_DSP1>,
+ <&topckgen CLK_TOP_MUX_DSP2>,
+ <&mmsys CLK_MM_SMI_COMMON>,
+ <&mmsys CLK_MM_SMI_LARB0>,
+ <&mmsys CLK_MM_SMI_LARB1>,
+ <&mmsys CLK_MM_GALS_COMM0>,
+ <&mmsys CLK_MM_GALS_COMM1>,
+ <&mmsys CLK_MM_GALS_CCU2MM>,
+ <&mmsys CLK_MM_GALS_IPU12MM>,
+ <&mmsys CLK_MM_GALS_IMG2MM>,
+ <&mmsys CLK_MM_GALS_CAM2MM>,
+ <&mmsys CLK_MM_GALS_IPU2MM>,
+ <&imgsys CLK_IMG_LARB5>,
+ <&imgsys CLK_IMG_LARB2>,
+ <&camsys CLK_CAM_LARB6>,
+ <&camsys CLK_CAM_LARB3>,
+ <&camsys CLK_CAM_SENINF>,
+ <&camsys CLK_CAM_CAMSV0>,
+ <&camsys CLK_CAM_CAMSV1>,
+ <&camsys CLK_CAM_CAMSV2>,
+ <&camsys CLK_CAM_CCU>,
+ <&ipu_conn CLK_IPU_CONN_IPU>,
+ <&ipu_conn CLK_IPU_CONN_AHB>,
+ <&ipu_conn CLK_IPU_CONN_AXI>,
+ <&ipu_conn CLK_IPU_CONN_ISP>,
+ <&ipu_conn CLK_IPU_CONN_CAM_ADL>,
+ <&ipu_conn CLK_IPU_CONN_IMG_ADL>;
+ clock-names = "audio", "audio1", "audio2",
+ "mfg", "mm", "cam",
+ "isp", "vpu", "vpu1",
+ "vpu2", "vpu3", "mm-0",
+ "mm-1", "mm-2", "mm-3",
+ "mm-4", "mm-5", "mm-6",
+ "mm-7", "mm-8", "mm-9",
+ "isp-0", "isp-1", "cam-0",
+ "cam-1", "cam-2", "cam-3",
+ "cam-4", "cam-5", "cam-6",
+ "vpu-0", "vpu-1", "vpu-2",
+ "vpu-3", "vpu-4", "vpu-5";
+ infracfg = <&infracfg>;
+ mediatek,smi = <&smi_common>;
+ };
+
watchdog: watchdog@10007000 {
compatible = "mediatek,mt8183-wdt",
"mediatek,mt6589-wdt";
@@ -658,6 +715,11 @@
#clock-cells = <1>;
};
+ smi_common: smi@14019000 {
+ compatible = "mediatek,mt8183-smi-common", "syscon";
+ reg = <0 0x14019000 0 0x1000>;
+ };
+
imgsys: syscon@15020000 {
compatible = "mediatek,mt8183-imgsys", "syscon";
reg = <0 0x15020000 0 0x1000>;
--
1.8.1.1.dirty
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply related
* [PATCH v15 08/11] soc: mediatek: Add MT8183 scpsys support
From: Weiyi Lu @ 2020-05-21 9:06 UTC (permalink / raw)
To: Enric Balletbo Serra, Matthias Brugger, Nicolas Boichat,
Rob Herring, Sascha Hauer
Cc: James Liao, Weiyi Lu, srv_heupstream, devicetree, linux-kernel,
Fan Chen, linux-mediatek, linux-arm-kernel
In-Reply-To: <1590051985-29149-1-git-send-email-weiyi.lu@mediatek.com>
Add scpsys driver for MT8183
Signed-off-by: Weiyi Lu <weiyi.lu@mediatek.com>
Reviewed-by: Nicolas Boichat <drinkcat@chromium.org>
---
drivers/soc/mediatek/mtk-scpsys.c | 249 ++++++++++++++++++++++++++++++++++++++
1 file changed, 249 insertions(+)
diff --git a/drivers/soc/mediatek/mtk-scpsys.c b/drivers/soc/mediatek/mtk-scpsys.c
index ef46e31..ae03127 100644
--- a/drivers/soc/mediatek/mtk-scpsys.c
+++ b/drivers/soc/mediatek/mtk-scpsys.c
@@ -19,6 +19,7 @@
#include <dt-bindings/power/mt7622-power.h>
#include <dt-bindings/power/mt7623a-power.h>
#include <dt-bindings/power/mt8173-power.h>
+#include <dt-bindings/power/mt8183-power.h>
#define MTK_POLL_DELAY_US 10
#define MTK_POLL_TIMEOUT USEC_PER_SEC
@@ -99,6 +100,34 @@
#define MT8173_TOP_AXI_PROT_EN_MFG_M1 BIT(22)
#define MT8173_TOP_AXI_PROT_EN_MFG_SNOOP_OUT BIT(23)
+#define MT8183_TOP_AXI_PROT_EN_DISP (BIT(10) | BIT(11))
+#define MT8183_TOP_AXI_PROT_EN_CONN (BIT(13) | BIT(14))
+#define MT8183_TOP_AXI_PROT_EN_MFG (BIT(21) | BIT(22))
+#define MT8183_TOP_AXI_PROT_EN_CAM BIT(28)
+#define MT8183_TOP_AXI_PROT_EN_VPU_TOP BIT(27)
+#define MT8183_TOP_AXI_PROT_EN_1_DISP (BIT(16) | BIT(17))
+#define MT8183_TOP_AXI_PROT_EN_1_MFG GENMASK(21, 19)
+#define MT8183_TOP_AXI_PROT_EN_MM_ISP (BIT(3) | BIT(8))
+#define MT8183_TOP_AXI_PROT_EN_MM_ISP_2ND BIT(10)
+#define MT8183_TOP_AXI_PROT_EN_MM_CAM (BIT(4) | BIT(5) | \
+ BIT(9) | BIT(13))
+#define MT8183_TOP_AXI_PROT_EN_MM_VPU_TOP (GENMASK(9, 6) | \
+ BIT(12))
+#define MT8183_TOP_AXI_PROT_EN_MM_VPU_TOP_2ND (BIT(10) | BIT(11))
+#define MT8183_TOP_AXI_PROT_EN_MM_CAM_2ND BIT(11)
+#define MT8183_TOP_AXI_PROT_EN_MCU_VPU_CORE0_2ND (BIT(0) | BIT(2) | \
+ BIT(4))
+#define MT8183_TOP_AXI_PROT_EN_MCU_VPU_CORE1_2ND (BIT(1) | BIT(3) | \
+ BIT(5))
+#define MT8183_TOP_AXI_PROT_EN_MCU_VPU_CORE0 BIT(6)
+#define MT8183_TOP_AXI_PROT_EN_MCU_VPU_CORE1 BIT(7)
+#define MT8183_SMI_COMMON_SMI_CLAMP_DISP GENMASK(7, 0)
+#define MT8183_SMI_COMMON_SMI_CLAMP_VENC BIT(1)
+#define MT8183_SMI_COMMON_SMI_CLAMP_ISP BIT(2)
+#define MT8183_SMI_COMMON_SMI_CLAMP_CAM (BIT(3) | BIT(4))
+#define MT8183_SMI_COMMON_SMI_CLAMP_VPU_TOP (BIT(5) | BIT(6))
+#define MT8183_SMI_COMMON_SMI_CLAMP_VDEC BIT(7)
+
#define MAX_CLKS 3
#define MAX_SUBSYS_CLKS 10
@@ -1190,6 +1219,212 @@ static void mtk_register_power_domains(struct platform_device *pdev,
{MT8173_POWER_DOMAIN_MFG_2D, MT8173_POWER_DOMAIN_MFG},
};
+/*
+ * MT8183 power domain support
+ */
+
+static const struct scp_domain_data scp_domain_data_mt8183[] = {
+ [MT8183_POWER_DOMAIN_AUDIO] = {
+ .name = "audio",
+ .sta_mask = PWR_STATUS_AUDIO,
+ .ctl_offs = 0x0314,
+ .sram_pdn_bits = GENMASK(11, 8),
+ .sram_pdn_ack_bits = GENMASK(15, 12),
+ .basic_clk_name = {"audio", "audio1", "audio2"},
+ },
+ [MT8183_POWER_DOMAIN_CONN] = {
+ .name = "conn",
+ .sta_mask = PWR_STATUS_CONN,
+ .ctl_offs = 0x032c,
+ .sram_pdn_bits = 0,
+ .sram_pdn_ack_bits = 0,
+ .bp_table = {
+ BUS_PROT(IFR_TYPE, 0x2a0, 0x2a4, 0, 0x228,
+ MT8183_TOP_AXI_PROT_EN_CONN),
+ },
+ },
+ [MT8183_POWER_DOMAIN_MFG_ASYNC] = {
+ .name = "mfg_async",
+ .sta_mask = PWR_STATUS_MFG_ASYNC,
+ .ctl_offs = 0x0334,
+ .sram_pdn_bits = 0,
+ .sram_pdn_ack_bits = 0,
+ .basic_clk_name = {"mfg"},
+ },
+ [MT8183_POWER_DOMAIN_MFG] = {
+ .name = "mfg",
+ .sta_mask = PWR_STATUS_MFG,
+ .ctl_offs = 0x0338,
+ .sram_pdn_bits = GENMASK(8, 8),
+ .sram_pdn_ack_bits = GENMASK(12, 12),
+ },
+ [MT8183_POWER_DOMAIN_MFG_CORE0] = {
+ .name = "mfg_core0",
+ .sta_mask = BIT(7),
+ .ctl_offs = 0x034c,
+ .sram_pdn_bits = GENMASK(8, 8),
+ .sram_pdn_ack_bits = GENMASK(12, 12),
+ },
+ [MT8183_POWER_DOMAIN_MFG_CORE1] = {
+ .name = "mfg_core1",
+ .sta_mask = BIT(20),
+ .ctl_offs = 0x0310,
+ .sram_pdn_bits = GENMASK(8, 8),
+ .sram_pdn_ack_bits = GENMASK(12, 12),
+ },
+ [MT8183_POWER_DOMAIN_MFG_2D] = {
+ .name = "mfg_2d",
+ .sta_mask = PWR_STATUS_MFG_2D,
+ .ctl_offs = 0x0348,
+ .sram_pdn_bits = GENMASK(8, 8),
+ .sram_pdn_ack_bits = GENMASK(12, 12),
+ .bp_table = {
+ BUS_PROT(IFR_TYPE, 0x2a8, 0x2ac, 0, 0x258,
+ MT8183_TOP_AXI_PROT_EN_1_MFG),
+ BUS_PROT(IFR_TYPE, 0x2a0, 0x2a4, 0, 0x228,
+ MT8183_TOP_AXI_PROT_EN_MFG),
+ },
+ },
+ [MT8183_POWER_DOMAIN_DISP] = {
+ .name = "disp",
+ .sta_mask = PWR_STATUS_DISP,
+ .ctl_offs = 0x030c,
+ .sram_pdn_bits = GENMASK(8, 8),
+ .sram_pdn_ack_bits = GENMASK(12, 12),
+ .basic_clk_name = {"mm"},
+ .subsys_clk_prefix = "mm",
+ .bp_table = {
+ BUS_PROT(IFR_TYPE, 0x2a8, 0x2ac, 0, 0x258,
+ MT8183_TOP_AXI_PROT_EN_1_DISP),
+ BUS_PROT(IFR_TYPE, 0x2a0, 0x2a4, 0, 0x228,
+ MT8183_TOP_AXI_PROT_EN_DISP),
+ BUS_PROT(SMI_TYPE, 0x3c4, 0x3c8, 0, 0x3c0,
+ MT8183_SMI_COMMON_SMI_CLAMP_DISP),
+ },
+ },
+ [MT8183_POWER_DOMAIN_CAM] = {
+ .name = "cam",
+ .sta_mask = BIT(25),
+ .ctl_offs = 0x0344,
+ .sram_pdn_bits = GENMASK(9, 8),
+ .sram_pdn_ack_bits = GENMASK(13, 12),
+ .basic_clk_name = {"cam"},
+ .subsys_clk_prefix = "cam",
+ .bp_table = {
+ BUS_PROT(IFR_TYPE, 0x2d4, 0x2d8, 0, 0x2ec,
+ MT8183_TOP_AXI_PROT_EN_MM_CAM),
+ BUS_PROT(IFR_TYPE, 0x2a0, 0x2a4, 0, 0x228,
+ MT8183_TOP_AXI_PROT_EN_CAM),
+ BUS_PROT_IGN(IFR_TYPE, 0x2d4, 0x2d8, 0, 0x2ec,
+ MT8183_TOP_AXI_PROT_EN_MM_CAM_2ND),
+ BUS_PROT(SMI_TYPE, 0x3c4, 0x3c8, 0, 0x3c0,
+ MT8183_SMI_COMMON_SMI_CLAMP_CAM),
+ },
+ },
+ [MT8183_POWER_DOMAIN_ISP] = {
+ .name = "isp",
+ .sta_mask = PWR_STATUS_ISP,
+ .ctl_offs = 0x0308,
+ .sram_pdn_bits = GENMASK(9, 8),
+ .sram_pdn_ack_bits = GENMASK(13, 12),
+ .basic_clk_name = {"isp"},
+ .subsys_clk_prefix = "isp",
+ .bp_table = {
+ BUS_PROT(IFR_TYPE, 0x2d4, 0x2d8, 0, 0x2ec,
+ MT8183_TOP_AXI_PROT_EN_MM_ISP),
+ BUS_PROT_IGN(IFR_TYPE, 0x2d4, 0x2d8, 0, 0x2ec,
+ MT8183_TOP_AXI_PROT_EN_MM_ISP_2ND),
+ BUS_PROT(SMI_TYPE, 0x3c4, 0x3c8, 0, 0x3c0,
+ MT8183_SMI_COMMON_SMI_CLAMP_ISP),
+ },
+ },
+ [MT8183_POWER_DOMAIN_VDEC] = {
+ .name = "vdec",
+ .sta_mask = BIT(31),
+ .ctl_offs = 0x0300,
+ .sram_pdn_bits = GENMASK(8, 8),
+ .sram_pdn_ack_bits = GENMASK(12, 12),
+ .bp_table = {
+ BUS_PROT(SMI_TYPE, 0x3c4, 0x3c8, 0, 0x3c0,
+ MT8183_SMI_COMMON_SMI_CLAMP_VDEC),
+ },
+ },
+ [MT8183_POWER_DOMAIN_VENC] = {
+ .name = "venc",
+ .sta_mask = PWR_STATUS_VENC,
+ .ctl_offs = 0x0304,
+ .sram_pdn_bits = GENMASK(11, 8),
+ .sram_pdn_ack_bits = GENMASK(15, 12),
+ .bp_table = {
+ BUS_PROT(SMI_TYPE, 0x3c4, 0x3c8, 0, 0x3c0,
+ MT8183_SMI_COMMON_SMI_CLAMP_VENC),
+ },
+ },
+ [MT8183_POWER_DOMAIN_VPU_TOP] = {
+ .name = "vpu_top",
+ .sta_mask = BIT(26),
+ .ctl_offs = 0x0324,
+ .sram_pdn_bits = GENMASK(8, 8),
+ .sram_pdn_ack_bits = GENMASK(12, 12),
+ .basic_clk_name = {"vpu", "vpu1"},
+ .subsys_clk_prefix = "vpu",
+ .bp_table = {
+ BUS_PROT(IFR_TYPE, 0x2d4, 0x2d8, 0, 0x2ec,
+ MT8183_TOP_AXI_PROT_EN_MM_VPU_TOP),
+ BUS_PROT(IFR_TYPE, 0x2a0, 0x2a4, 0, 0x228,
+ MT8183_TOP_AXI_PROT_EN_VPU_TOP),
+ BUS_PROT(IFR_TYPE, 0x2d4, 0x2d8, 0, 0x2ec,
+ MT8183_TOP_AXI_PROT_EN_MM_VPU_TOP_2ND),
+ BUS_PROT(SMI_TYPE, 0x3c4, 0x3c8, 0, 0x3c0,
+ MT8183_SMI_COMMON_SMI_CLAMP_VPU_TOP),
+ },
+ },
+ [MT8183_POWER_DOMAIN_VPU_CORE0] = {
+ .name = "vpu_core0",
+ .sta_mask = BIT(27),
+ .ctl_offs = 0x33c,
+ .sram_pdn_bits = GENMASK(11, 8),
+ .sram_pdn_ack_bits = GENMASK(13, 12),
+ .basic_clk_name = {"vpu2"},
+ .bp_table = {
+ BUS_PROT(IFR_TYPE, 0x2c4, 0x2c8, 0, 0x2e4,
+ MT8183_TOP_AXI_PROT_EN_MCU_VPU_CORE0),
+ BUS_PROT(IFR_TYPE, 0x2c4, 0x2c8, 0, 0x2e4,
+ MT8183_TOP_AXI_PROT_EN_MCU_VPU_CORE0_2ND),
+ },
+ .caps = MTK_SCPD_SRAM_ISO,
+ },
+ [MT8183_POWER_DOMAIN_VPU_CORE1] = {
+ .name = "vpu_core1",
+ .sta_mask = BIT(28),
+ .ctl_offs = 0x0340,
+ .sram_pdn_bits = GENMASK(11, 8),
+ .sram_pdn_ack_bits = GENMASK(13, 12),
+ .basic_clk_name = {"vpu3"},
+ .bp_table = {
+ BUS_PROT(IFR_TYPE, 0x2c4, 0x2c8, 0, 0x2e4,
+ MT8183_TOP_AXI_PROT_EN_MCU_VPU_CORE1),
+ BUS_PROT(IFR_TYPE, 0x2c4, 0x2c8, 0, 0x2e4,
+ MT8183_TOP_AXI_PROT_EN_MCU_VPU_CORE1_2ND),
+ },
+ .caps = MTK_SCPD_SRAM_ISO,
+ },
+};
+
+static const struct scp_subdomain scp_subdomain_mt8183[] = {
+ {MT8183_POWER_DOMAIN_MFG_ASYNC, MT8183_POWER_DOMAIN_MFG},
+ {MT8183_POWER_DOMAIN_MFG, MT8183_POWER_DOMAIN_MFG_2D},
+ {MT8183_POWER_DOMAIN_MFG, MT8183_POWER_DOMAIN_MFG_CORE0},
+ {MT8183_POWER_DOMAIN_MFG, MT8183_POWER_DOMAIN_MFG_CORE1},
+ {MT8183_POWER_DOMAIN_DISP, MT8183_POWER_DOMAIN_CAM},
+ {MT8183_POWER_DOMAIN_DISP, MT8183_POWER_DOMAIN_ISP},
+ {MT8183_POWER_DOMAIN_DISP, MT8183_POWER_DOMAIN_VDEC},
+ {MT8183_POWER_DOMAIN_DISP, MT8183_POWER_DOMAIN_VENC},
+ {MT8183_POWER_DOMAIN_DISP, MT8183_POWER_DOMAIN_VPU_TOP},
+ {MT8183_POWER_DOMAIN_VPU_TOP, MT8183_POWER_DOMAIN_VPU_CORE0},
+ {MT8183_POWER_DOMAIN_VPU_TOP, MT8183_POWER_DOMAIN_VPU_CORE1},
+};
+
static const struct scp_soc_data mt2701_data = {
.domains = scp_domain_data_mt2701,
.num_domains = ARRAY_SIZE(scp_domain_data_mt2701),
@@ -1250,6 +1485,17 @@ static void mtk_register_power_domains(struct platform_device *pdev,
},
};
+static const struct scp_soc_data mt8183_data = {
+ .domains = scp_domain_data_mt8183,
+ .num_domains = ARRAY_SIZE(scp_domain_data_mt8183),
+ .subdomains = scp_subdomain_mt8183,
+ .num_subdomains = ARRAY_SIZE(scp_subdomain_mt8183),
+ .regs = {
+ .pwr_sta_offs = 0x0180,
+ .pwr_sta2nd_offs = 0x0184
+ }
+};
+
/*
* scpsys driver init
*/
@@ -1274,6 +1520,9 @@ static void mtk_register_power_domains(struct platform_device *pdev,
.compatible = "mediatek,mt8173-scpsys",
.data = &mt8173_data,
}, {
+ .compatible = "mediatek,mt8183-scpsys",
+ .data = &mt8183_data,
+ }, {
/* sentinel */
}
};
--
1.8.1.1.dirty
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply related
* [PATCH v15 07/11] soc: mediatek: Add extra sram control
From: Weiyi Lu @ 2020-05-21 9:06 UTC (permalink / raw)
To: Enric Balletbo Serra, Matthias Brugger, Nicolas Boichat,
Rob Herring, Sascha Hauer
Cc: James Liao, Weiyi Lu, srv_heupstream, devicetree, linux-kernel,
Fan Chen, linux-mediatek, linux-arm-kernel
In-Reply-To: <1590051985-29149-1-git-send-email-weiyi.lu@mediatek.com>
For some power domains like vpu_core on MT8183 whose sram need to
do clock and internal isolation while power on/off sram.
We add a cap "MTK_SCPD_SRAM_ISO" to judge if we need to do
the extra sram isolation control or not.
Signed-off-by: Weiyi Lu <weiyi.lu@mediatek.com>
Reviewed-by: Nicolas Boichat <drinkcat@chromium.org>
---
drivers/soc/mediatek/mtk-scpsys.c | 22 ++++++++++++++++++++--
1 file changed, 20 insertions(+), 2 deletions(-)
diff --git a/drivers/soc/mediatek/mtk-scpsys.c b/drivers/soc/mediatek/mtk-scpsys.c
index ef2c668..ef46e31 100644
--- a/drivers/soc/mediatek/mtk-scpsys.c
+++ b/drivers/soc/mediatek/mtk-scpsys.c
@@ -25,6 +25,7 @@
#define MTK_SCPD_ACTIVE_WAKEUP BIT(0)
#define MTK_SCPD_FWAIT_SRAM BIT(1)
+#define MTK_SCPD_SRAM_ISO BIT(2)
#define MTK_SCPD_CAPS(_scpd, _x) ((_scpd)->data->caps & (_x))
#define SPM_VDE_PWR_CON 0x0210
@@ -56,6 +57,8 @@
#define PWR_ON_BIT BIT(2)
#define PWR_ON_2ND_BIT BIT(3)
#define PWR_CLK_DIS_BIT BIT(4)
+#define PWR_SRAM_CLKISO_BIT BIT(5)
+#define PWR_SRAM_ISOINT_B_BIT BIT(6)
#define PWR_STATUS_CONN BIT(1)
#define PWR_STATUS_DISP BIT(3)
@@ -290,6 +293,14 @@ static int scpsys_sram_enable(struct scp_domain *scpd, void __iomem *ctl_addr)
return ret;
}
+ if (MTK_SCPD_CAPS(scpd, MTK_SCPD_SRAM_ISO)) {
+ val = readl(ctl_addr) | PWR_SRAM_ISOINT_B_BIT;
+ writel(val, ctl_addr);
+ udelay(1);
+ val &= ~PWR_SRAM_CLKISO_BIT;
+ writel(val, ctl_addr);
+ }
+
return 0;
}
@@ -299,8 +310,15 @@ static int scpsys_sram_disable(struct scp_domain *scpd, void __iomem *ctl_addr)
u32 pdn_ack = scpd->data->sram_pdn_ack_bits;
int tmp;
- val = readl(ctl_addr);
- val |= scpd->data->sram_pdn_bits;
+ if (MTK_SCPD_CAPS(scpd, MTK_SCPD_SRAM_ISO)) {
+ val = readl(ctl_addr) | PWR_SRAM_CLKISO_BIT;
+ writel(val, ctl_addr);
+ val &= ~PWR_SRAM_ISOINT_B_BIT;
+ writel(val, ctl_addr);
+ udelay(1);
+ }
+
+ val = readl(ctl_addr) | scpd->data->sram_pdn_bits;
writel(val, ctl_addr);
/* Either wait until SRAM_PDN_ACK all 1 or 0 */
--
1.8.1.1.dirty
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply related
* [PATCH v15 01/11] dt-bindings: mediatek: Add property to mt8183 smi-common
From: Weiyi Lu @ 2020-05-21 9:06 UTC (permalink / raw)
To: Enric Balletbo Serra, Matthias Brugger, Nicolas Boichat,
Rob Herring, Sascha Hauer
Cc: James Liao, Weiyi Lu, srv_heupstream, devicetree, linux-kernel,
Fan Chen, linux-mediatek, linux-arm-kernel
In-Reply-To: <1590051985-29149-1-git-send-email-weiyi.lu@mediatek.com>
For scpsys driver using regmap based syscon driver API.
Signed-off-by: Weiyi Lu <weiyi.lu@mediatek.com>
---
.../devicetree/bindings/memory-controllers/mediatek,smi-common.txt | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/Documentation/devicetree/bindings/memory-controllers/mediatek,smi-common.txt b/Documentation/devicetree/bindings/memory-controllers/mediatek,smi-common.txt
index b478ade..01744ec 100644
--- a/Documentation/devicetree/bindings/memory-controllers/mediatek,smi-common.txt
+++ b/Documentation/devicetree/bindings/memory-controllers/mediatek,smi-common.txt
@@ -20,7 +20,7 @@ Required properties:
"mediatek,mt2712-smi-common"
"mediatek,mt7623-smi-common", "mediatek,mt2701-smi-common"
"mediatek,mt8173-smi-common"
- "mediatek,mt8183-smi-common"
+ "mediatek,mt8183-smi-common", "syscon"
- reg : the register and size of the SMI block.
- power-domains : a phandle to the power domain of this local arbiter.
- clocks : Must contain an entry for each entry in clock-names.
--
1.8.1.1.dirty
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply related
* [PATCH v15 11/11] arm64: dts: Add power-domains property to mfgcfg
From: Weiyi Lu @ 2020-05-21 9:06 UTC (permalink / raw)
To: Enric Balletbo Serra, Matthias Brugger, Nicolas Boichat,
Rob Herring, Sascha Hauer
Cc: James Liao, Weiyi Lu, srv_heupstream, devicetree, linux-kernel,
Fan Chen, linux-mediatek, linux-arm-kernel
In-Reply-To: <1590051985-29149-1-git-send-email-weiyi.lu@mediatek.com>
mfgcfg clock is under MFG_ASYNC power domain
Signed-off-by: Weiyi Lu <weiyi.lu@mediatek.com>
---
arch/arm64/boot/dts/mediatek/mt8183.dtsi | 1 +
1 file changed, 1 insertion(+)
diff --git a/arch/arm64/boot/dts/mediatek/mt8183.dtsi b/arch/arm64/boot/dts/mediatek/mt8183.dtsi
index ff7fe0c..911f0db 100644
--- a/arch/arm64/boot/dts/mediatek/mt8183.dtsi
+++ b/arch/arm64/boot/dts/mediatek/mt8183.dtsi
@@ -707,6 +707,7 @@
compatible = "mediatek,mt8183-mfgcfg", "syscon";
reg = <0 0x13000000 0 0x1000>;
#clock-cells = <1>;
+ power-domains = <&scpsys MT8183_POWER_DOMAIN_MFG_ASYNC>;
};
mmsys: syscon@14000000 {
--
1.8.1.1.dirty
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply related
* Re: [PATCH v4 0/7] firmware: smccc: Add basic SMCCC v1.2 + ARCH_SOC_ID support
From: Sudeep Holla @ 2020-05-21 9:15 UTC (permalink / raw)
To: Arnd Bergmann
Cc: Mark Rutland, Lorenzo Pieralisi, Catalin Marinas,
linux-kernel@vger.kernel.org, Steven Price, harb, Will Deacon,
Linux ARM
In-Reply-To: <CAK8P3a3dV0B26XE3oFQGTFf8EWV0AHoLudNtpSSB_t+pCfkOkQ@mail.gmail.com>
On Thu, May 21, 2020 at 11:06:23AM +0200, Arnd Bergmann wrote:
> On Thu, May 21, 2020 at 10:11 AM Sudeep Holla <sudeep.holla@arm.com> wrote:
> > On Thu, May 21, 2020 at 08:57:56AM +0100, Will Deacon wrote:
> > > On Thu, May 21, 2020 at 09:34:10AM +0200, Arnd Bergmann wrote:
> > > > On Thu, May 21, 2020 at 9:07 AM Sudeep Holla <sudeep.holla@arm.com> wrote:
> > > > > On Wed, May 20, 2020 at 11:54:16PM +0200, Arnd Bergmann wrote:
> > > > > > On Wed, May 20, 2020 at 11:29 PM Will Deacon <will@kernel.org> wrote:
> > > > > > > Applied to arm64 (for-next/smccc), thanks!
> > > > > > >
> > > > > > > Arnd -- Sudeep's reply to you about the sysfs groups seemed reasonable to me,
> > > > > > > but please shout if you'd rather I dropped this in order to pursue an
> > > > > > > alternative approach.
> > > > > >
> > > > > > I missed the reply earlier, thanks for pointing me to it again.
> > >
> > > D'oh, I took your silence as "no objections". Oh well!
> > >
> > > > > > I'm not entirely convinced, but don't revert it for now because of that,
> > > > > > I assume we can find a solution.
> > >
> > > Ok, cheers. It's on a separate branch so it's easy enough to drop if
> > > necessary (i.e. no reverts needed). Sudeep -- please send any extra patches
> > > on top of the branch.
> > >
> >
> > Indeed, it is also last patch in the series. However if Arnd is happy
> > with the sysfs names, we can move to generic code later without breaking
> > anything.
> >
> > We need not revert or drop it now. I will leave that to you or Arnd to
> > decide. Just that it may be too late to get acks for all the soc sysfs
> > drivers in time for v5.8
> >
> > I am fine if you want to drop the last patch.
>
> Ok, let's drop that patch then and make sure we do something that
> everyone is happy with later on. I'm already in favor of adding
> a more reliable soc_device instance based on this, but we need to
> be sure we don't screw up the contents of the attributes when we
> can't change them later.
>
Sure. Will, please drop the last patch in the series. I will rework
moving the custom attributes to the core.
> > > > >> drivers/firmware/smccc/smccc.c:14:13: warning: no previous prototype for function 'arm_smccc_version_init' [-Wmissing-prototypes]
> > > > void __init arm_smccc_version_init(u32 version, enum arm_smccc_conduit conduit)
> > > > ^
> > > > drivers/firmware/smccc/smccc.c:14:1: note: declare 'static' if the
> > > > function is not intended to be used outside of this translation unit
> > > > void __init arm_smccc_version_init(u32 version, enum arm_smccc_conduit conduit)
> > >
> > > I saw that when I applied the patches, but since the function is called from
> > > another compilation unit (psci/psci.o), I just ignored it as we have loads
> > > of these already and it only screams if you build with W=1.
> > >
> >
> > /me confused. Do you need the fix for this warning or you are happy to ignore?
>
> I want a fix for that, as I hope we can eventually turn this warning on by
> default and stop playing whack-a-mole when they come up. Most of these
> warnings are harmless, but occasionally the prototypes don't match exactly
> and cause real bugs depending on the configuration, and ensuring both
> sides include a common header file is an easy way to make it work
> more reliably.
>
Agreed.
> Note that the warning should come up for either W=1 or C=1, and I also
> think that new code should generally be written sparse-clean and have
> no warnings with 'make C=1' as a rule.
>
Sure, I am facing issues with clang-8, it fails to build arm_smccc_1_1_invoke
which I think Nick was mentioning in some other thread. I will try latest
clang.
--
Regards,
Sudeep
_______________________________________________
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 v5 09/19] mtd: spi-nor: sfdp: parse xSPI Profile 1.0 table
From: Pratyush Yadav @ 2020-05-21 9:14 UTC (permalink / raw)
To: masonccyang
Cc: Alexandre Belloni, Vignesh Raghavendra, Tudor Ambarus, juliensu,
Richard Weinberger, Mark Brown, Sekhar Nori, linux-kernel,
linux-spi, Ludovic Desroches, Boris Brezillon, linux-mediatek,
Miquel Raynal, Matthias Brugger, linux-mtd, linux-arm-kernel
In-Reply-To: <OFF5A6BA99.395182B5-ON4825856F.002B2F98-4825856F.002CD973@mxic.com.tw>
On 21/05/20 04:09PM, masonccyang@mxic.com.tw wrote:
>
> Hi Pratyush,
>
> > > > > > + /* Get 8D-8D-8D fast read opcode and dummy cycles. */
> > > > > > + opcode = FIELD_GET(PROFILE1_DWORD1_RD_FAST_CMD, table[0]);
> > > > > > +
> > > > > > + /*
> > > > > > + * Update the fast read settings. We set the default dummy
> > > cycles to
> > > > > 20
> > > > > > + * here. Flashes can change this value if they need to when
> > > enabling
> > > > > > + * octal mode.
> > > > > > + */
> > > > > > +
> spi_nor_set_read_settings(¶ms->reads[SNOR_CMD_READ_8_8_8_DTR],
> > > > > > + 0, 20, opcode,
> > > > > > + SNOR_PROTO_8_8_8_DTR);
> > > > > > +
> > > > >
> > > > >
> > > > > I thought we have a agreement that only do parse here, no other
> read
> > > > > parameters setting.
> > > >
> > > > Yes, and I considered it. But it didn't make much sense to me to
> > > > introduce an extra member in struct spi_nor just to make this call
> in
> > > > some other function later.
> > > >
> > > > Why exactly do you think doing this here is bad? The way I see it,
> we
> > > > avoid carrying around an extra member in spi_nor and this also
> allows
> > > > flashes to change the read settings easily in a post-sfdp hook. The
> > > > 4bait parsing function does something similar.
> > >
> > > I think it's not a question for good or bad.
> > >
> > > 4bait parsing function parse the 4-Byte Address Instruction Table
> > > and set up read/pp parameters there for sure.
> > >
> > > Here we give the function name spi_nor_parse_profile1() but also
> >
> > But the function that parses 4bait table is also called
> > spi_nor_parse_4bait().
> >
> > > do others setting that has nothing to do with it,
> >
> > Why has setting read opcode and dummy cycles got nothing to do with it?
> > The purpose of the Profile 1.0 table is to tell us the Read Fast
> > command and dummy cycles, among other things. I think it _does_ have
> > something to do with it.
>
> As you know I mean this function just do parse parameter of profile 1
> table
> and keep these value data for later usage.
>
> A device supports xSPI profile table could work in either 8S-8S-8S or
> 8D-8D-8D mode.
> It seems to setup these parameters somewhere out here is betters.
As far as I know, the Profile 1.0 table only describes 8D-8D-8D mode. I
see no mention of 8S-8S-8S in JESD251 or JESD216D.01. No field in the
table describes anything related to 8S. In fact, searching for "8S" in
the JESD251 spec yields 0 results.
Anyway, you should set up 8S parameters in SNOR_CMD_READ_8_8_8, not
SNOR_CMD_READ_8_8_8_DTR. 8D configuration is independent of 8S
configuration.
PS: If you have any more comments, please send them now. The merge
window is getting close, and I'd like to see this make it in.
--
Regards,
Pratyush Yadav
Texas Instruments India
_______________________________________________
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 20/91] clk: bcm: rpi: Discover the firmware clocks
From: Nicolas Saenz Julienne @ 2020-05-21 9:13 UTC (permalink / raw)
To: Maxime Ripard
Cc: Tim Gover, Dave Stevenson, Stephen Boyd, Michael Turquette,
linux-kernel, dri-devel, Phil Elwell, Eric Anholt,
bcm-kernel-feedback-list, linux-rpi-kernel, linux-clk,
linux-arm-kernel
In-Reply-To: <20200515081914.lejcqqwezn3zwpft@gilmour.lan>
[-- Attachment #1.1: Type: text/plain, Size: 3581 bytes --]
Hi Maxime,
On Fri, 2020-05-15 at 10:19 +0200, Maxime Ripard wrote:
> Hi Nicolas,
>
> On Mon, May 04, 2020 at 02:05:47PM +0200, Nicolas Saenz Julienne wrote:
> > Hi Maxime, as always, thanks for the series!
> > Some extra context, and comments below.
> >
> > On Fri, 2020-04-24 at 17:34 +0200, Maxime Ripard wrote:
> > > The RaspberryPi4 firmware actually exposes more clocks than are currently
> > > handled by the driver and we will need to change some of them directly
> > > based on the pixel rate for the display related clocks, or the load for
> > > the
> > > GPU.
> > >
> > > This rate change can have a number of side-effects, including adjusting
> > > the
> > > various PLL voltages or the PLL parents. The firmware will also update
> > > those clocks by itself for example if the SoC runs too hot.
> >
> > To complete this:
> >
> > RPi4's firmware implements DVFS. Clock frequency and SoC voltage are
> > correlated, if you can determine all clocks are running below a maximum then
> > it
> > should be safe to lower the voltage. Currently, firmware actively monitors
> > arm,
> > core, h264, v3d, isp and hevc to determine what voltage can be reduced to,
> > and
> > if arm increases any of those clocks behind the firmware's back, when it has
> > a
> > lowered voltage, a crash is highly likely.
> >
> > As pointed out to me by RPi foundation engineers hsm/pixel aren't currently
> > being monitored, as driving a high resolution display also requires a high
> > core
> > clock, which already sets an acceptable min voltage threshold. But that
> > might
> > change if needed.
> >
> > Ultimately, from the DVFS, the safe way to change clocks from arm would be
> > to
> > always use the firmware interface, which we're far from doing right now. On
> > the
> > other hand, AFAIK not all clocks have a firmware counterpart.
> >
> > Note that we could also have a word with the RPi foundation and see if
> > disabling DVFS is possible (AFAIK it's not an option right now). Although I
> > personally prefer to support this upstream, aside from the obvious benefits
> > to
> > battery powered use cases, not consuming power unnecessarily is always big
> > plus.
> >
> > > In order to make Linux play as nice as possible with those constraints, it
> > > makes sense to rely on the firmware clocks as much as possible.
> >
> > As I comment above, not as simple as it seems. I suggest, for now, we only
> > register the clocks we're going to use and that are likely to be affected by
> > DVFS. hsm being a contender here.
> >
> > As we'd be settling on a hybrid solution here, which isn't ideal to say the
> > least, I'd like to gather some opinions on whether pushing towards a fully
> > firmware based solution is something you'd like to see.
>
> Thanks for the summary above, I'll try to adjust that commit log to reflect
> this. As for my opinion, I don't really think that an hybrid approach is
> practical, since that would leave us with weird interactions between the
> firmware (and possibly multiple versinos of it) and the linux driver, and this
> would be pretty hard to maintain in the long run.
>
> That leaves us either the MMIO-based driver or the firmware-based one, and
> here
> with what you said above, at the moment, the firmware based one is a clear
> winner.
We're on the same page here :)
My remaining concern is the fact there isn't a firmware counterpart to every
clock used right now. But it's something we can work out in the future.
Regards,
Nicolas
[-- Attachment #1.2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 488 bytes --]
[-- Attachment #2: Type: text/plain, Size: 176 bytes --]
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* [PATCH v15 05/11] soc: mediatek: Add multiple step bus protection control
From: Weiyi Lu @ 2020-05-21 9:06 UTC (permalink / raw)
To: Enric Balletbo Serra, Matthias Brugger, Nicolas Boichat,
Rob Herring, Sascha Hauer
Cc: James Liao, Weiyi Lu, srv_heupstream, devicetree, linux-kernel,
Fan Chen, linux-mediatek, linux-arm-kernel
In-Reply-To: <1590051985-29149-1-git-send-email-weiyi.lu@mediatek.com>
Both MT8183 & MT6765 have more control steps of bus protection
than previous project. And there add more bus protection registers
reside at infracfg & smi-common.
Extend function to support multiple step bus protection control
with more customized arguments.
And then use bp_table for bus protection of all compatibles,
instead of mixing bus_prot_mask and bus_prot_reg_update.
Signed-off-by: Weiyi Lu <weiyi.lu@mediatek.com>
---
drivers/soc/mediatek/mtk-scpsys.c | 235 +++++++++++++++++++++++++++-----------
1 file changed, 168 insertions(+), 67 deletions(-)
diff --git a/drivers/soc/mediatek/mtk-scpsys.c b/drivers/soc/mediatek/mtk-scpsys.c
index b603af7..59a525a 100644
--- a/drivers/soc/mediatek/mtk-scpsys.c
+++ b/drivers/soc/mediatek/mtk-scpsys.c
@@ -78,11 +78,6 @@
#define PWR_STATUS_HIF1 BIT(26) /* MT7622 */
#define PWR_STATUS_WB BIT(27) /* MT7622 */
-#define INFRA_TOPAXI_PROTECTEN 0x0220
-#define INFRA_TOPAXI_PROTECTSTA1 0x0228
-#define INFRA_TOPAXI_PROTECTEN_SET 0x0260
-#define INFRA_TOPAXI_PROTECTEN_CLR 0x0264
-
#define MT2701_TOP_AXI_PROT_EN_MM_M0 BIT(1)
#define MT2701_TOP_AXI_PROT_EN_CONN_M BIT(2)
#define MT2701_TOP_AXI_PROT_EN_CONN_S BIT(8)
@@ -103,6 +98,45 @@
#define MAX_CLKS 3
+#define MAX_STEPS 4
+
+#define _BUS_PROT(_type, _set_ofs, _clr_ofs, \
+ _en_ofs, _sta_ofs, _mask, _ignore_clr_ack) { \
+ .type = _type, \
+ .set_ofs = _set_ofs, \
+ .clr_ofs = _clr_ofs, \
+ .en_ofs = _en_ofs, \
+ .sta_ofs = _sta_ofs, \
+ .mask = _mask, \
+ .ignore_clr_ack = _ignore_clr_ack, \
+ }
+
+#define BUS_PROT(_type, _set_ofs, _clr_ofs, \
+ _en_ofs, _sta_ofs, _mask) \
+ _BUS_PROT(_type, _set_ofs, _clr_ofs, \
+ _en_ofs, _sta_ofs, _mask, false)
+
+#define BUS_PROT_IGN(_type, _set_ofs, _clr_ofs, \
+ _en_ofs, _sta_ofs, _mask) \
+ _BUS_PROT(_type, _set_ofs, _clr_ofs, \
+ _en_ofs, _sta_ofs, _mask, true)
+
+enum regmap_type {
+ INVALID_TYPE = 0,
+ IFR_TYPE,
+ SMI_TYPE,
+};
+
+struct bus_prot {
+ enum regmap_type type;
+ u32 set_ofs;
+ u32 clr_ofs;
+ u32 en_ofs;
+ u32 sta_ofs;
+ u32 mask;
+ bool ignore_clr_ack;
+};
+
/**
* struct scp_domain_data - scp domain data for power on/off flow
* @name: The domain name.
@@ -110,9 +144,9 @@
* @ctl_offs: The offset for main power control register.
* @sram_pdn_bits: The mask for sram power control bits.
* @sram_pdn_ack_bits: The mask for sram power control acked bits.
- * @bus_prot_mask: The mask for single step bus protection.
* @basic_clk_name: The basic clocks required by this power domain.
* @caps: The flag for active wake-up action.
+ * @bp_table: The mask table for multiple step bus protection.
*/
struct scp_domain_data {
const char *name;
@@ -120,9 +154,9 @@ struct scp_domain_data {
int ctl_offs;
u32 sram_pdn_bits;
u32 sram_pdn_ack_bits;
- u32 bus_prot_mask;
const char *basic_clk_name[MAX_CLKS];
u8 caps;
+ struct bus_prot bp_table[MAX_STEPS];
};
struct scp;
@@ -146,8 +180,8 @@ struct scp {
struct device *dev;
void __iomem *base;
struct regmap *infracfg;
+ struct regmap *smi_common;
struct scp_ctrl_reg ctrl_reg;
- bool bus_prot_reg_update;
};
struct scp_subdomain {
@@ -161,7 +195,6 @@ struct scp_soc_data {
const struct scp_subdomain *subdomains;
int num_subdomains;
const struct scp_ctrl_reg regs;
- bool bus_prot_reg_update;
};
static int scpsys_domain_is_on(struct scp_domain *scpd)
@@ -271,53 +304,87 @@ static int scpsys_sram_disable(struct scp_domain *scpd, void __iomem *ctl_addr)
MTK_POLL_DELAY_US, MTK_POLL_TIMEOUT);
}
+static int set_bus_protection(struct regmap *map, const struct bus_prot *bp)
+{
+ u32 val;
+
+ if (bp->set_ofs)
+ regmap_write(map, bp->set_ofs, bp->mask);
+ else
+ regmap_update_bits(map, bp->en_ofs, bp->mask, bp->mask);
+
+ return regmap_read_poll_timeout(map, bp->sta_ofs,
+ val, (val & bp->mask) == bp->mask,
+ MTK_POLL_DELAY_US, MTK_POLL_TIMEOUT);
+}
+
+static int clear_bus_protection(struct regmap *map, const struct bus_prot *bp)
+{
+ u32 val;
+
+ if (bp->clr_ofs)
+ regmap_write(map, bp->clr_ofs, bp->mask);
+ else
+ regmap_update_bits(map, bp->en_ofs, bp->mask, 0);
+
+ if (bp->ignore_clr_ack)
+ return 0;
+
+ return regmap_read_poll_timeout(map, bp->sta_ofs,
+ val, !(val & bp->mask),
+ MTK_POLL_DELAY_US, MTK_POLL_TIMEOUT);
+}
+
static int scpsys_bus_protect_enable(struct scp_domain *scpd)
{
struct scp *scp = scpd->scp;
+ const struct bus_prot *bp_table = scpd->data->bp_table;
struct regmap *infracfg = scp->infracfg;
- u32 mask = scpd->data->bus_prot_mask;
- bool reg_update = scp->bus_prot_reg_update;
- u32 val;
- int ret;
+ struct regmap *smi_common = scp->smi_common;
+ struct regmap *map;
+ int i, ret;
- if (!mask)
- return 0;
+ for (i = 0; i < MAX_STEPS; i++) {
+ if (bp_table[i].type == IFR_TYPE)
+ map = infracfg;
+ else if (bp_table[i].type == SMI_TYPE)
+ map = smi_common;
+ else
+ break;
- if (reg_update)
- regmap_update_bits(infracfg, INFRA_TOPAXI_PROTECTEN, mask,
- mask);
- else
- regmap_write(infracfg, INFRA_TOPAXI_PROTECTEN_SET, mask);
+ ret = set_bus_protection(map, &bp_table[i]);
- ret = regmap_read_poll_timeout(infracfg, INFRA_TOPAXI_PROTECTSTA1,
- val, (val & mask) == mask,
- MTK_POLL_DELAY_US, MTK_POLL_TIMEOUT);
+ if (ret)
+ return ret;
+ }
- return ret;
+ return 0;
}
static int scpsys_bus_protect_disable(struct scp_domain *scpd)
{
struct scp *scp = scpd->scp;
+ const struct bus_prot *bp_table = scpd->data->bp_table;
struct regmap *infracfg = scp->infracfg;
- u32 mask = scpd->data->bus_prot_mask;
- bool reg_update = scp->bus_prot_reg_update;
- u32 val;
- int ret;
+ struct regmap *smi_common = scp->smi_common;
+ struct regmap *map;
+ int i, ret;
- if (!mask)
- return 0;
+ for (i = MAX_STEPS - 1; i >= 0; i--) {
+ if (bp_table[i].type == IFR_TYPE)
+ map = infracfg;
+ else if (bp_table[i].type == SMI_TYPE)
+ map = smi_common;
+ else
+ continue;
- if (reg_update)
- regmap_update_bits(infracfg, INFRA_TOPAXI_PROTECTEN, mask, 0);
- else
- regmap_write(infracfg, INFRA_TOPAXI_PROTECTEN_CLR, mask);
+ ret = clear_bus_protection(map, &bp_table[i]);
- ret = regmap_read_poll_timeout(infracfg, INFRA_TOPAXI_PROTECTSTA1,
- val, !(val & mask),
- MTK_POLL_DELAY_US, MTK_POLL_TIMEOUT);
+ if (ret)
+ return ret;
+ }
- return ret;
+ return 0;
}
static int scpsys_power_on(struct generic_pm_domain *genpd)
@@ -448,8 +515,7 @@ static int init_basic_clks(struct platform_device *pdev, struct clk **clk,
static struct scp *init_scp(struct platform_device *pdev,
const struct scp_domain_data *scp_domain_data, int num,
- const struct scp_ctrl_reg *scp_ctrl_reg,
- bool bus_prot_reg_update)
+ const struct scp_ctrl_reg *scp_ctrl_reg)
{
struct genpd_onecell_data *pd_data;
struct resource *res;
@@ -463,8 +529,6 @@ static struct scp *init_scp(struct platform_device *pdev,
scp->ctrl_reg.pwr_sta_offs = scp_ctrl_reg->pwr_sta_offs;
scp->ctrl_reg.pwr_sta2nd_offs = scp_ctrl_reg->pwr_sta2nd_offs;
- scp->bus_prot_reg_update = bus_prot_reg_update;
-
scp->dev = &pdev->dev;
res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
@@ -492,6 +556,17 @@ static struct scp *init_scp(struct platform_device *pdev,
return ERR_CAST(scp->infracfg);
}
+ scp->smi_common = syscon_regmap_lookup_by_phandle(pdev->dev.of_node,
+ "mediatek,smi");
+
+ if (scp->smi_common == ERR_PTR(-ENODEV)) {
+ scp->smi_common = NULL;
+ } else if (IS_ERR(scp->smi_common)) {
+ dev_err(&pdev->dev, "Cannot find smi_common controller: %ld\n",
+ PTR_ERR(scp->smi_common));
+ return ERR_CAST(scp->smi_common);
+ }
+
for (i = 0; i < num; i++) {
struct scp_domain *scpd = &scp->domains[i];
const struct scp_domain_data *data = &scp_domain_data[i];
@@ -574,8 +649,11 @@ static void mtk_register_power_domains(struct platform_device *pdev,
.name = "conn",
.sta_mask = PWR_STATUS_CONN,
.ctl_offs = SPM_CONN_PWR_CON,
- .bus_prot_mask = MT2701_TOP_AXI_PROT_EN_CONN_M |
- MT2701_TOP_AXI_PROT_EN_CONN_S,
+ .bp_table = {
+ BUS_PROT(IFR_TYPE, 0, 0, 0x220, 0x228,
+ MT2701_TOP_AXI_PROT_EN_CONN_M |
+ MT2701_TOP_AXI_PROT_EN_CONN_S),
+ },
.caps = MTK_SCPD_ACTIVE_WAKEUP,
},
[MT2701_POWER_DOMAIN_DISP] = {
@@ -584,7 +662,10 @@ static void mtk_register_power_domains(struct platform_device *pdev,
.ctl_offs = SPM_DIS_PWR_CON,
.sram_pdn_bits = GENMASK(11, 8),
.basic_clk_name = {"mm"},
- .bus_prot_mask = MT2701_TOP_AXI_PROT_EN_MM_M0,
+ .bp_table = {
+ BUS_PROT(IFR_TYPE, 0, 0, 0x220, 0x228,
+ MT2701_TOP_AXI_PROT_EN_MM_M0),
+ },
.caps = MTK_SCPD_ACTIVE_WAKEUP,
},
[MT2701_POWER_DOMAIN_MFG] = {
@@ -719,7 +800,10 @@ static void mtk_register_power_domains(struct platform_device *pdev,
.sram_pdn_bits = GENMASK(8, 8),
.sram_pdn_ack_bits = GENMASK(16, 16),
.basic_clk_name = {"mfg"},
- .bus_prot_mask = BIT(14) | BIT(21) | BIT(23),
+ .bp_table = {
+ BUS_PROT(IFR_TYPE, 0x260, 0x264, 0x220, 0x228,
+ BIT(14) | BIT(21) | BIT(23)),
+ },
.caps = MTK_SCPD_ACTIVE_WAKEUP,
},
[MT2712_POWER_DOMAIN_MFG_SC1] = {
@@ -791,7 +875,10 @@ static void mtk_register_power_domains(struct platform_device *pdev,
.sram_pdn_bits = GENMASK(8, 8),
.sram_pdn_ack_bits = GENMASK(12, 12),
.basic_clk_name = {"mm"},
- .bus_prot_mask = (BIT(1) | BIT(2)),
+ .bp_table = {
+ BUS_PROT(IFR_TYPE, 0, 0, 0x220, 0x228,
+ BIT(1) | BIT(2)),
+ },
},
[MT6797_POWER_DOMAIN_AUDIO] = {
.name = "audio",
@@ -838,7 +925,10 @@ static void mtk_register_power_domains(struct platform_device *pdev,
.ctl_offs = SPM_ETHSYS_PWR_CON,
.sram_pdn_bits = GENMASK(11, 8),
.sram_pdn_ack_bits = GENMASK(15, 12),
- .bus_prot_mask = MT7622_TOP_AXI_PROT_EN_ETHSYS,
+ .bp_table = {
+ BUS_PROT(IFR_TYPE, 0, 0, 0x220, 0x228,
+ MT7622_TOP_AXI_PROT_EN_ETHSYS),
+ },
.caps = MTK_SCPD_ACTIVE_WAKEUP,
},
[MT7622_POWER_DOMAIN_HIF0] = {
@@ -848,7 +938,10 @@ static void mtk_register_power_domains(struct platform_device *pdev,
.sram_pdn_bits = GENMASK(11, 8),
.sram_pdn_ack_bits = GENMASK(15, 12),
.basic_clk_name = {"hif_sel"},
- .bus_prot_mask = MT7622_TOP_AXI_PROT_EN_HIF0,
+ .bp_table = {
+ BUS_PROT(IFR_TYPE, 0, 0, 0x220, 0x228,
+ MT7622_TOP_AXI_PROT_EN_HIF0),
+ },
.caps = MTK_SCPD_ACTIVE_WAKEUP,
},
[MT7622_POWER_DOMAIN_HIF1] = {
@@ -858,7 +951,10 @@ static void mtk_register_power_domains(struct platform_device *pdev,
.sram_pdn_bits = GENMASK(11, 8),
.sram_pdn_ack_bits = GENMASK(15, 12),
.basic_clk_name = {"hif_sel"},
- .bus_prot_mask = MT7622_TOP_AXI_PROT_EN_HIF1,
+ .bp_table = {
+ BUS_PROT(IFR_TYPE, 0, 0, 0x220, 0x228,
+ MT7622_TOP_AXI_PROT_EN_HIF1),
+ },
.caps = MTK_SCPD_ACTIVE_WAKEUP,
},
[MT7622_POWER_DOMAIN_WB] = {
@@ -867,7 +963,10 @@ static void mtk_register_power_domains(struct platform_device *pdev,
.ctl_offs = SPM_WB_PWR_CON,
.sram_pdn_bits = 0,
.sram_pdn_ack_bits = 0,
- .bus_prot_mask = MT7622_TOP_AXI_PROT_EN_WB,
+ .bp_table = {
+ BUS_PROT(IFR_TYPE, 0, 0, 0x220, 0x228,
+ MT7622_TOP_AXI_PROT_EN_WB),
+ },
.caps = MTK_SCPD_ACTIVE_WAKEUP | MTK_SCPD_FWAIT_SRAM,
},
};
@@ -881,8 +980,11 @@ static void mtk_register_power_domains(struct platform_device *pdev,
.name = "conn",
.sta_mask = PWR_STATUS_CONN,
.ctl_offs = SPM_CONN_PWR_CON,
- .bus_prot_mask = MT2701_TOP_AXI_PROT_EN_CONN_M |
- MT2701_TOP_AXI_PROT_EN_CONN_S,
+ .bp_table = {
+ BUS_PROT(IFR_TYPE, 0, 0, 0x220, 0x228,
+ MT2701_TOP_AXI_PROT_EN_CONN_M |
+ MT2701_TOP_AXI_PROT_EN_CONN_S),
+ },
.caps = MTK_SCPD_ACTIVE_WAKEUP,
},
[MT7623A_POWER_DOMAIN_ETH] = {
@@ -947,8 +1049,11 @@ static void mtk_register_power_domains(struct platform_device *pdev,
.sram_pdn_bits = GENMASK(11, 8),
.sram_pdn_ack_bits = GENMASK(12, 12),
.basic_clk_name = {"mm"},
- .bus_prot_mask = MT8173_TOP_AXI_PROT_EN_MM_M0 |
- MT8173_TOP_AXI_PROT_EN_MM_M1,
+ .bp_table = {
+ BUS_PROT(IFR_TYPE, 0, 0, 0x220, 0x228,
+ MT8173_TOP_AXI_PROT_EN_MM_M0 |
+ MT8173_TOP_AXI_PROT_EN_MM_M1),
+ },
},
[MT8173_POWER_DOMAIN_VENC_LT] = {
.name = "venc_lt",
@@ -994,10 +1099,13 @@ static void mtk_register_power_domains(struct platform_device *pdev,
.ctl_offs = SPM_MFG_PWR_CON,
.sram_pdn_bits = GENMASK(13, 8),
.sram_pdn_ack_bits = GENMASK(21, 16),
- .bus_prot_mask = MT8173_TOP_AXI_PROT_EN_MFG_S |
- MT8173_TOP_AXI_PROT_EN_MFG_M0 |
- MT8173_TOP_AXI_PROT_EN_MFG_M1 |
- MT8173_TOP_AXI_PROT_EN_MFG_SNOOP_OUT,
+ .bp_table = {
+ BUS_PROT(IFR_TYPE, 0, 0, 0x220, 0x228,
+ MT8173_TOP_AXI_PROT_EN_MFG_S |
+ MT8173_TOP_AXI_PROT_EN_MFG_M0 |
+ MT8173_TOP_AXI_PROT_EN_MFG_M1 |
+ MT8173_TOP_AXI_PROT_EN_MFG_SNOOP_OUT),
+ },
},
};
@@ -1013,7 +1121,6 @@ static void mtk_register_power_domains(struct platform_device *pdev,
.pwr_sta_offs = SPM_PWR_STATUS,
.pwr_sta2nd_offs = SPM_PWR_STATUS_2ND
},
- .bus_prot_reg_update = true,
};
static const struct scp_soc_data mt2712_data = {
@@ -1025,7 +1132,6 @@ static void mtk_register_power_domains(struct platform_device *pdev,
.pwr_sta_offs = SPM_PWR_STATUS,
.pwr_sta2nd_offs = SPM_PWR_STATUS_2ND
},
- .bus_prot_reg_update = false,
};
static const struct scp_soc_data mt6797_data = {
@@ -1037,7 +1143,6 @@ static void mtk_register_power_domains(struct platform_device *pdev,
.pwr_sta_offs = SPM_PWR_STATUS_MT6797,
.pwr_sta2nd_offs = SPM_PWR_STATUS_2ND_MT6797
},
- .bus_prot_reg_update = true,
};
static const struct scp_soc_data mt7622_data = {
@@ -1047,7 +1152,6 @@ static void mtk_register_power_domains(struct platform_device *pdev,
.pwr_sta_offs = SPM_PWR_STATUS,
.pwr_sta2nd_offs = SPM_PWR_STATUS_2ND
},
- .bus_prot_reg_update = true,
};
static const struct scp_soc_data mt7623a_data = {
@@ -1057,7 +1161,6 @@ static void mtk_register_power_domains(struct platform_device *pdev,
.pwr_sta_offs = SPM_PWR_STATUS,
.pwr_sta2nd_offs = SPM_PWR_STATUS_2ND
},
- .bus_prot_reg_update = true,
};
static const struct scp_soc_data mt8173_data = {
@@ -1069,7 +1172,6 @@ static void mtk_register_power_domains(struct platform_device *pdev,
.pwr_sta_offs = SPM_PWR_STATUS,
.pwr_sta2nd_offs = SPM_PWR_STATUS_2ND
},
- .bus_prot_reg_update = true,
};
/*
@@ -1110,8 +1212,7 @@ static int scpsys_probe(struct platform_device *pdev)
soc = of_device_get_match_data(&pdev->dev);
- scp = init_scp(pdev, soc->domains, soc->num_domains, &soc->regs,
- soc->bus_prot_reg_update);
+ scp = init_scp(pdev, soc->domains, soc->num_domains, &soc->regs);
if (IS_ERR(scp))
return PTR_ERR(scp);
--
1.8.1.1.dirty
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply related
* [PATCH v15 00/11] Mediatek MT8183 scpsys support
From: Weiyi Lu @ 2020-05-21 9:06 UTC (permalink / raw)
To: Enric Balletbo Serra, Matthias Brugger, Nicolas Boichat,
Rob Herring, Sascha Hauer
Cc: James Liao, Weiyi Lu, srv_heupstream, devicetree, linux-kernel,
Fan Chen, linux-mediatek, linux-arm-kernel
This series is based on v5.7-rc1
changes since v14:
- fix commit message typo
- use property name "mediatek,smi" for smi phandle
changes since v13:
- document optional property "smi-comm"
- move defines in scpsyc.h to mtk-scpsys.c directly
- minor coding sytle fixes
change since v12:
- separate the fix of comma at the end into a new patch [PATCH 09/11]
changes since v11:
- re-order patches "Remove infracfg misc driver support" and "Add multiple step bus protection"
- add cap MTK_SCPD_SRAM_ISO for extra sram control
- minor coding sytle fixes and reword commit messages
changes since v10:
- squash PATCH 04 and PATCH 06 in v9 into its previous patch
- add "ignore_clr_ack" for multiple step bus protection control to have a clean definition of power domain data
- keep the mask register bit definitions and do the same for MT8183
changes since v9:
- add new PATCH 04 and PATCH 06 to replace by new method for all compatibles
- add new PATCH 07 to remove infracfg misc driver
- minor coding sytle fix
changes since v7:
- reword in binding document [PATCH 02/14]
- fix error return checking bug in subsys clock control [PATCH 10/14]
- add power domains properity to mfgcfg patch [PATCH 14/14] from
https://patchwork.kernel.org/patch/11126199/
changes since v6:
- remove the patch of SPDX license identifier because it's already fixed
changes since v5:
- fix documentation in [PATCH 04/14]
- remove useless variable checking and reuse API of clock control in [PATCH 06/14]
- coding style fix of bus protection control in [PATCH 08/14]
- fix naming of new added data in [PATCH 09/14]
- small refactor of multiple step bus protection control in [PATCH 10/14]
changes since v4:
- add property to mt8183 smi-common
- seperate refactor patches and new add function
- add power controller device node
Weiyi Lu (11):
dt-bindings: mediatek: Add property to mt8183 smi-common
dt-bindings: soc: Add MT8183 power dt-bindings
soc: mediatek: Add basic_clk_name to scp_power_data
soc: mediatek: Remove infracfg misc driver support
soc: mediatek: Add multiple step bus protection control
soc: mediatek: Add subsys clock control for bus protection
soc: mediatek: Add extra sram control
soc: mediatek: Add MT8183 scpsys support
soc: mediatek: Add a comma at the end
arm64: dts: Add power controller device node of MT8183
arm64: dts: Add power-domains property to mfgcfg
.../mediatek,smi-common.txt | 2 +-
.../bindings/soc/mediatek/scpsys.txt | 21 +-
arch/arm64/boot/dts/mediatek/mt8183.dtsi | 63 ++
drivers/soc/mediatek/Kconfig | 10 -
drivers/soc/mediatek/Makefile | 1 -
drivers/soc/mediatek/mtk-infracfg.c | 79 --
drivers/soc/mediatek/mtk-scpsys.c | 706 ++++++++++++++----
include/dt-bindings/power/mt8183-power.h | 26 +
include/linux/soc/mediatek/infracfg.h | 39 -
9 files changed, 672 insertions(+), 275 deletions(-)
delete mode 100644 drivers/soc/mediatek/mtk-infracfg.c
create mode 100644 include/dt-bindings/power/mt8183-power.h
delete mode 100644 include/linux/soc/mediatek/infracfg.h
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* [PATCH v15 09/11] soc: mediatek: Add a comma at the end
From: Weiyi Lu @ 2020-05-21 9:06 UTC (permalink / raw)
To: Enric Balletbo Serra, Matthias Brugger, Nicolas Boichat,
Rob Herring, Sascha Hauer
Cc: James Liao, Weiyi Lu, srv_heupstream, devicetree, linux-kernel,
Fan Chen, linux-mediatek, linux-arm-kernel
In-Reply-To: <1590051985-29149-1-git-send-email-weiyi.lu@mediatek.com>
A minor coding style fix
Signed-off-by: Weiyi Lu <weiyi.lu@mediatek.com>
---
drivers/soc/mediatek/mtk-scpsys.c | 14 +++++++-------
1 file changed, 7 insertions(+), 7 deletions(-)
diff --git a/drivers/soc/mediatek/mtk-scpsys.c b/drivers/soc/mediatek/mtk-scpsys.c
index ae03127..1a43bbf 100644
--- a/drivers/soc/mediatek/mtk-scpsys.c
+++ b/drivers/soc/mediatek/mtk-scpsys.c
@@ -1430,7 +1430,7 @@ static void mtk_register_power_domains(struct platform_device *pdev,
.num_domains = ARRAY_SIZE(scp_domain_data_mt2701),
.regs = {
.pwr_sta_offs = SPM_PWR_STATUS,
- .pwr_sta2nd_offs = SPM_PWR_STATUS_2ND
+ .pwr_sta2nd_offs = SPM_PWR_STATUS_2ND,
},
};
@@ -1441,7 +1441,7 @@ static void mtk_register_power_domains(struct platform_device *pdev,
.num_subdomains = ARRAY_SIZE(scp_subdomain_mt2712),
.regs = {
.pwr_sta_offs = SPM_PWR_STATUS,
- .pwr_sta2nd_offs = SPM_PWR_STATUS_2ND
+ .pwr_sta2nd_offs = SPM_PWR_STATUS_2ND,
},
};
@@ -1452,7 +1452,7 @@ static void mtk_register_power_domains(struct platform_device *pdev,
.num_subdomains = ARRAY_SIZE(scp_subdomain_mt6797),
.regs = {
.pwr_sta_offs = SPM_PWR_STATUS_MT6797,
- .pwr_sta2nd_offs = SPM_PWR_STATUS_2ND_MT6797
+ .pwr_sta2nd_offs = SPM_PWR_STATUS_2ND_MT6797,
},
};
@@ -1461,7 +1461,7 @@ static void mtk_register_power_domains(struct platform_device *pdev,
.num_domains = ARRAY_SIZE(scp_domain_data_mt7622),
.regs = {
.pwr_sta_offs = SPM_PWR_STATUS,
- .pwr_sta2nd_offs = SPM_PWR_STATUS_2ND
+ .pwr_sta2nd_offs = SPM_PWR_STATUS_2ND,
},
};
@@ -1470,7 +1470,7 @@ static void mtk_register_power_domains(struct platform_device *pdev,
.num_domains = ARRAY_SIZE(scp_domain_data_mt7623a),
.regs = {
.pwr_sta_offs = SPM_PWR_STATUS,
- .pwr_sta2nd_offs = SPM_PWR_STATUS_2ND
+ .pwr_sta2nd_offs = SPM_PWR_STATUS_2ND,
},
};
@@ -1481,7 +1481,7 @@ static void mtk_register_power_domains(struct platform_device *pdev,
.num_subdomains = ARRAY_SIZE(scp_subdomain_mt8173),
.regs = {
.pwr_sta_offs = SPM_PWR_STATUS,
- .pwr_sta2nd_offs = SPM_PWR_STATUS_2ND
+ .pwr_sta2nd_offs = SPM_PWR_STATUS_2ND,
},
};
@@ -1492,7 +1492,7 @@ static void mtk_register_power_domains(struct platform_device *pdev,
.num_subdomains = ARRAY_SIZE(scp_subdomain_mt8183),
.regs = {
.pwr_sta_offs = 0x0180,
- .pwr_sta2nd_offs = 0x0184
+ .pwr_sta2nd_offs = 0x0184,
}
};
--
1.8.1.1.dirty
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply related
* Re: [PATCH v4 0/7] firmware: smccc: Add basic SMCCC v1.2 + ARCH_SOC_ID support
From: Arnd Bergmann @ 2020-05-21 9:06 UTC (permalink / raw)
To: Sudeep Holla
Cc: Mark Rutland, Lorenzo Pieralisi, Catalin Marinas,
linux-kernel@vger.kernel.org, Steven Price, harb, Will Deacon,
Linux ARM
In-Reply-To: <20200521081055.GD1131@bogus>
On Thu, May 21, 2020 at 10:11 AM Sudeep Holla <sudeep.holla@arm.com> wrote:
> On Thu, May 21, 2020 at 08:57:56AM +0100, Will Deacon wrote:
> > On Thu, May 21, 2020 at 09:34:10AM +0200, Arnd Bergmann wrote:
> > > On Thu, May 21, 2020 at 9:07 AM Sudeep Holla <sudeep.holla@arm.com> wrote:
> > > > On Wed, May 20, 2020 at 11:54:16PM +0200, Arnd Bergmann wrote:
> > > > > On Wed, May 20, 2020 at 11:29 PM Will Deacon <will@kernel.org> wrote:
> > > > > > Applied to arm64 (for-next/smccc), thanks!
> > > > > >
> > > > > > Arnd -- Sudeep's reply to you about the sysfs groups seemed reasonable to me,
> > > > > > but please shout if you'd rather I dropped this in order to pursue an
> > > > > > alternative approach.
> > > > >
> > > > > I missed the reply earlier, thanks for pointing me to it again.
> >
> > D'oh, I took your silence as "no objections". Oh well!
> >
> > > > > I'm not entirely convinced, but don't revert it for now because of that,
> > > > > I assume we can find a solution.
> >
> > Ok, cheers. It's on a separate branch so it's easy enough to drop if
> > necessary (i.e. no reverts needed). Sudeep -- please send any extra patches
> > on top of the branch.
> >
>
> Indeed, it is also last patch in the series. However if Arnd is happy
> with the sysfs names, we can move to generic code later without breaking
> anything.
>
> We need not revert or drop it now. I will leave that to you or Arnd to
> decide. Just that it may be too late to get acks for all the soc sysfs
> drivers in time for v5.8
>
> I am fine if you want to drop the last patch.
Ok, let's drop that patch then and make sure we do something that
everyone is happy with later on. I'm already in favor of adding
a more reliable soc_device instance based on this, but we need to
be sure we don't screw up the contents of the attributes when we
can't change them later.
> > > >> drivers/firmware/smccc/smccc.c:14:13: warning: no previous prototype for function 'arm_smccc_version_init' [-Wmissing-prototypes]
> > > void __init arm_smccc_version_init(u32 version, enum arm_smccc_conduit conduit)
> > > ^
> > > drivers/firmware/smccc/smccc.c:14:1: note: declare 'static' if the
> > > function is not intended to be used outside of this translation unit
> > > void __init arm_smccc_version_init(u32 version, enum arm_smccc_conduit conduit)
> >
> > I saw that when I applied the patches, but since the function is called from
> > another compilation unit (psci/psci.o), I just ignored it as we have loads
> > of these already and it only screams if you build with W=1.
> >
>
> /me confused. Do you need the fix for this warning or you are happy to ignore?
I want a fix for that, as I hope we can eventually turn this warning on by
default and stop playing whack-a-mole when they come up. Most of these
warnings are harmless, but occasionally the prototypes don't match exactly
and cause real bugs depending on the configuration, and ensuring both
sides include a common header file is an easy way to make it work
more reliably.
Note that the warning should come up for either W=1 or C=1, and I also
think that
new code should generally be written sparse-clean and have no warnings with
'make C=1' as a rule.
Arnd
_______________________________________________
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 1/3] ARM: pxa: remove Compulab pxa2xx boards
From: Robert Jarzmik @ 2020-05-21 9:01 UTC (permalink / raw)
To: Mike Rapoport
Cc: Boris Brezillon, linux-mtd, Linux ARM, Arnd Bergmann,
Miquel Raynal
In-Reply-To: <20200520155735.GF1118872@kernel.org>
Mike Rapoport <rppt@kernel.org> writes:
> On Wed, May 20, 2020 at 05:21:51PM +0200, Arnd Bergmann wrote:
>> On Wed, May 20, 2020 at 12:21 PM Robert Jarzmik <robert.jarzmik@free.fr> wrote:
>> >
>> > As these boards have no more users nor testers, and patching them has
>> > become a burden, be that because of the PCI part or the MTD NAND
>> > support, let's remove them.
>> >
>> > The cm-x300 will for now remain and represent Compulab boards at its
>> > best in the PXA department.
>> >
>> > Signed-off-by: Robert Jarzmik <robert.jarzmik@free.fr>
>>
>> Acked-by: Arnd Bergmann <arnd@arndb.de>
>
> I've not been PXA development for a while, so FWIW
>
> Acked-by: Mike Rapoport <rppt@kernel.org>
>
>
>> Should we take the series through the soc tree? If so, please
>> send them to soc@kernel.org if there are no objections;
>> or along with other patches you might have in the pull requests.
Yeah, that would be great. I'll send it to soc@kernel.org, adding the 2 acks I
>> got (which make it a v3).
Cheers.
--
Robert
_______________________________________________
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 3/4] arm64: cpufeature: Modify address authentication cpufeature to exact
From: Suzuki K Poulose @ 2020-05-21 9:00 UTC (permalink / raw)
To: amit.kachhap, catalin.marinas
Cc: mark.rutland, keescook, kristina.martsenko, broonie, james.morse,
Vincenzo.Frascino, will, dave.martin, linux-arm-kernel
In-Reply-To: <0557ca21-99d0-a5a1-0703-d576ba956475@arm.com>
On 05/21/2020 09:09 AM, Amit Kachhap wrote:
> Hi Suzuki,
>
> On 5/20/20 6:50 PM, Suzuki K Poulose wrote:
>> On 05/13/2020 04:42 PM, Amit Kachhap wrote:
>>>
>>>
>>> On 5/12/20 11:03 PM, Catalin Marinas wrote:
>>>> On Fri, May 08, 2020 at 09:51:53PM +0530, Amit Kachhap wrote:
>>>>> On 5/6/20 10:43 PM, Catalin Marinas wrote:
>>>>>> On Tue, Apr 14, 2020 at 11:01:53AM +0530, Amit Daniel Kachhap wrote:
>>>>>>> This patch modifies the address authentication cpufeature type to
>>>>>>> EXACT
>>>>>>> from earlier LOWER_SAFE as the different configurations added for
>>>>>>> Armv8.6
>>>>>>> enhanced PAC have different behaviour and there is no tunable to
>>>>>>> enable the
>>>>>>> lower safe versions. The safe value is set as 0.
>>>>>>>
>>>>>>> After this change, if there is any variation in configurations in
>>>>>>> secondary
>>>>>>> cpus from boot cpu then those cpus are marked tainted. The KVM
>>>>>>> guests may
>>>>>>> completely disable address authentication if there is any such
>>>>>>> variations
>>>>>>> detected.
>>>>>>>
>>>>>>> Signed-off-by: Amit Daniel Kachhap <amit.kachhap@arm.com>
>>>>>>> ---
>>>>>>> arch/arm64/kernel/cpufeature.c | 4 ++--
>>>>>>> 1 file changed, 2 insertions(+), 2 deletions(-)
>>>>>>>
>>>>>>> diff --git a/arch/arm64/kernel/cpufeature.c
>>>>>>> b/arch/arm64/kernel/cpufeature.c
>>>>>>> index 08795025409c..599b03df2f93 100644
>>>>>>> --- a/arch/arm64/kernel/cpufeature.c
>>>>>>> +++ b/arch/arm64/kernel/cpufeature.c
>>>>>>> @@ -154,9 +154,9 @@ static const struct arm64_ftr_bits
>>>>>>> ftr_id_aa64isar1[] = {
>>>>>>> ARM64_FTR_BITS(FTR_VISIBLE, FTR_STRICT, FTR_LOWER_SAFE,
>>>>>>> ID_AA64ISAR1_FCMA_SHIFT, 4, 0),
>>>>>>> ARM64_FTR_BITS(FTR_VISIBLE, FTR_STRICT, FTR_LOWER_SAFE,
>>>>>>> ID_AA64ISAR1_JSCVT_SHIFT, 4, 0),
>>>>>>> ARM64_FTR_BITS(FTR_VISIBLE_IF_IS_ENABLED(CONFIG_ARM64_PTR_AUTH),
>>>>>>> - FTR_STRICT, FTR_LOWER_SAFE,
>>>>>>> ID_AA64ISAR1_API_SHIFT, 4, 0),
>>>>>>> + FTR_STRICT, FTR_EXACT, ID_AA64ISAR1_API_SHIFT, 4,
>>>>>>> 0),
>>>>>>> ARM64_FTR_BITS(FTR_VISIBLE_IF_IS_ENABLED(CONFIG_ARM64_PTR_AUTH),
>>>>>>> - FTR_STRICT, FTR_LOWER_SAFE,
>>>>>>> ID_AA64ISAR1_APA_SHIFT, 4, 0),
>>>>>>> + FTR_STRICT, FTR_EXACT, ID_AA64ISAR1_APA_SHIFT, 4,
>>>>>>> 0),
>>>>>>> ARM64_FTR_BITS(FTR_VISIBLE, FTR_STRICT, FTR_LOWER_SAFE,
>>>>>>> ID_AA64ISAR1_DPB_SHIFT, 4, 0),
>>>>>>> ARM64_FTR_END,
>>>>>>
>>>>>> Is this sufficient? If we have the boot CPU already enabling the
>>>>>> ptrauth
>>>>>> and we get a secondary CPU with a different ISAR1 field that
>>>>>> matches the
>>>>>> address auth in cpufeature.c, we still allow it to boot. We no longer
>>>>>> report the feature to the user system_supports_address_auth() is true
>>>>>> while system_supports_generic_auth() would be false as it checks the
>>>>>> sanitised feature registers.
>>>>>
>>>>> Yes agreed. Generic authentication also needs EXACT cpufeature type.
>>>>
>>>> I'm still not sure that's sufficient. If we boot the primary CPU with
>>>> ptrauth as detected in proc.S, we consider this a boot feature so all
>>>> secondary CPUs must have it. Subsequent CPUs are currently checked via
>>>> the arm64_features[] definitions and we allow them to boot if the ID is
>>>> at least that of the boot CPU. How does this interact with the above
>>>> FTR_EXACT changes?
>>>
>>> Unfortunately FTR_EXACT does not effect the bootflow directly but marks
>>> the cpu TAINTED and goes ahead.
>>>
>>>>
>>>> My concern is that we boot with PAC enabled on all CPUs but because of
>>>> the FTR_EXACT, the sanitised ID registers no longer report the feature.
>>>>
>>>
>>> You are right that PAC is enabled in hardware but un-reported to user
>>> in this case.
>>>
>>> The issue here is in feature_matches() which only validates with the
>>> entry->min_field_value. If we can modify this value to boot cpu value
>>> for FTR_EXACT type then this cpu will fail to online.
>>> May be we can introduce a new structure or make arm64_feature[]
>>> writable for this.
>>>
>>> Something like below code.
>>
>> The has_cpuid_feature() is for features with "FTR_LOWER_SAFE". Hacking
>> it to support EXACT doesn't look ideal. You may simply add your own
>> "matches()" for ptr-auth.
>
> Yes it is reasonable to have separate match() function. I was thinking
> of adding some generic match function for FTR_EXACT to be used by other
> similar cpufeatures.
Ideally, if we enable CPU feature sanity check infrastructure to do this
for us (i.e park a CPU which conflicts), we don't have to duplicate it
here in the capabilities. For now, yes, let us use something specific to
ptr-auth, which may not cater for generic EXACT features. Generalizing
it for different "scope"s are going to be tricky.
>
>>
>> something like :
>>
>> static bool
>> has_addr_auth(const struct arm64_cpu_capabilities *entry, int scope)
>> {
>> static int boot_cpu_auth;
>
> I suppose that is this new match() has to be used for both AUTH_ARCH and
> AUTH_IMP_DEF then we may need 2 such static variables.
>
>> int local_cpu_auth;
>> u64 isar1;
>>
>> /* We don't expect to be called with SCOPE_SYSTEM */
>> WARN_ON(scope == SCOPE_SYSTEM);
>> isar1 = read_sysreg_s(SYS_ID_AA64ISAR1_EL1);
>> local_cpu_auth = cpuid_feature_extract_unsigned_field(isar1,
>> entry->shift);
>>
>> /*
>> * The ptr-auth feature levels are not intercompatible with
>> * lower levels. Hence we must match all the CPUs with that
>> * of the boot CPU. So cache the level of boot CPU and compare
>> * it against the secondary CPUs.
>> */
>> if (scope & SCOPE_BOOT_CPU) {
>> boot_cpu_auth = local_cpu_auth;
>> return boot_cpu_auth > 0;
>
> May be,
> return boot_cpu_auth >= entry->min_field_value
Yes, thats fine.
Cheers
Suzuki
_______________________________________________
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 09/12] devfreq: add mediatek cci devfreq
From: andrew-sh.cheng @ 2020-05-21 8:52 UTC (permalink / raw)
Cc: Mark Rutland, Nishanth Menon, srv_heupstream, linux-pm,
Stephen Boyd, Viresh Kumar, Rafael J . Wysocki, Liam Girdwood,
Rob Herring, linux-kernel, Chanwoo Choi, Kyungmin Park,
MyungJoo Ham, linux-mediatek, linux-arm-kernel, Matthias Brugger,
devicetree
In-Reply-To: <20200520123135.GD4823@sirena.org.uk>
On Wed, 2020-05-20 at 13:31 +0100, Mark Brown wrote:
> On Wed, May 20, 2020 at 11:43:04AM +0800, Andrew-sh.Cheng wrote:
>
> > + cci_df->proc_reg = devm_regulator_get_optional(cci_dev, "proc");
> > + ret = PTR_ERR_OR_ZERO(cci_df->proc_reg);
> > + if (ret) {
> > + if (ret != -EPROBE_DEFER)
> > + dev_err(cci_dev, "failed to get regulator for CCI: %d\n",
> > + ret);
> > + return ret;
> > + }
> > + ret = regulator_enable(cci_df->proc_reg);
>
> The code appears to require a regulator (and I'm guessing the device
> needs power) so why is this using regulator_get_optional()?
Hi Mark,
Do you mean, why not use regulator_get_exclusive() or regulator_get()?
Because cci and cpu litter core shared buck, it cannot use
regulator_get_exclusive().
Because both cci and cpu want to tune voltage, it cannot use
regulator_get(), otherwise it will get dummy regulator even this buck
doesn't register.as regulator.
BR,
Andrew-sh.Cheng
_______________________________________________
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 v5 01/19] spi: spi-mem: allow specifying whether an op is DTR or not
From: masonccyang @ 2020-05-21 8:27 UTC (permalink / raw)
To: Pratyush Yadav
Cc: Alexandre Belloni, Vignesh Raghavendra, Tudor Ambarus, juliensu,
Richard Weinberger, Mark Brown, Sekhar Nori, linux-kernel,
linux-spi, Ludovic Desroches, Boris Brezillon, linux-mediatek,
Miquel Raynal, Matthias Brugger, linux-mtd, Pratyush Yadav,
linux-arm-kernel
In-Reply-To: <20200519142642.24131-2-p.yadav@ti.com>
Hi Pratyush,
Given cmd.nbytes a initial value & check it !
>
> [PATCH v5 01/19] spi: spi-mem: allow specifying whether an op is DTR or
not
>
> Each phase is given a separate 'dtr' field so mixed protocols like
> 4S-4D-4D can be supported.
>
> Signed-off-by: Pratyush Yadav <p.yadav@ti.com>
> ---
> drivers/spi/spi-mem.c | 3 +++
> include/linux/spi/spi-mem.h | 8 ++++++++
> 2 files changed, 11 insertions(+)
>
> diff --git a/drivers/spi/spi-mem.c b/drivers/spi/spi-mem.c
> index 9a86cc27fcc0..93e255287ab9 100644
> --- a/drivers/spi/spi-mem.c
> +++ b/drivers/spi/spi-mem.c
> @@ -156,6 +156,9 @@ bool spi_mem_default_supports_op(struct spi_mem
*mem,
> op->data.dir == SPI_MEM_DATA_OUT))
> return false;
>
> + if (op->cmd.dtr || op->addr.dtr || op->dummy.dtr || op->data.dtr)
> + return false;
> +
+ if (op->cmd.nbytes != 1)
+ return false;
> return true;
> }
> EXPORT_SYMBOL_GPL(spi_mem_default_supports_op);
static int spi_mem_check_op(const struct spi_mem_op *op)
{
- if (!op->cmd.buswidth)
+ if (!op->cmd.buswidth || op->cmd.nbytes < 1 ||
op->cmd.nbytes > 2)
return -EINVAL;
> diff --git a/include/linux/spi/spi-mem.h b/include/linux/spi/spi-mem.h
> index af9ff2f0f1b2..e3dcb956bf61 100644
> --- a/include/linux/spi/spi-mem.h
> +++ b/include/linux/spi/spi-mem.h
#define SPI_MEM_OP_CMD(__opcode, __buswidth) \
{ \
.buswidth = __buswidth, \
.opcode = __opcode, \
+ .nbytes = 1, \
}
> @@ -71,9 +71,11 @@ enum spi_mem_data_dir {
> * struct spi_mem_op - describes a SPI memory operation
> * @cmd.buswidth: number of IO lines used to transmit the command
> * @cmd.opcode: operation opcode
> + * @cmd.dtr: whether the command opcode should be sent in DTR mode or
not
> * @addr.nbytes: number of address bytes to send. Can be zero if the
operation
> * does not need to send an address
> * @addr.buswidth: number of IO lines used to transmit the address
cycles
> + * @addr.dtr: whether the address should be sent in DTR mode or not
> * @addr.val: address value. This value is always sent MSB first on the
bus.
> * Note that only @addr.nbytes are taken into account in this
> * address value, so users should make sure the value fits in
the
> @@ -81,7 +83,9 @@ enum spi_mem_data_dir {
> * @dummy.nbytes: number of dummy bytes to send after an opcode or
address. Can
> * be zero if the operation does not require dummy bytes
> * @dummy.buswidth: number of IO lanes used to transmit the dummy bytes
> + * @dummy.dtr: whether the dummy bytes should be sent in DTR mode or
not
> * @data.buswidth: number of IO lanes used to send/receive the data
> + * @data.dtr: whether the data should be sent in DTR mode or not
> * @data.dir: direction of the transfer
> * @data.nbytes: number of data bytes to send/receive. Can be zero if
the
> * operation does not involve transferring data
> @@ -91,22 +95,26 @@ enum spi_mem_data_dir {
> struct spi_mem_op {
> struct {
> u8 buswidth;
> + u8 dtr : 1;
> u8 opcode;
> } cmd;
>
> struct {
> u8 nbytes;
> u8 buswidth;
> + u8 dtr : 1;
> u64 val;
> } addr;
>
> struct {
> u8 nbytes;
> u8 buswidth;
> + u8 dtr : 1;
> } dummy;
>
> struct {
> u8 buswidth;
> + u8 dtr : 1;
> enum spi_mem_data_dir dir;
> unsigned int nbytes;
> union {
> --
> 2.26.2
>
thanks & best regards,
Mason
CONFIDENTIALITY NOTE:
This e-mail and any attachments may contain confidential information
and/or personal data, which is protected by applicable laws. Please be
reminded that duplication, disclosure, distribution, or use of this e-mail
(and/or its attachments) or any part thereof is prohibited. If you receive
this e-mail in error, please notify us immediately and delete this mail as
well as its attachment(s) from your system. In addition, please be
informed that collection, processing, and/or use of personal data is
prohibited unless expressly permitted by personal data protection laws.
Thank you for your attention and cooperation.
Macronix International Co., Ltd.
=====================================================================
============================================================================
CONFIDENTIALITY NOTE:
This e-mail and any attachments may contain confidential information and/or personal data, which is protected by applicable laws. Please be reminded that duplication, disclosure, distribution, or use of this e-mail (and/or its attachments) or any part thereof is prohibited. If you receive this e-mail in error, please notify us immediately and delete this mail as well as its attachment(s) from your system. In addition, please be informed that collection, processing, and/or use of personal data is prohibited unless expressly permitted by personal data protection laws. Thank you for your attention and cooperation.
Macronix International Co., Ltd.
=====================================================================
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* [PATCH 1/2] ARM: Remove redundant ARCH_SPARSEMEM_DEFAULT setting
From: Mike Rapoport @ 2020-05-21 8:18 UTC (permalink / raw)
To: Russell King - ARM Linux admin
Cc: Florian Fainelli, Arnd Bergmann, Stephen Boyd, Kevin Cernekee,
Mike Rapoport, Doug Berger, Gregory Fong, linux-arm-kernel
In-Reply-To: <20200521081825.1348844-1-rppt@linux.ibm.com>
From: Kevin Cernekee <cernekee@gmail.com>
If ARCH_SPARSEMEM_ENABLE=y and ARCH_{FLATMEM,DISCONTIGMEM}_ENABLE=n,
then the logic in mm/Kconfig already makes CONFIG_SPARSEMEM the only
choice. This is true for all of the existing ARM users of
ARCH_SPARSEMEM_ENABLE.
Forcing ARCH_SPARSEMEM_DEFAULT=y if ARCH_SPARSEMEM_ENABLE=y prevents
us from ever defaulting to FLATMEM, so we should remove this setting.
Link: https://lkml.org/lkml/2015/6/4/757
Signed-off-by: Kevin Cernekee <cernekee@gmail.com>
Tested-by: Stephen Boyd <sboyd@codeaurora.org>
Acked-by: Arnd Bergmann <arnd@arndb.de>
Signed-off-by: Gregory Fong <gregory.0xf0@gmail.com>
Signed-off-by: Doug Berger <opendmb@gmail.com>
Signed-off-by: Florian Fainelli <f.fainelli@gmail.com>
---
arch/arm/Kconfig | 3 ---
1 file changed, 3 deletions(-)
diff --git a/arch/arm/Kconfig b/arch/arm/Kconfig
index c88a48d622fc..604caf652e2a 100644
--- a/arch/arm/Kconfig
+++ b/arch/arm/Kconfig
@@ -1519,9 +1519,6 @@ config ARCH_SPARSEMEM_ENABLE
bool
select SPARSEMEM_STATIC
-config ARCH_SPARSEMEM_DEFAULT
- def_bool ARCH_SPARSEMEM_ENABLE
-
config HAVE_ARCH_PFN_VALID
def_bool ARCH_HAS_HOLES_MEMORYMODEL || !SPARSEMEM
--
2.26.2
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply related
* [PATCH 2/2] ARM: Allow either FLATMEM or SPARSEMEM on the multiplatform build
From: Mike Rapoport @ 2020-05-21 8:18 UTC (permalink / raw)
To: Russell King - ARM Linux admin
Cc: Florian Fainelli, Arnd Bergmann, Stephen Boyd, Kevin Cernekee,
Mike Rapoport, Doug Berger, Gregory Fong, linux-arm-kernel
In-Reply-To: <20200521081825.1348844-1-rppt@linux.ibm.com>
From: Gregory Fong <gregory.0xf0@gmail.com>
ARMv7 chips with LPAE can often benefit from SPARSEMEM, as portions of
system memory can be located deep in the 36-bit address space. Allow
FLATMEM or SPARSEMEM to be selectable at compile time; FLATMEM remains
the default.
This is based on Kevin's "[PATCH 3/3] ARM: Allow either FLATMEM or
SPARSEMEM on the multi-v7 build" from [1] and shamelessly rips off his
commit message text above. As Arnd pointed out at [2] there doesn't
seem to be any reason to tie this specifically to ARMv7, so this has
been changed to apply to all multiplatform kernels.
The addition of this option does not change the defaults and a build with
any defconfig will behave the same way as previously.
The only effect this change has is to enable user to change "Memory model"
selection in interactive kernel configuration (menuconfig, xconfig etc).
[1] http://lists.infradead.org/pipermail/linux-arm-kernel/2014-September/286837.html
[2] http://lists.infradead.org/pipermail/linux-arm-kernel/2014-October/298950.html
[ rppt: added ARCH_SELECT_MEMORY_MODEL and update the changelog ]
Cc: Kevin Cernekee <cernekee@gmail.com>
Tested-by: Stephen Boyd <sboyd@codeaurora.org>
Signed-off-by: Gregory Fong <gregory.0xf0@gmail.com>
Signed-off-by: Doug Berger <opendmb@gmail.com>
Signed-off-by: Florian Fainelli <f.fainelli@gmail.com>
Signed-off-by: Mike Rapoport <rppt@linux.ibm.com>
---
arch/arm/Kconfig | 11 ++++++++++-
1 file changed, 10 insertions(+), 1 deletion(-)
diff --git a/arch/arm/Kconfig b/arch/arm/Kconfig
index 604caf652e2a..34b93e0903df 100644
--- a/arch/arm/Kconfig
+++ b/arch/arm/Kconfig
@@ -312,6 +312,9 @@ choice
config ARCH_MULTIPLATFORM
bool "Allow multiple platforms to be selected"
depends on MMU
+ select ARCH_FLATMEM_ENABLE
+ select ARCH_SPARSEMEM_ENABLE
+ select ARCH_SELECT_MEMORY_MODEL
select ARM_HAS_SG_CHAIN
select ARM_PATCH_PHYS_VIRT
select AUTO_ZRELADDR
@@ -1515,9 +1518,15 @@ config OABI_COMPAT
config ARCH_HAS_HOLES_MEMORYMODEL
bool
+config ARCH_SELECT_MEMORY_MODEL
+ bool
+
+config ARCH_FLATMEM_ENABLE
+ bool
+
config ARCH_SPARSEMEM_ENABLE
bool
- select SPARSEMEM_STATIC
+ select SPARSEMEM_STATIC if SPARSEMEM
config HAVE_ARCH_PFN_VALID
def_bool ARCH_HAS_HOLES_MEMORYMODEL || !SPARSEMEM
--
2.26.2
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply related
* [PATCH 0/2] ARM: Allow either FLATMEM or SPARSEMEM on the multiplatform build
From: Mike Rapoport @ 2020-05-21 8:18 UTC (permalink / raw)
To: Russell King - ARM Linux admin
Cc: Florian Fainelli, Arnd Bergmann, Stephen Boyd, Kevin Cernekee,
Mike Rapoport, Doug Berger, Gregory Fong, linux-arm-kernel
(resendig for the correct address and with mailing list cc'ed, sorry for
the noise)
Hi,
Following the discussion at [1], I'm resending the patches that enable
memory model selection in menuconfig and such.
These patches do not change the way the configuration is generated from the
defconfigs and they do not change explicit selection of SPARSEMEM for
platforms that have "select ARCH_ENABLE_SPARSEMEM".
The mere change is that when a user runs an interactive configuration they
will be allowed to select between FLATMEM and SPARSMEM, which is not the
case today.
There is indeed some awkwardness in, e.g. removal of
ARCH_SPARSEMEM_DEFAULT, but this is what memory model selection logic in
mm/Kconfig imposes.
For example, below is the diffs of the configurations generated with
'make rpc_defconfig' and 'make defconfig':
$ diff -s old/rpc_defconfig new/rpc_defconfig
Files old/rpc_defconfig and new/rpc_defconfig are identical
$ diff -u old/defconfig new/defconfig
--- old/defconfig 2020-05-20 17:51:01.832649705 +0300
+++ new/defconfig 2020-05-20 18:15:21.084385880 +0300
@@ -674,6 +674,9 @@
CONFIG_AEABI=y
# CONFIG_OABI_COMPAT is not set
CONFIG_ARCH_HAS_HOLES_MEMORYMODEL=y
+CONFIG_ARCH_SELECT_MEMORY_MODEL=y
+CONFIG_ARCH_FLATMEM_ENABLE=y
+CONFIG_ARCH_SPARSEMEM_ENABLE=y
CONFIG_HAVE_ARCH_PFN_VALID=y
CONFIG_HIGHMEM=y
CONFIG_HIGHPTE=y
@@ -1061,6 +1064,9 @@
#
# Memory Management options
#
+CONFIG_SELECT_MEMORY_MODEL=y
+CONFIG_FLATMEM_MANUAL=y
+# CONFIG_SPARSEMEM_MANUAL is not set
CONFIG_FLATMEM=y
CONFIG_FLAT_NODE_MEM_MAP=y
CONFIG_ARCH_KEEP_MEMBLOCK=y
[1] https://lore.kernel.org/linux-arm-kernel/20200506235009.25023-1-f.fainelli@gmail.com
Gregory Fong (1):
ARM: Allow either FLATMEM or SPARSEMEM on the multiplatform build
Kevin Cernekee (1):
ARM: Remove redundant ARCH_SPARSEMEM_DEFAULT setting
arch/arm/Kconfig | 14 ++++++++++----
1 file changed, 10 insertions(+), 4 deletions(-)
--
2.26.2
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* [GIT PULL] Immutable branch between MFD, Power and RTC due for the v5.8 merge window
From: Lee Jones @ 2020-05-21 8:16 UTC (permalink / raw)
To: Hsin-Hsiung Wang
Cc: linux-rtc, Alessandro Zummo, Alexandre Belloni, drinkcat,
srv_heupstream, Frank Wunderlich, Josef Friedl, Ran Bi, Sean Wang,
Sebastian Reichel, linux-kernel, Richard Fontana, devicetree,
Rob Herring, linux-mediatek, linux-pm, Matthias Brugger,
Thomas Gleixner, Eddie Huang, linux-arm-kernel
In-Reply-To: <1587438012-24832-1-git-send-email-hsin-hsiung.wang@mediatek.com>
Enjoy!
The following changes since commit 8f3d9f354286745c751374f5f1fcafee6b3f3136:
Linux 5.7-rc1 (2020-04-12 12:35:55 -0700)
are available in the Git repository at:
git://git.kernel.org/pub/scm/linux/kernel/git/lee/mfd.git ib-mfd-power-rtc-v5.8
for you to fetch changes up to 29ee40091e27615530c0ba7773a2879d8266381e:
rtc: mt6397: Add support for the MediaTek MT6358 RTC (2020-05-21 08:55:48 +0100)
----------------------------------------------------------------
Immutable branch between MFD, Power and RTC due for the v5.8 merge window
----------------------------------------------------------------
Hsin-Hsiung Wang (4):
mfd: mt6397: Modify suspend/resume behavior
mfd: mt6397: Trim probe function to support different chips more cleanly
dt-bindings: mfd: Add compatible for the MediaTek MT6358 PMIC
mfd: Add support for the MediaTek MT6358 PMIC
Ran Bi (1):
rtc: mt6397: Add support for the MediaTek MT6358 RTC
Documentation/devicetree/bindings/mfd/mt6397.txt | 14 +-
drivers/mfd/Makefile | 2 +-
drivers/mfd/mt6358-irq.c | 235 +++++++++++++++++++
drivers/mfd/mt6397-core.c | 101 ++++----
drivers/mfd/mt6397-irq.c | 35 ++-
drivers/power/reset/mt6323-poweroff.c | 2 +-
drivers/rtc/rtc-mt6397.c | 18 +-
include/linux/mfd/mt6358/core.h | 158 +++++++++++++
include/linux/mfd/mt6358/registers.h | 282 +++++++++++++++++++++++
include/linux/mfd/mt6397/core.h | 5 +
include/linux/mfd/mt6397/rtc.h | 9 +-
11 files changed, 799 insertions(+), 62 deletions(-)
create mode 100644 drivers/mfd/mt6358-irq.c
create mode 100644 include/linux/mfd/mt6358/core.h
create mode 100644 include/linux/mfd/mt6358/registers.h
--
Lee Jones [李琼斯]
Linaro Services Technical Lead
Linaro.org │ Open source software for ARM SoCs
Follow Linaro: Facebook | Twitter | Blog
_______________________________________________
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 v4 0/7] firmware: smccc: Add basic SMCCC v1.2 + ARCH_SOC_ID support
From: Sudeep Holla @ 2020-05-21 8:10 UTC (permalink / raw)
To: Will Deacon
Cc: Mark Rutland, Lorenzo Pieralisi, Arnd Bergmann, Catalin Marinas,
linux-kernel@vger.kernel.org, Steven Price, harb, Linux ARM
In-Reply-To: <20200521075755.GA4668@willie-the-truck>
On Thu, May 21, 2020 at 08:57:56AM +0100, Will Deacon wrote:
> On Thu, May 21, 2020 at 09:34:10AM +0200, Arnd Bergmann wrote:
> > On Thu, May 21, 2020 at 9:07 AM Sudeep Holla <sudeep.holla@arm.com> wrote:
> > > On Wed, May 20, 2020 at 11:54:16PM +0200, Arnd Bergmann wrote:
> > > > On Wed, May 20, 2020 at 11:29 PM Will Deacon <will@kernel.org> wrote:
> > > > > Applied to arm64 (for-next/smccc), thanks!
> > > > >
> > > > > Arnd -- Sudeep's reply to you about the sysfs groups seemed reasonable to me,
> > > > > but please shout if you'd rather I dropped this in order to pursue an
> > > > > alternative approach.
> > > >
> > > > I missed the reply earlier, thanks for pointing me to it again.
>
> D'oh, I took your silence as "no objections". Oh well!
>
> > > > I'm not entirely convinced, but don't revert it for now because of that,
> > > > I assume we can find a solution.
>
> Ok, cheers. It's on a separate branch so it's easy enough to drop if
> necessary (i.e. no reverts needed). Sudeep -- please send any extra patches
> on top of the branch.
>
Indeed, it is also last patch in the series. However if Arnd is happy
with the sysfs names, we can move to generic code later without breaking
anything.
We need not revert or drop it now. I will leave that to you or Arnd to
decide. Just that it may be too late to get acks for all the soc sysfs
drivers in time for v5.8
I am fine if you want to drop the last patch.
> > > I liked your idea of making this generic and hardcode values if required
> > > for other drivers. I will take a look at that/
> > >
> > > > However, please have a look at the build failure report for patch 5
> > > > and fix it if you can see what went wrong.
> > > >
> > >
> > > Any pointers for that failure ? I seem to have missed them. I pushed
> > > branch couple of times to my tree but got build success both times.
> > > Any specific config or compilers ?
> >
> > See below for the reply from the 0day build bot to your email. It seems it
> > was not sent to the mailing list, but you were on Cc. Looking at it now,
> > the fix should be trivial.
>
> [...]
>
> > >> drivers/firmware/smccc/smccc.c:14:13: warning: no previous prototype for function 'arm_smccc_version_init' [-Wmissing-prototypes]
> > void __init arm_smccc_version_init(u32 version, enum arm_smccc_conduit conduit)
> > ^
> > drivers/firmware/smccc/smccc.c:14:1: note: declare 'static' if the
> > function is not intended to be used outside of this translation unit
> > void __init arm_smccc_version_init(u32 version, enum arm_smccc_conduit conduit)
>
> I saw that when I applied the patches, but since the function is called from
> another compilation unit (psci/psci.o), I just ignored it as we have loads
> of these already and it only screams if you build with W=1.
>
/me confused. Do you need the fix for this warning or you are happy to ignore?
--
Regards,
Sudeep
_______________________________________________
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 v5 09/19] mtd: spi-nor: sfdp: parse xSPI Profile 1.0 table
From: masonccyang @ 2020-05-21 8:09 UTC (permalink / raw)
To: Pratyush Yadav
Cc: Alexandre Belloni, Vignesh Raghavendra, Tudor Ambarus, juliensu,
Richard Weinberger, Mark Brown, Sekhar Nori, linux-kernel,
linux-spi, Ludovic Desroches, Boris Brezillon, linux-mediatek,
Miquel Raynal, Matthias Brugger, linux-mtd, linux-arm-kernel
In-Reply-To: <20200520103728.jtbslowdfrv3o5yz@ti.com>
Hi Pratyush,
> >
> > > > > +/**
> > > > > + * spi_nor_parse_profile1() - parse the xSPI Profile 1.0 table
> > > > > + * @nor: pointer to a 'struct spi_nor'
> > > > > + * @param_header: pointer to the 'struct
sfdp_parameter_header'
> > > > describing
> > > > > + * the 4-Byte Address Instruction Table length and
version.
> > > > > + * @params: pointer to the 'struct
spi_nor_flash_parameter' to
> > be.
> > > > > + *
> > > > > + * Return: 0 on success, -errno otherwise.
> > > > > + */
> > > > > +static int spi_nor_parse_profile1(struct spi_nor *nor,
> > > > > + const struct sfdp_parameter_header
*profile1_header,
> > > > > + struct spi_nor_flash_parameter *params)
> > > > > +{
> > > > > + u32 *table, opcode, addr;
> > > > > + size_t len;
> > > > > + int ret, i;
> > > > > +
> > > > > + len = profile1_header->length * sizeof(*table);
> > > > > + table = kmalloc(len, GFP_KERNEL);
> > > > > + if (!table)
> > > > > + return -ENOMEM;
> > > > > +
> > > > > + addr = SFDP_PARAM_HEADER_PTP(profile1_header);
> > > > > + ret = spi_nor_read_sfdp(nor, addr, len, table);
> > > > > + if (ret)
> > > > > + goto out;
> > > > > +
> > > > > + /* Fix endianness of the table DWORDs. */
> > > > > + for (i = 0; i < profile1_header->length; i++)
> > > > > + table[i] = le32_to_cpu(table[i]);
> > > > > +
> > > > > + /* Get 8D-8D-8D fast read opcode and dummy cycles. */
> > > > > + opcode = FIELD_GET(PROFILE1_DWORD1_RD_FAST_CMD, table[0]);
> > > > > +
> > > > > + /*
> > > > > + * Update the fast read settings. We set the default dummy
> > cycles to
> > > > 20
> > > > > + * here. Flashes can change this value if they need to when
> > enabling
> > > > > + * octal mode.
> > > > > + */
> > > > > +
spi_nor_set_read_settings(¶ms->reads[SNOR_CMD_READ_8_8_8_DTR],
> > > > > + 0, 20, opcode,
> > > > > + SNOR_PROTO_8_8_8_DTR);
> > > > > +
> > > >
> > > >
> > > > I thought we have a agreement that only do parse here, no other
read
> > > > parameters setting.
> > >
> > > Yes, and I considered it. But it didn't make much sense to me to
> > > introduce an extra member in struct spi_nor just to make this call
in
> > > some other function later.
> > >
> > > Why exactly do you think doing this here is bad? The way I see it,
we
> > > avoid carrying around an extra member in spi_nor and this also
allows
> > > flashes to change the read settings easily in a post-sfdp hook. The
> > > 4bait parsing function does something similar.
> >
> > I think it's not a question for good or bad.
> >
> > 4bait parsing function parse the 4-Byte Address Instruction Table
> > and set up read/pp parameters there for sure.
> >
> > Here we give the function name spi_nor_parse_profile1() but also
>
> But the function that parses 4bait table is also called
> spi_nor_parse_4bait().
>
> > do others setting that has nothing to do with it,
>
> Why has setting read opcode and dummy cycles got nothing to do with it?
> The purpose of the Profile 1.0 table is to tell us the Read Fast command
> and dummy cycles, among other things. I think it _does_ have something
> to do with it.
As you know I mean this function just do parse parameter of profile 1
table
and keep these value data for later usage.
A device supports xSPI profile table could work in either 8S-8S-8S or
8D-8D-8D mode.
It seems to setup these parameters somewhere out here is betters.
>
> Just like the 4bait table tells us the 4-byte opcodes and we set them up
> in our data structures, the profile 1.0 table tells us the 8D read
> opcode and dummy cycles, and we set them up in our data structures.
>
> > it seems not good for SW module design.
> > oh, it's my humble opinion.
> >
> > >
> > > What are the benefits of doing it otherwise?
> >
> > For other Octal Flash like mx25*
>
> I mean from a design perspective. How does it make the code better, or
> the job of people who need to read/change it easier?
yes, agreed.
I also need to patch for 8S-8S-8S mode, not only 8D-8D-8D mode.
That's why we have some discussions.
thanks & best regards,
Mason
CONFIDENTIALITY NOTE:
This e-mail and any attachments may contain confidential information
and/or personal data, which is protected by applicable laws. Please be
reminded that duplication, disclosure, distribution, or use of this e-mail
(and/or its attachments) or any part thereof is prohibited. If you receive
this e-mail in error, please notify us immediately and delete this mail as
well as its attachment(s) from your system. In addition, please be
informed that collection, processing, and/or use of personal data is
prohibited unless expressly permitted by personal data protection laws.
Thank you for your attention and cooperation.
Macronix International Co., Ltd.
=====================================================================
============================================================================
CONFIDENTIALITY NOTE:
This e-mail and any attachments may contain confidential information and/or personal data, which is protected by applicable laws. Please be reminded that duplication, disclosure, distribution, or use of this e-mail (and/or its attachments) or any part thereof is prohibited. If you receive this e-mail in error, please notify us immediately and delete this mail as well as its attachment(s) from your system. In addition, please be informed that collection, processing, and/or use of personal data is prohibited unless expressly permitted by personal data protection laws. Thank you for your attention and cooperation.
Macronix International Co., Ltd.
=====================================================================
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
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