All of lore.kernel.org
 help / color / mirror / Atom feed
* [RFC] Mediatek SCPSYS power domain support
@ 2015-03-09  8:09 ` Sascha Hauer
  0 siblings, 0 replies; 40+ messages in thread
From: Sascha Hauer @ 2015-03-09  8:09 UTC (permalink / raw)
  To: linux-arm-kernel
  Cc: devicetree, linux-kernel, Matthias Brugger, linux-mediatek, kernel

s series adds support for the MediaTek SCPSYS unit.

The SCPSYS unit handles several power management related tasks such
as thermal measurement, DVFS, interrupt filter and low level sleep
control.

The initial support only contains the generic power domain handling.
This is needed to turn on power to the different power domains.

The driver is quite straight forward now. Due to the lack of a better
place I have put it to drivers/soc/mediatek. As the SCPSYS unit has
several other tasks that also do not fit into some specific subsystem
this probably is a good place for this driver.

What is not clear to me is how the Kconfig dependencies should be
handled. Some domains are disabled by bootloader default, so without
this driver for example sound won't work. So should PM, PM_GENERIC_DOMAINS
and this driver be made mandatory for MT8173? Or should this driver
when PM is disabled be compiled as a stub which only enables all
domains? I don't have a good idea how things should work out here.

Please review, any input welcome.

Sascha

----------------------------------------------------------------
Sascha Hauer (4):
      soc: Mediatek: Add SCPSYS power domain driver
      dt-bindings: soc: Add documentation for the MediaTek SCPSYS unit
      ARM64: MediaTek: Add generic pm domain support
      ARM64: MediaTek MT8173: Add SCPSYS device node

 .../devicetree/bindings/soc/mediatek/scpsys.txt    |  32 ++
 arch/arm64/Kconfig                                 |   1 +
 arch/arm64/boot/dts/mediatek/mt8173.dtsi           |   6 +
 drivers/soc/mediatek/Kconfig                       |   6 +
 drivers/soc/mediatek/Makefile                      |   1 +
 drivers/soc/mediatek/mtk-scpsys.c                  | 398 +++++++++++++++++++++
 include/dt-bindings/power/mt8173-power.h           |  15 +
 7 files changed, 459 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/soc/mediatek/scpsys.txt
 create mode 100644 drivers/soc/mediatek/mtk-scpsys.c
 create mode 100644 include/dt-bindings/power/mt8173-power.h


^ permalink raw reply	[flat|nested] 40+ messages in thread

* [RFC] Mediatek SCPSYS power domain support
@ 2015-03-09  8:09 ` Sascha Hauer
  0 siblings, 0 replies; 40+ messages in thread
From: Sascha Hauer @ 2015-03-09  8:09 UTC (permalink / raw)
  To: linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r
  Cc: devicetree-u79uwXL29TY76Z2rM5mHXA,
	linux-kernel-u79uwXL29TY76Z2rM5mHXA, Matthias Brugger,
	linux-mediatek-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
	kernel-bIcnvbaLZ9MEGnE8C9+IrQ

s series adds support for the MediaTek SCPSYS unit.

The SCPSYS unit handles several power management related tasks such
as thermal measurement, DVFS, interrupt filter and low level sleep
control.

The initial support only contains the generic power domain handling.
This is needed to turn on power to the different power domains.

The driver is quite straight forward now. Due to the lack of a better
place I have put it to drivers/soc/mediatek. As the SCPSYS unit has
several other tasks that also do not fit into some specific subsystem
this probably is a good place for this driver.

What is not clear to me is how the Kconfig dependencies should be
handled. Some domains are disabled by bootloader default, so without
this driver for example sound won't work. So should PM, PM_GENERIC_DOMAINS
and this driver be made mandatory for MT8173? Or should this driver
when PM is disabled be compiled as a stub which only enables all
domains? I don't have a good idea how things should work out here.

Please review, any input welcome.

Sascha

----------------------------------------------------------------
Sascha Hauer (4):
      soc: Mediatek: Add SCPSYS power domain driver
      dt-bindings: soc: Add documentation for the MediaTek SCPSYS unit
      ARM64: MediaTek: Add generic pm domain support
      ARM64: MediaTek MT8173: Add SCPSYS device node

 .../devicetree/bindings/soc/mediatek/scpsys.txt    |  32 ++
 arch/arm64/Kconfig                                 |   1 +
 arch/arm64/boot/dts/mediatek/mt8173.dtsi           |   6 +
 drivers/soc/mediatek/Kconfig                       |   6 +
 drivers/soc/mediatek/Makefile                      |   1 +
 drivers/soc/mediatek/mtk-scpsys.c                  | 398 +++++++++++++++++++++
 include/dt-bindings/power/mt8173-power.h           |  15 +
 7 files changed, 459 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/soc/mediatek/scpsys.txt
 create mode 100644 drivers/soc/mediatek/mtk-scpsys.c
 create mode 100644 include/dt-bindings/power/mt8173-power.h

--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

^ permalink raw reply	[flat|nested] 40+ messages in thread

* [RFC] Mediatek SCPSYS power domain support
@ 2015-03-09  8:09 ` Sascha Hauer
  0 siblings, 0 replies; 40+ messages in thread
From: Sascha Hauer @ 2015-03-09  8:09 UTC (permalink / raw)
  To: linux-arm-kernel

s series adds support for the MediaTek SCPSYS unit.

The SCPSYS unit handles several power management related tasks such
as thermal measurement, DVFS, interrupt filter and low level sleep
control.

The initial support only contains the generic power domain handling.
This is needed to turn on power to the different power domains.

The driver is quite straight forward now. Due to the lack of a better
place I have put it to drivers/soc/mediatek. As the SCPSYS unit has
several other tasks that also do not fit into some specific subsystem
this probably is a good place for this driver.

What is not clear to me is how the Kconfig dependencies should be
handled. Some domains are disabled by bootloader default, so without
this driver for example sound won't work. So should PM, PM_GENERIC_DOMAINS
and this driver be made mandatory for MT8173? Or should this driver
when PM is disabled be compiled as a stub which only enables all
domains? I don't have a good idea how things should work out here.

Please review, any input welcome.

Sascha

----------------------------------------------------------------
Sascha Hauer (4):
      soc: Mediatek: Add SCPSYS power domain driver
      dt-bindings: soc: Add documentation for the MediaTek SCPSYS unit
      ARM64: MediaTek: Add generic pm domain support
      ARM64: MediaTek MT8173: Add SCPSYS device node

 .../devicetree/bindings/soc/mediatek/scpsys.txt    |  32 ++
 arch/arm64/Kconfig                                 |   1 +
 arch/arm64/boot/dts/mediatek/mt8173.dtsi           |   6 +
 drivers/soc/mediatek/Kconfig                       |   6 +
 drivers/soc/mediatek/Makefile                      |   1 +
 drivers/soc/mediatek/mtk-scpsys.c                  | 398 +++++++++++++++++++++
 include/dt-bindings/power/mt8173-power.h           |  15 +
 7 files changed, 459 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/soc/mediatek/scpsys.txt
 create mode 100644 drivers/soc/mediatek/mtk-scpsys.c
 create mode 100644 include/dt-bindings/power/mt8173-power.h

^ permalink raw reply	[flat|nested] 40+ messages in thread

* [PATCH 1/4] dt-bindings: soc: Add documentation for the MediaTek SCPSYS unit
  2015-03-09  8:09 ` Sascha Hauer
@ 2015-03-09  8:10   ` Sascha Hauer
  -1 siblings, 0 replies; 40+ messages in thread
From: Sascha Hauer @ 2015-03-09  8:10 UTC (permalink / raw)
  To: linux-arm-kernel
  Cc: devicetree, linux-kernel, Matthias Brugger, linux-mediatek,
	kernel, Sascha Hauer

This adds documentation for the MediaTek SCPSYS unit found in MT8173 SoCs.

Signed-off-by: Sascha Hauer <s.hauer@pengutronix.de>
---
 .../devicetree/bindings/soc/mediatek/scpsys.txt    | 32 ++++++++++++++++++++++
 1 file changed, 32 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/soc/mediatek/scpsys.txt

diff --git a/Documentation/devicetree/bindings/soc/mediatek/scpsys.txt b/Documentation/devicetree/bindings/soc/mediatek/scpsys.txt
new file mode 100644
index 0000000..4764a03
--- /dev/null
+++ b/Documentation/devicetree/bindings/soc/mediatek/scpsys.txt
@@ -0,0 +1,32 @@
+MediaTek SCPSYS
+===============
+
+The System Control Processor System (SCPSYS) has several power management
+related tasks in the system. The tasks include thermal measurement, dynamic
+voltage frequency scaling (DVFS), interrupt filter and lowlevel sleep control.
+The System Power Manager (SPM) inside the SCPSYS is for the MTCMOS power
+domain control.
+
+The driver implements the Generic PM domain bindings described in
+power/power_domain.txt. It provides the power domains defined in
+include/dt-bindings/power/mt8173-power.h.
+
+Required properties:
+- compatible: Must be "mediatek,mt8173-scpsys"
+- #power-domain-cells: Must be 1
+- reg: Address range of the SCPSYS unit
+
+Example:
+
+	scpsys: scpsys@10006000 {
+		#power-domain-cells = <1>;
+		compatible = "mediatek,mt8173-scpsys";
+		reg = <0 0x10006000 0 0x1000>;
+	};
+
+Example consumer:
+
+	afe: mt8173-afe-pcm@11220000 {
+		compatible = "mediatek,mt8173-afe-pcm";
+		power-domains = <&scpsys MT8173_POWER_DOMAIN_AUDIO>;
+	};
-- 
2.1.4


^ permalink raw reply related	[flat|nested] 40+ messages in thread

* [PATCH 1/4] dt-bindings: soc: Add documentation for the MediaTek SCPSYS unit
@ 2015-03-09  8:10   ` Sascha Hauer
  0 siblings, 0 replies; 40+ messages in thread
From: Sascha Hauer @ 2015-03-09  8:10 UTC (permalink / raw)
  To: linux-arm-kernel

This adds documentation for the MediaTek SCPSYS unit found in MT8173 SoCs.

Signed-off-by: Sascha Hauer <s.hauer@pengutronix.de>
---
 .../devicetree/bindings/soc/mediatek/scpsys.txt    | 32 ++++++++++++++++++++++
 1 file changed, 32 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/soc/mediatek/scpsys.txt

diff --git a/Documentation/devicetree/bindings/soc/mediatek/scpsys.txt b/Documentation/devicetree/bindings/soc/mediatek/scpsys.txt
new file mode 100644
index 0000000..4764a03
--- /dev/null
+++ b/Documentation/devicetree/bindings/soc/mediatek/scpsys.txt
@@ -0,0 +1,32 @@
+MediaTek SCPSYS
+===============
+
+The System Control Processor System (SCPSYS) has several power management
+related tasks in the system. The tasks include thermal measurement, dynamic
+voltage frequency scaling (DVFS), interrupt filter and lowlevel sleep control.
+The System Power Manager (SPM) inside the SCPSYS is for the MTCMOS power
+domain control.
+
+The driver implements the Generic PM domain bindings described in
+power/power_domain.txt. It provides the power domains defined in
+include/dt-bindings/power/mt8173-power.h.
+
+Required properties:
+- compatible: Must be "mediatek,mt8173-scpsys"
+- #power-domain-cells: Must be 1
+- reg: Address range of the SCPSYS unit
+
+Example:
+
+	scpsys: scpsys at 10006000 {
+		#power-domain-cells = <1>;
+		compatible = "mediatek,mt8173-scpsys";
+		reg = <0 0x10006000 0 0x1000>;
+	};
+
+Example consumer:
+
+	afe: mt8173-afe-pcm at 11220000 {
+		compatible = "mediatek,mt8173-afe-pcm";
+		power-domains = <&scpsys MT8173_POWER_DOMAIN_AUDIO>;
+	};
-- 
2.1.4

^ permalink raw reply related	[flat|nested] 40+ messages in thread

* [PATCH 2/4] soc: Mediatek: Add SCPSYS power domain driver
  2015-03-09  8:09 ` Sascha Hauer
@ 2015-03-09  8:10   ` Sascha Hauer
  -1 siblings, 0 replies; 40+ messages in thread
From: Sascha Hauer @ 2015-03-09  8:10 UTC (permalink / raw)
  To: linux-arm-kernel
  Cc: devicetree, linux-kernel, Matthias Brugger, linux-mediatek,
	kernel, Sascha Hauer

Signed-off-by: Sascha Hauer <s.hauer@pengutronix.de>
---
 drivers/soc/mediatek/Kconfig             |   6 +
 drivers/soc/mediatek/Makefile            |   1 +
 drivers/soc/mediatek/mtk-scpsys.c        | 398 +++++++++++++++++++++++++++++++
 include/dt-bindings/power/mt8173-power.h |  15 ++
 4 files changed, 420 insertions(+)
 create mode 100644 drivers/soc/mediatek/mtk-scpsys.c
 create mode 100644 include/dt-bindings/power/mt8173-power.h

diff --git a/drivers/soc/mediatek/Kconfig b/drivers/soc/mediatek/Kconfig
index b91665a..4736f5b 100644
--- a/drivers/soc/mediatek/Kconfig
+++ b/drivers/soc/mediatek/Kconfig
@@ -9,3 +9,9 @@ config MTK_PMIC_WRAP
 	  Say yes here to add support for MediaTek PMIC Wrapper found
 	  on the MT8135 and MT8173 SoCs. The PMIC wrapper is a proprietary
 	  hardware to connect the PMIC.
+
+config MTK_SCPSYS
+	tristate "MediaTek SCPSYS Support"
+	help
+	  Say yes here to add support for the MediaTek SCPSYS power domain
+	  driver.
diff --git a/drivers/soc/mediatek/Makefile b/drivers/soc/mediatek/Makefile
index ecaf4de..ce88693 100644
--- a/drivers/soc/mediatek/Makefile
+++ b/drivers/soc/mediatek/Makefile
@@ -1 +1,2 @@
 obj-$(CONFIG_MTK_PMIC_WRAP) += mtk-pmic-wrap.o
+obj-$(CONFIG_MTK_SCPSYS) += mtk-scpsys.o
diff --git a/drivers/soc/mediatek/mtk-scpsys.c b/drivers/soc/mediatek/mtk-scpsys.c
new file mode 100644
index 0000000..8bbd2e8
--- /dev/null
+++ b/drivers/soc/mediatek/mtk-scpsys.c
@@ -0,0 +1,398 @@
+/*
+ * Copyright (c) 2015 Pengutronix, Sascha Hauer <kernel@pengutronix.de>
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+ * GNU General Public License for more details.
+ */
+#include <linux/clk.h>
+#include <linux/io.h>
+#include <linux/kernel.h>
+#include <linux/module.h>
+#include <linux/of_device.h>
+#include <linux/platform_device.h>
+#include <linux/regmap.h>
+#include <linux/pm_domain.h>
+#include <linux/delay.h>
+#include <dt-bindings/power/mt8173-power.h>
+#include <linux/mfd/syscon.h>
+
+#define SPM_VDE_PWR_CON			0x0210
+#define SPM_MFG_PWR_CON			0x0214
+#define SPM_VEN_PWR_CON			0x0230
+#define SPM_ISP_PWR_CON			0x0238
+#define SPM_DIS_PWR_CON			0x023c
+#define SPM_VEN2_PWR_CON		0x0298
+#define SPM_AUDIO_PWR_CON		0x029c
+#define SPM_MFG_2D_PWR_CON		0x02c0
+#define SPM_MFG_ASYNC_PWR_CON		0x02c4
+#define SPM_USB_PWR_CON			0x02cc
+#define SPM_PWR_STATUS			0x060c
+#define SPM_PWR_STATUS_2ND		0x0610
+
+#define PWR_RST_B_BIT			BIT(0)
+#define PWR_ISO_BIT			BIT(1)
+#define PWR_ON_BIT			BIT(2)
+#define PWR_ON_2ND_BIT			BIT(3)
+#define PWR_CLK_DIS_BIT			BIT(4)
+
+#define DIS_PWR_STA_MASK		BIT(3)
+#define MFG_PWR_STA_MASK		BIT(4)
+#define ISP_PWR_STA_MASK		BIT(5)
+#define VDE_PWR_STA_MASK		BIT(7)
+#define VEN2_PWR_STA_MASK		BIT(20)
+#define VEN_PWR_STA_MASK		BIT(21)
+#define MFG_2D_PWR_STA_MASK		BIT(22)
+#define MFG_ASYNC_PWR_STA_MASK		BIT(23)
+#define AUDIO_PWR_STA_MASK		BIT(24)
+#define USB_PWR_STA_MASK		BIT(25)
+
+/*
+ * The Infracfg unit has bus protection bits. We enable the bus protection
+ * for disabled power domains so that the system does not hang when some unit
+ * accesses the bus while in power down.
+ */
+#define INFRA_TOPAXI_PROTECTEN		0x0220
+#define INFRA_TOPAXI_PROTECTSTA1	0x0228
+
+#define TOP_AXI_PROT_EN_MFG_SNOOP_OUT	BIT(23)
+#define TOP_AXI_PROT_EN_MFG_M1		BIT(22)
+#define TOP_AXI_PROT_EN_MFG_M0		BIT(21)
+#define TOP_AXI_PROT_EN_IOMMU		BIT(20)
+#define TOP_AXI_PROT_EN_GCPU		BIT(19)
+#define TOP_AXI_PROT_EN_CQ_DMA		BIT(18)
+#define TOP_AXI_PROT_EN_DEBUGSYS	BIT(17)
+#define TOP_AXI_PROT_EN_PERI_M1		BIT(16)
+#define TOP_AXI_PROT_EN_PERI_M0		BIT(15)
+#define TOP_AXI_PROT_EN_MFG_S		BIT(14)
+#define TOP_AXI_PROT_EN_CCI_M2		BIT(13)
+#define TOP_AXI_PROT_EN_L2SS_ADD	BIT(12)
+#define TOP_AXI_PROT_EN_L2SS_SMI	BIT(11)
+#define TOP_AXI_PROT_EN_L2C_M2		BIT(9)
+#define TOP_AXI_PROT_EN_MMAPB_S		BIT(6)
+#define TOP_AXI_PROT_EN_MM_M1		BIT(2)
+#define TOP_AXI_PROT_EN_MM_M0		BIT(1)
+#define TOP_AXI_PROT_EN_MCI_M2		BIT(0)
+
+struct scp_domain_data {
+	const char *name;
+	u32 sta_mask;
+	int ctl_offs;
+	u32 sram_pdn_bits;
+	u32 sram_pdn_ack_bits;
+	u32 bus_prot_mask;
+	int id;
+};
+
+static struct scp_domain_data scp_domain_data[] = {
+	{
+		.id = MT8173_POWER_DOMAIN_VDE,
+		.name = "vde",
+		.sta_mask = VDE_PWR_STA_MASK,
+		.ctl_offs = SPM_VDE_PWR_CON,
+		.sram_pdn_bits = GENMASK(11, 8),
+		.sram_pdn_ack_bits = GENMASK(12, 12),
+	}, {
+		.id = MT8173_POWER_DOMAIN_MFG,
+		.name = "mfg",
+		.sta_mask = MFG_PWR_STA_MASK,
+		.ctl_offs = SPM_MFG_PWR_CON,
+		.sram_pdn_bits = GENMASK(13, 8),
+		.sram_pdn_ack_bits = GENMASK(21, 16),
+		.bus_prot_mask = TOP_AXI_PROT_EN_MFG_S | TOP_AXI_PROT_EN_MFG_M0 |
+			TOP_AXI_PROT_EN_MFG_M1 | TOP_AXI_PROT_EN_MFG_SNOOP_OUT,
+	}, {
+		.id = MT8173_POWER_DOMAIN_VEN,
+		.name = "ven",
+		.sta_mask = VEN_PWR_STA_MASK,
+		.ctl_offs = SPM_VEN_PWR_CON,
+		.sram_pdn_bits = GENMASK(11, 8),
+		.sram_pdn_ack_bits = GENMASK(15, 12),
+	}, {
+		.id = MT8173_POWER_DOMAIN_ISP,
+		.name = "isp",
+		.sta_mask = ISP_PWR_STA_MASK,
+		.ctl_offs = SPM_ISP_PWR_CON,
+		.sram_pdn_bits = GENMASK(11, 8),
+		.sram_pdn_ack_bits = GENMASK(13, 12),
+	}, {
+		.id = MT8173_POWER_DOMAIN_DIS,
+		.name = "dis",
+		.sta_mask = DIS_PWR_STA_MASK,
+		.ctl_offs = SPM_DIS_PWR_CON,
+		.sram_pdn_bits = GENMASK(11, 8),
+		.sram_pdn_ack_bits = GENMASK(12, 12),
+		.bus_prot_mask = TOP_AXI_PROT_EN_MM_M0 | TOP_AXI_PROT_EN_MM_M1,
+	}, {
+		.id = MT8173_POWER_DOMAIN_VEN2,
+		.name = "ven2",
+		.sta_mask = VEN2_PWR_STA_MASK,
+		.ctl_offs = SPM_VEN2_PWR_CON,
+		.sram_pdn_bits = GENMASK(11, 8),
+		.sram_pdn_ack_bits = GENMASK(15, 12),
+	}, {
+		.id = MT8173_POWER_DOMAIN_AUDIO,
+		.name = "audio",
+		.sta_mask = AUDIO_PWR_STA_MASK,
+		.ctl_offs = SPM_AUDIO_PWR_CON,
+		.sram_pdn_bits = GENMASK(11, 8),
+		.sram_pdn_ack_bits = GENMASK(15, 12),
+	}, {
+		.id = MT8173_POWER_DOMAIN_MFG_2D,
+		.name = "mfg_2d",
+		.sta_mask = MFG_2D_PWR_STA_MASK,
+		.ctl_offs = SPM_MFG_2D_PWR_CON,
+		.sram_pdn_bits = GENMASK(11, 8),
+		.sram_pdn_ack_bits = GENMASK(13, 12),
+	}, {
+		.id = MT8173_POWER_DOMAIN_MFG_ASYNC,
+		.name = "mfg_async",
+		.sta_mask = MFG_ASYNC_PWR_STA_MASK,
+		.ctl_offs = SPM_MFG_ASYNC_PWR_CON,
+		.sram_pdn_bits = GENMASK(11, 8),
+		.sram_pdn_ack_bits = 0,
+	}, {
+		.id = MT8173_POWER_DOMAIN_USB,
+		.name = "usb",
+		.sta_mask = USB_PWR_STA_MASK,
+		.ctl_offs = SPM_USB_PWR_CON,
+		.sram_pdn_bits = GENMASK(11, 8),
+		.sram_pdn_ack_bits = GENMASK(15, 12),
+	},
+};
+
+#define NUM_DOMAINS	ARRAY_SIZE(scp_domain_data)
+
+struct scp;
+
+struct scp_domain {
+	struct generic_pm_domain pmd;
+	struct scp_domain_data *data;
+	struct scp *scp;
+};
+
+struct scp {
+	struct scp_domain domains[NUM_DOMAINS];
+	struct generic_pm_domain *pmd[NUM_DOMAINS];
+	struct genpd_onecell_data pd_data;
+	void __iomem *base;
+	struct regmap *infracfg;
+};
+
+static int scpsys_power_on(struct generic_pm_domain *genpd)
+{
+	struct scp_domain *scpd = container_of(genpd, struct scp_domain, pmd);
+	struct scp *scp = scpd->scp;
+	struct scp_domain_data *data = scpd->data;
+	unsigned long expired;
+	void __iomem *ctl_addr = scpd->scp->base + data->ctl_offs;
+	u32 sram_pdn_ack = data->sram_pdn_ack_bits;
+	u32 val;
+	int ret;
+
+	val = readl(ctl_addr);
+	val |= PWR_ON_BIT;
+	writel(val, ctl_addr);
+	val |= PWR_ON_2ND_BIT;
+	writel(val, ctl_addr);
+
+	/* wait until PWR_ACK = 1 */
+	expired = jiffies + HZ;
+	while (!(readl(scp->base + SPM_PWR_STATUS) & data->sta_mask) ||
+			!(readl(scp->base + SPM_PWR_STATUS_2ND) & data->sta_mask)) {
+		cpu_relax();
+		if (time_after(jiffies, expired))
+			return -EIO;
+	}
+
+	val &= ~PWR_CLK_DIS_BIT;
+	writel(val, ctl_addr);
+
+	val &= ~PWR_ISO_BIT;
+	writel(val, ctl_addr);
+
+	val |= PWR_RST_B_BIT;
+	writel(val, ctl_addr);
+
+	val &= ~data->sram_pdn_bits;
+	writel(val, ctl_addr);
+
+	/* wait until SRAM_PDN_ACK all 0 */
+	expired = jiffies + HZ;
+	while (sram_pdn_ack && (readl(ctl_addr) & sram_pdn_ack)) {
+		cpu_relax();
+		if (time_after(jiffies, expired))
+			return -EIO;
+	}
+
+	/* Clear bus protection bits */
+	if (data->bus_prot_mask) {
+		u32 mask = data->bus_prot_mask;
+		struct regmap *infracfg = scp->infracfg;
+
+		regmap_update_bits(infracfg, INFRA_TOPAXI_PROTECTEN, mask, 0);
+
+		expired = jiffies + HZ;
+
+		while (1) {
+			u32 val;
+
+			ret = regmap_read(infracfg, INFRA_TOPAXI_PROTECTSTA1, &val);
+			if (ret)
+				return ret;
+
+			if (!(val & mask))
+				break;
+
+			cpu_relax();
+			if (time_after(jiffies, expired))
+				return -EIO;
+		}
+	}
+
+	return 0;
+}
+
+static int scpsys_power_off(struct generic_pm_domain *genpd)
+{
+	struct scp_domain *scpd = container_of(genpd, struct scp_domain, pmd);
+	struct scp *scp = scpd->scp;
+	struct scp_domain_data *data = scpd->data;
+	unsigned long expired;
+	void __iomem *ctl_addr = scpd->scp->base + data->ctl_offs;
+	u32 sram_pdn_ack = data->sram_pdn_ack_bits;
+	u32 val;
+	int ret;
+
+	/* set bus protection bits */
+	if (data->bus_prot_mask) {
+		struct regmap *infracfg = scp->infracfg;
+		u32 mask = data->bus_prot_mask;
+
+		regmap_update_bits(infracfg, INFRA_TOPAXI_PROTECTEN, mask, mask);
+
+		expired = jiffies + HZ;
+
+		while (1) {
+			ret = regmap_read(infracfg, INFRA_TOPAXI_PROTECTSTA1, &val);
+			if (ret)
+				return ret;
+
+			if ((val & mask) == mask)
+				break;
+
+			cpu_relax();
+			if (time_after(jiffies, expired))
+				return -EIO;
+		}
+	}
+
+	val = readl(ctl_addr);
+	val |= data->sram_pdn_bits;
+	writel(val, ctl_addr);
+
+	/* wait until SRAM_PDN_ACK all 1 */
+	expired = jiffies + HZ;
+	while ((readl(ctl_addr) & sram_pdn_ack) != sram_pdn_ack) {
+		cpu_relax();
+		if (time_after(jiffies, expired))
+			return -EIO;
+	}
+
+	val |= PWR_ISO_BIT;
+	writel(val, ctl_addr);
+
+	val &= ~PWR_RST_B_BIT;
+	writel(val, ctl_addr);
+
+	val |= PWR_CLK_DIS_BIT;
+	writel(val, ctl_addr);
+
+	val &= ~PWR_ON_BIT;
+	writel(val, ctl_addr);
+
+	val &= ~PWR_ON_2ND_BIT;
+	writel(val, ctl_addr);
+
+	/* wait until PWR_ACK = 0 */
+	expired = jiffies + HZ;
+	while ((readl(scp->base + SPM_PWR_STATUS) & data->sta_mask) ||
+			(readl(scp->base + SPM_PWR_STATUS_2ND) & data->sta_mask)) {
+		cpu_relax();
+		if (time_after(jiffies, expired))
+			return -EIO;
+	}
+
+	return 0;
+}
+
+static int scpsys_probe(struct platform_device *pdev)
+{
+	struct genpd_onecell_data *pd_data;
+	struct resource *res;
+	int i;
+	struct scp *scp = devm_kzalloc(&pdev->dev, sizeof(*scp), GFP_KERNEL);
+
+	res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
+	scp->base = devm_ioremap_resource(&pdev->dev, res);
+	if (IS_ERR(scp->base))
+		return PTR_ERR(scp->base);
+
+	pd_data = &scp->pd_data;
+
+	scp->infracfg = syscon_regmap_lookup_by_compatible("mediatek,mt8173-infracfg");
+	if (IS_ERR(scp->infracfg))
+		return PTR_ERR(scp->infracfg);
+
+	pd_data->domains = scp->pmd;
+	pd_data->num_domains = NUM_DOMAINS;
+
+	for (i = 0; i < NUM_DOMAINS; i++) {
+		struct scp_domain *scpd = &scp->domains[i];
+		struct generic_pm_domain *pmd = &scpd->pmd;
+
+		scp->pmd[i] = pmd;
+		scpd->data = &scp_domain_data[i];
+		scpd->scp = scp;
+
+		pmd->name = scp_domain_data[i].name;
+		pmd->power_off = scpsys_power_off;
+		pmd->power_on = scpsys_power_on;
+		pmd->power_off_latency_ns = 20000;
+		pmd->power_on_latency_ns = 20000;
+
+		pd_data->domains[i] = pmd;
+		pm_genpd_init(pmd, NULL, 1);
+	}
+
+	return of_genpd_add_provider_onecell(pdev->dev.of_node, pd_data);
+}
+
+static struct of_device_id of_scpsys_match_tbl[] = {
+	{
+		.compatible = "mediatek,mt8173-scpsys",
+	}, {
+		/* sentinel */
+	}
+};
+MODULE_DEVICE_TABLE(of, of_scpsys_match_tbl);
+
+static struct platform_driver scpsys_drv = {
+	.driver = {
+		.name = "mtk-scpsys",
+		.owner = THIS_MODULE,
+		.of_match_table = of_match_ptr(of_scpsys_match_tbl),
+	},
+	.probe = scpsys_probe,
+};
+
+module_platform_driver(scpsys_drv);
+
+MODULE_AUTHOR("Sascha Hauer, Pengutronix");
+MODULE_DESCRIPTION("MediaTek MT8173 scpsys driver");
+MODULE_LICENSE("GPL");
diff --git a/include/dt-bindings/power/mt8173-power.h b/include/dt-bindings/power/mt8173-power.h
new file mode 100644
index 0000000..88715f2
--- /dev/null
+++ b/include/dt-bindings/power/mt8173-power.h
@@ -0,0 +1,15 @@
+#ifndef _DT_BINDINGS_POWER_MT8183_POWER_H
+#define _DT_BINDINGS_POWER_MT8183_POWER_H
+
+#define MT8173_POWER_DOMAIN_VDE		0
+#define MT8173_POWER_DOMAIN_MFG		1
+#define MT8173_POWER_DOMAIN_VEN		2
+#define MT8173_POWER_DOMAIN_ISP		3
+#define MT8173_POWER_DOMAIN_DIS		4
+#define MT8173_POWER_DOMAIN_VEN2	5
+#define MT8173_POWER_DOMAIN_AUDIO	6
+#define MT8173_POWER_DOMAIN_MFG_2D	7
+#define MT8173_POWER_DOMAIN_MFG_ASYNC	8
+#define MT8173_POWER_DOMAIN_USB		9
+
+#endif /* _DT_BINDINGS_POWER_MT8183_POWER_H */
-- 
2.1.4


^ permalink raw reply related	[flat|nested] 40+ messages in thread

* [PATCH 2/4] soc: Mediatek: Add SCPSYS power domain driver
@ 2015-03-09  8:10   ` Sascha Hauer
  0 siblings, 0 replies; 40+ messages in thread
From: Sascha Hauer @ 2015-03-09  8:10 UTC (permalink / raw)
  To: linux-arm-kernel

Signed-off-by: Sascha Hauer <s.hauer@pengutronix.de>
---
 drivers/soc/mediatek/Kconfig             |   6 +
 drivers/soc/mediatek/Makefile            |   1 +
 drivers/soc/mediatek/mtk-scpsys.c        | 398 +++++++++++++++++++++++++++++++
 include/dt-bindings/power/mt8173-power.h |  15 ++
 4 files changed, 420 insertions(+)
 create mode 100644 drivers/soc/mediatek/mtk-scpsys.c
 create mode 100644 include/dt-bindings/power/mt8173-power.h

diff --git a/drivers/soc/mediatek/Kconfig b/drivers/soc/mediatek/Kconfig
index b91665a..4736f5b 100644
--- a/drivers/soc/mediatek/Kconfig
+++ b/drivers/soc/mediatek/Kconfig
@@ -9,3 +9,9 @@ config MTK_PMIC_WRAP
 	  Say yes here to add support for MediaTek PMIC Wrapper found
 	  on the MT8135 and MT8173 SoCs. The PMIC wrapper is a proprietary
 	  hardware to connect the PMIC.
+
+config MTK_SCPSYS
+	tristate "MediaTek SCPSYS Support"
+	help
+	  Say yes here to add support for the MediaTek SCPSYS power domain
+	  driver.
diff --git a/drivers/soc/mediatek/Makefile b/drivers/soc/mediatek/Makefile
index ecaf4de..ce88693 100644
--- a/drivers/soc/mediatek/Makefile
+++ b/drivers/soc/mediatek/Makefile
@@ -1 +1,2 @@
 obj-$(CONFIG_MTK_PMIC_WRAP) += mtk-pmic-wrap.o
+obj-$(CONFIG_MTK_SCPSYS) += mtk-scpsys.o
diff --git a/drivers/soc/mediatek/mtk-scpsys.c b/drivers/soc/mediatek/mtk-scpsys.c
new file mode 100644
index 0000000..8bbd2e8
--- /dev/null
+++ b/drivers/soc/mediatek/mtk-scpsys.c
@@ -0,0 +1,398 @@
+/*
+ * Copyright (c) 2015 Pengutronix, Sascha Hauer <kernel@pengutronix.de>
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+ * GNU General Public License for more details.
+ */
+#include <linux/clk.h>
+#include <linux/io.h>
+#include <linux/kernel.h>
+#include <linux/module.h>
+#include <linux/of_device.h>
+#include <linux/platform_device.h>
+#include <linux/regmap.h>
+#include <linux/pm_domain.h>
+#include <linux/delay.h>
+#include <dt-bindings/power/mt8173-power.h>
+#include <linux/mfd/syscon.h>
+
+#define SPM_VDE_PWR_CON			0x0210
+#define SPM_MFG_PWR_CON			0x0214
+#define SPM_VEN_PWR_CON			0x0230
+#define SPM_ISP_PWR_CON			0x0238
+#define SPM_DIS_PWR_CON			0x023c
+#define SPM_VEN2_PWR_CON		0x0298
+#define SPM_AUDIO_PWR_CON		0x029c
+#define SPM_MFG_2D_PWR_CON		0x02c0
+#define SPM_MFG_ASYNC_PWR_CON		0x02c4
+#define SPM_USB_PWR_CON			0x02cc
+#define SPM_PWR_STATUS			0x060c
+#define SPM_PWR_STATUS_2ND		0x0610
+
+#define PWR_RST_B_BIT			BIT(0)
+#define PWR_ISO_BIT			BIT(1)
+#define PWR_ON_BIT			BIT(2)
+#define PWR_ON_2ND_BIT			BIT(3)
+#define PWR_CLK_DIS_BIT			BIT(4)
+
+#define DIS_PWR_STA_MASK		BIT(3)
+#define MFG_PWR_STA_MASK		BIT(4)
+#define ISP_PWR_STA_MASK		BIT(5)
+#define VDE_PWR_STA_MASK		BIT(7)
+#define VEN2_PWR_STA_MASK		BIT(20)
+#define VEN_PWR_STA_MASK		BIT(21)
+#define MFG_2D_PWR_STA_MASK		BIT(22)
+#define MFG_ASYNC_PWR_STA_MASK		BIT(23)
+#define AUDIO_PWR_STA_MASK		BIT(24)
+#define USB_PWR_STA_MASK		BIT(25)
+
+/*
+ * The Infracfg unit has bus protection bits. We enable the bus protection
+ * for disabled power domains so that the system does not hang when some unit
+ * accesses the bus while in power down.
+ */
+#define INFRA_TOPAXI_PROTECTEN		0x0220
+#define INFRA_TOPAXI_PROTECTSTA1	0x0228
+
+#define TOP_AXI_PROT_EN_MFG_SNOOP_OUT	BIT(23)
+#define TOP_AXI_PROT_EN_MFG_M1		BIT(22)
+#define TOP_AXI_PROT_EN_MFG_M0		BIT(21)
+#define TOP_AXI_PROT_EN_IOMMU		BIT(20)
+#define TOP_AXI_PROT_EN_GCPU		BIT(19)
+#define TOP_AXI_PROT_EN_CQ_DMA		BIT(18)
+#define TOP_AXI_PROT_EN_DEBUGSYS	BIT(17)
+#define TOP_AXI_PROT_EN_PERI_M1		BIT(16)
+#define TOP_AXI_PROT_EN_PERI_M0		BIT(15)
+#define TOP_AXI_PROT_EN_MFG_S		BIT(14)
+#define TOP_AXI_PROT_EN_CCI_M2		BIT(13)
+#define TOP_AXI_PROT_EN_L2SS_ADD	BIT(12)
+#define TOP_AXI_PROT_EN_L2SS_SMI	BIT(11)
+#define TOP_AXI_PROT_EN_L2C_M2		BIT(9)
+#define TOP_AXI_PROT_EN_MMAPB_S		BIT(6)
+#define TOP_AXI_PROT_EN_MM_M1		BIT(2)
+#define TOP_AXI_PROT_EN_MM_M0		BIT(1)
+#define TOP_AXI_PROT_EN_MCI_M2		BIT(0)
+
+struct scp_domain_data {
+	const char *name;
+	u32 sta_mask;
+	int ctl_offs;
+	u32 sram_pdn_bits;
+	u32 sram_pdn_ack_bits;
+	u32 bus_prot_mask;
+	int id;
+};
+
+static struct scp_domain_data scp_domain_data[] = {
+	{
+		.id = MT8173_POWER_DOMAIN_VDE,
+		.name = "vde",
+		.sta_mask = VDE_PWR_STA_MASK,
+		.ctl_offs = SPM_VDE_PWR_CON,
+		.sram_pdn_bits = GENMASK(11, 8),
+		.sram_pdn_ack_bits = GENMASK(12, 12),
+	}, {
+		.id = MT8173_POWER_DOMAIN_MFG,
+		.name = "mfg",
+		.sta_mask = MFG_PWR_STA_MASK,
+		.ctl_offs = SPM_MFG_PWR_CON,
+		.sram_pdn_bits = GENMASK(13, 8),
+		.sram_pdn_ack_bits = GENMASK(21, 16),
+		.bus_prot_mask = TOP_AXI_PROT_EN_MFG_S | TOP_AXI_PROT_EN_MFG_M0 |
+			TOP_AXI_PROT_EN_MFG_M1 | TOP_AXI_PROT_EN_MFG_SNOOP_OUT,
+	}, {
+		.id = MT8173_POWER_DOMAIN_VEN,
+		.name = "ven",
+		.sta_mask = VEN_PWR_STA_MASK,
+		.ctl_offs = SPM_VEN_PWR_CON,
+		.sram_pdn_bits = GENMASK(11, 8),
+		.sram_pdn_ack_bits = GENMASK(15, 12),
+	}, {
+		.id = MT8173_POWER_DOMAIN_ISP,
+		.name = "isp",
+		.sta_mask = ISP_PWR_STA_MASK,
+		.ctl_offs = SPM_ISP_PWR_CON,
+		.sram_pdn_bits = GENMASK(11, 8),
+		.sram_pdn_ack_bits = GENMASK(13, 12),
+	}, {
+		.id = MT8173_POWER_DOMAIN_DIS,
+		.name = "dis",
+		.sta_mask = DIS_PWR_STA_MASK,
+		.ctl_offs = SPM_DIS_PWR_CON,
+		.sram_pdn_bits = GENMASK(11, 8),
+		.sram_pdn_ack_bits = GENMASK(12, 12),
+		.bus_prot_mask = TOP_AXI_PROT_EN_MM_M0 | TOP_AXI_PROT_EN_MM_M1,
+	}, {
+		.id = MT8173_POWER_DOMAIN_VEN2,
+		.name = "ven2",
+		.sta_mask = VEN2_PWR_STA_MASK,
+		.ctl_offs = SPM_VEN2_PWR_CON,
+		.sram_pdn_bits = GENMASK(11, 8),
+		.sram_pdn_ack_bits = GENMASK(15, 12),
+	}, {
+		.id = MT8173_POWER_DOMAIN_AUDIO,
+		.name = "audio",
+		.sta_mask = AUDIO_PWR_STA_MASK,
+		.ctl_offs = SPM_AUDIO_PWR_CON,
+		.sram_pdn_bits = GENMASK(11, 8),
+		.sram_pdn_ack_bits = GENMASK(15, 12),
+	}, {
+		.id = MT8173_POWER_DOMAIN_MFG_2D,
+		.name = "mfg_2d",
+		.sta_mask = MFG_2D_PWR_STA_MASK,
+		.ctl_offs = SPM_MFG_2D_PWR_CON,
+		.sram_pdn_bits = GENMASK(11, 8),
+		.sram_pdn_ack_bits = GENMASK(13, 12),
+	}, {
+		.id = MT8173_POWER_DOMAIN_MFG_ASYNC,
+		.name = "mfg_async",
+		.sta_mask = MFG_ASYNC_PWR_STA_MASK,
+		.ctl_offs = SPM_MFG_ASYNC_PWR_CON,
+		.sram_pdn_bits = GENMASK(11, 8),
+		.sram_pdn_ack_bits = 0,
+	}, {
+		.id = MT8173_POWER_DOMAIN_USB,
+		.name = "usb",
+		.sta_mask = USB_PWR_STA_MASK,
+		.ctl_offs = SPM_USB_PWR_CON,
+		.sram_pdn_bits = GENMASK(11, 8),
+		.sram_pdn_ack_bits = GENMASK(15, 12),
+	},
+};
+
+#define NUM_DOMAINS	ARRAY_SIZE(scp_domain_data)
+
+struct scp;
+
+struct scp_domain {
+	struct generic_pm_domain pmd;
+	struct scp_domain_data *data;
+	struct scp *scp;
+};
+
+struct scp {
+	struct scp_domain domains[NUM_DOMAINS];
+	struct generic_pm_domain *pmd[NUM_DOMAINS];
+	struct genpd_onecell_data pd_data;
+	void __iomem *base;
+	struct regmap *infracfg;
+};
+
+static int scpsys_power_on(struct generic_pm_domain *genpd)
+{
+	struct scp_domain *scpd = container_of(genpd, struct scp_domain, pmd);
+	struct scp *scp = scpd->scp;
+	struct scp_domain_data *data = scpd->data;
+	unsigned long expired;
+	void __iomem *ctl_addr = scpd->scp->base + data->ctl_offs;
+	u32 sram_pdn_ack = data->sram_pdn_ack_bits;
+	u32 val;
+	int ret;
+
+	val = readl(ctl_addr);
+	val |= PWR_ON_BIT;
+	writel(val, ctl_addr);
+	val |= PWR_ON_2ND_BIT;
+	writel(val, ctl_addr);
+
+	/* wait until PWR_ACK = 1 */
+	expired = jiffies + HZ;
+	while (!(readl(scp->base + SPM_PWR_STATUS) & data->sta_mask) ||
+			!(readl(scp->base + SPM_PWR_STATUS_2ND) & data->sta_mask)) {
+		cpu_relax();
+		if (time_after(jiffies, expired))
+			return -EIO;
+	}
+
+	val &= ~PWR_CLK_DIS_BIT;
+	writel(val, ctl_addr);
+
+	val &= ~PWR_ISO_BIT;
+	writel(val, ctl_addr);
+
+	val |= PWR_RST_B_BIT;
+	writel(val, ctl_addr);
+
+	val &= ~data->sram_pdn_bits;
+	writel(val, ctl_addr);
+
+	/* wait until SRAM_PDN_ACK all 0 */
+	expired = jiffies + HZ;
+	while (sram_pdn_ack && (readl(ctl_addr) & sram_pdn_ack)) {
+		cpu_relax();
+		if (time_after(jiffies, expired))
+			return -EIO;
+	}
+
+	/* Clear bus protection bits */
+	if (data->bus_prot_mask) {
+		u32 mask = data->bus_prot_mask;
+		struct regmap *infracfg = scp->infracfg;
+
+		regmap_update_bits(infracfg, INFRA_TOPAXI_PROTECTEN, mask, 0);
+
+		expired = jiffies + HZ;
+
+		while (1) {
+			u32 val;
+
+			ret = regmap_read(infracfg, INFRA_TOPAXI_PROTECTSTA1, &val);
+			if (ret)
+				return ret;
+
+			if (!(val & mask))
+				break;
+
+			cpu_relax();
+			if (time_after(jiffies, expired))
+				return -EIO;
+		}
+	}
+
+	return 0;
+}
+
+static int scpsys_power_off(struct generic_pm_domain *genpd)
+{
+	struct scp_domain *scpd = container_of(genpd, struct scp_domain, pmd);
+	struct scp *scp = scpd->scp;
+	struct scp_domain_data *data = scpd->data;
+	unsigned long expired;
+	void __iomem *ctl_addr = scpd->scp->base + data->ctl_offs;
+	u32 sram_pdn_ack = data->sram_pdn_ack_bits;
+	u32 val;
+	int ret;
+
+	/* set bus protection bits */
+	if (data->bus_prot_mask) {
+		struct regmap *infracfg = scp->infracfg;
+		u32 mask = data->bus_prot_mask;
+
+		regmap_update_bits(infracfg, INFRA_TOPAXI_PROTECTEN, mask, mask);
+
+		expired = jiffies + HZ;
+
+		while (1) {
+			ret = regmap_read(infracfg, INFRA_TOPAXI_PROTECTSTA1, &val);
+			if (ret)
+				return ret;
+
+			if ((val & mask) == mask)
+				break;
+
+			cpu_relax();
+			if (time_after(jiffies, expired))
+				return -EIO;
+		}
+	}
+
+	val = readl(ctl_addr);
+	val |= data->sram_pdn_bits;
+	writel(val, ctl_addr);
+
+	/* wait until SRAM_PDN_ACK all 1 */
+	expired = jiffies + HZ;
+	while ((readl(ctl_addr) & sram_pdn_ack) != sram_pdn_ack) {
+		cpu_relax();
+		if (time_after(jiffies, expired))
+			return -EIO;
+	}
+
+	val |= PWR_ISO_BIT;
+	writel(val, ctl_addr);
+
+	val &= ~PWR_RST_B_BIT;
+	writel(val, ctl_addr);
+
+	val |= PWR_CLK_DIS_BIT;
+	writel(val, ctl_addr);
+
+	val &= ~PWR_ON_BIT;
+	writel(val, ctl_addr);
+
+	val &= ~PWR_ON_2ND_BIT;
+	writel(val, ctl_addr);
+
+	/* wait until PWR_ACK = 0 */
+	expired = jiffies + HZ;
+	while ((readl(scp->base + SPM_PWR_STATUS) & data->sta_mask) ||
+			(readl(scp->base + SPM_PWR_STATUS_2ND) & data->sta_mask)) {
+		cpu_relax();
+		if (time_after(jiffies, expired))
+			return -EIO;
+	}
+
+	return 0;
+}
+
+static int scpsys_probe(struct platform_device *pdev)
+{
+	struct genpd_onecell_data *pd_data;
+	struct resource *res;
+	int i;
+	struct scp *scp = devm_kzalloc(&pdev->dev, sizeof(*scp), GFP_KERNEL);
+
+	res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
+	scp->base = devm_ioremap_resource(&pdev->dev, res);
+	if (IS_ERR(scp->base))
+		return PTR_ERR(scp->base);
+
+	pd_data = &scp->pd_data;
+
+	scp->infracfg = syscon_regmap_lookup_by_compatible("mediatek,mt8173-infracfg");
+	if (IS_ERR(scp->infracfg))
+		return PTR_ERR(scp->infracfg);
+
+	pd_data->domains = scp->pmd;
+	pd_data->num_domains = NUM_DOMAINS;
+
+	for (i = 0; i < NUM_DOMAINS; i++) {
+		struct scp_domain *scpd = &scp->domains[i];
+		struct generic_pm_domain *pmd = &scpd->pmd;
+
+		scp->pmd[i] = pmd;
+		scpd->data = &scp_domain_data[i];
+		scpd->scp = scp;
+
+		pmd->name = scp_domain_data[i].name;
+		pmd->power_off = scpsys_power_off;
+		pmd->power_on = scpsys_power_on;
+		pmd->power_off_latency_ns = 20000;
+		pmd->power_on_latency_ns = 20000;
+
+		pd_data->domains[i] = pmd;
+		pm_genpd_init(pmd, NULL, 1);
+	}
+
+	return of_genpd_add_provider_onecell(pdev->dev.of_node, pd_data);
+}
+
+static struct of_device_id of_scpsys_match_tbl[] = {
+	{
+		.compatible = "mediatek,mt8173-scpsys",
+	}, {
+		/* sentinel */
+	}
+};
+MODULE_DEVICE_TABLE(of, of_scpsys_match_tbl);
+
+static struct platform_driver scpsys_drv = {
+	.driver = {
+		.name = "mtk-scpsys",
+		.owner = THIS_MODULE,
+		.of_match_table = of_match_ptr(of_scpsys_match_tbl),
+	},
+	.probe = scpsys_probe,
+};
+
+module_platform_driver(scpsys_drv);
+
+MODULE_AUTHOR("Sascha Hauer, Pengutronix");
+MODULE_DESCRIPTION("MediaTek MT8173 scpsys driver");
+MODULE_LICENSE("GPL");
diff --git a/include/dt-bindings/power/mt8173-power.h b/include/dt-bindings/power/mt8173-power.h
new file mode 100644
index 0000000..88715f2
--- /dev/null
+++ b/include/dt-bindings/power/mt8173-power.h
@@ -0,0 +1,15 @@
+#ifndef _DT_BINDINGS_POWER_MT8183_POWER_H
+#define _DT_BINDINGS_POWER_MT8183_POWER_H
+
+#define MT8173_POWER_DOMAIN_VDE		0
+#define MT8173_POWER_DOMAIN_MFG		1
+#define MT8173_POWER_DOMAIN_VEN		2
+#define MT8173_POWER_DOMAIN_ISP		3
+#define MT8173_POWER_DOMAIN_DIS		4
+#define MT8173_POWER_DOMAIN_VEN2	5
+#define MT8173_POWER_DOMAIN_AUDIO	6
+#define MT8173_POWER_DOMAIN_MFG_2D	7
+#define MT8173_POWER_DOMAIN_MFG_ASYNC	8
+#define MT8173_POWER_DOMAIN_USB		9
+
+#endif /* _DT_BINDINGS_POWER_MT8183_POWER_H */
-- 
2.1.4

^ permalink raw reply related	[flat|nested] 40+ messages in thread

* [PATCH 3/4] ARM64: MediaTek: Add generic pm domain support
@ 2015-03-09  8:10   ` Sascha Hauer
  0 siblings, 0 replies; 40+ messages in thread
From: Sascha Hauer @ 2015-03-09  8:10 UTC (permalink / raw)
  To: linux-arm-kernel
  Cc: devicetree, linux-kernel, Matthias Brugger, linux-mediatek,
	kernel, Sascha Hauer

Enable support for generic power domains in the config.

Signed-off-by: Sascha Hauer <s.hauer@pengutronix.de>
---
 arch/arm64/Kconfig | 1 +
 1 file changed, 1 insertion(+)

diff --git a/arch/arm64/Kconfig b/arch/arm64/Kconfig
index 1b8e973..aef77d2 100644
--- a/arch/arm64/Kconfig
+++ b/arch/arm64/Kconfig
@@ -174,6 +174,7 @@ config ARCH_FSL_LS2085A
 config ARCH_MEDIATEK
 	bool "Mediatek MT65xx & MT81xx ARMv8 SoC"
 	select ARM_GIC
+	select PM_GENERIC_DOMAINS if PM
 	help
 	  Support for Mediatek MT65xx & MT81xx ARMv8 SoCs
 
-- 
2.1.4


^ permalink raw reply related	[flat|nested] 40+ messages in thread

* [PATCH 3/4] ARM64: MediaTek: Add generic pm domain support
@ 2015-03-09  8:10   ` Sascha Hauer
  0 siblings, 0 replies; 40+ messages in thread
From: Sascha Hauer @ 2015-03-09  8:10 UTC (permalink / raw)
  To: linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r
  Cc: devicetree-u79uwXL29TY76Z2rM5mHXA,
	linux-kernel-u79uwXL29TY76Z2rM5mHXA, Matthias Brugger,
	linux-mediatek-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
	kernel-bIcnvbaLZ9MEGnE8C9+IrQ, Sascha Hauer

Enable support for generic power domains in the config.

Signed-off-by: Sascha Hauer <s.hauer-bIcnvbaLZ9MEGnE8C9+IrQ@public.gmane.org>
---
 arch/arm64/Kconfig | 1 +
 1 file changed, 1 insertion(+)

diff --git a/arch/arm64/Kconfig b/arch/arm64/Kconfig
index 1b8e973..aef77d2 100644
--- a/arch/arm64/Kconfig
+++ b/arch/arm64/Kconfig
@@ -174,6 +174,7 @@ config ARCH_FSL_LS2085A
 config ARCH_MEDIATEK
 	bool "Mediatek MT65xx & MT81xx ARMv8 SoC"
 	select ARM_GIC
+	select PM_GENERIC_DOMAINS if PM
 	help
 	  Support for Mediatek MT65xx & MT81xx ARMv8 SoCs
 
-- 
2.1.4

--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

^ permalink raw reply related	[flat|nested] 40+ messages in thread

* [PATCH 3/4] ARM64: MediaTek: Add generic pm domain support
@ 2015-03-09  8:10   ` Sascha Hauer
  0 siblings, 0 replies; 40+ messages in thread
From: Sascha Hauer @ 2015-03-09  8:10 UTC (permalink / raw)
  To: linux-arm-kernel

Enable support for generic power domains in the config.

Signed-off-by: Sascha Hauer <s.hauer@pengutronix.de>
---
 arch/arm64/Kconfig | 1 +
 1 file changed, 1 insertion(+)

diff --git a/arch/arm64/Kconfig b/arch/arm64/Kconfig
index 1b8e973..aef77d2 100644
--- a/arch/arm64/Kconfig
+++ b/arch/arm64/Kconfig
@@ -174,6 +174,7 @@ config ARCH_FSL_LS2085A
 config ARCH_MEDIATEK
 	bool "Mediatek MT65xx & MT81xx ARMv8 SoC"
 	select ARM_GIC
+	select PM_GENERIC_DOMAINS if PM
 	help
 	  Support for Mediatek MT65xx & MT81xx ARMv8 SoCs
 
-- 
2.1.4

^ permalink raw reply related	[flat|nested] 40+ messages in thread

* [PATCH 4/4] ARM64: MediaTek MT8173: Add SCPSYS device node
@ 2015-03-09  8:10   ` Sascha Hauer
  0 siblings, 0 replies; 40+ messages in thread
From: Sascha Hauer @ 2015-03-09  8:10 UTC (permalink / raw)
  To: linux-arm-kernel
  Cc: devicetree, linux-kernel, Matthias Brugger, linux-mediatek,
	kernel, Sascha Hauer

This adds the SCPSYS device node to the MT8173 dtsi file.

Signed-off-by: Sascha Hauer <s.hauer@pengutronix.de>
---
 arch/arm64/boot/dts/mediatek/mt8173.dtsi | 6 ++++++
 1 file changed, 6 insertions(+)

diff --git a/arch/arm64/boot/dts/mediatek/mt8173.dtsi b/arch/arm64/boot/dts/mediatek/mt8173.dtsi
index 8554ec3..9fa64ac 100644
--- a/arch/arm64/boot/dts/mediatek/mt8173.dtsi
+++ b/arch/arm64/boot/dts/mediatek/mt8173.dtsi
@@ -105,6 +105,12 @@
 		compatible = "simple-bus";
 		ranges;
 
+		scpsys: scpsys@10006000 {
+			compatible = "mediatek,mt8173-scpsys";
+			#power-domain-cells = <1>;
+			reg = <0 0x10006000 0 0x1000>;
+		};
+
 		sysirq: intpol-controller@10200620 {
 			compatible = "mediatek,mt8173-sysirq",
 					"mediatek,mt6577-sysirq";
-- 
2.1.4


^ permalink raw reply related	[flat|nested] 40+ messages in thread

* [PATCH 4/4] ARM64: MediaTek MT8173: Add SCPSYS device node
@ 2015-03-09  8:10   ` Sascha Hauer
  0 siblings, 0 replies; 40+ messages in thread
From: Sascha Hauer @ 2015-03-09  8:10 UTC (permalink / raw)
  To: linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r
  Cc: devicetree-u79uwXL29TY76Z2rM5mHXA,
	linux-kernel-u79uwXL29TY76Z2rM5mHXA, Matthias Brugger,
	linux-mediatek-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
	kernel-bIcnvbaLZ9MEGnE8C9+IrQ, Sascha Hauer

This adds the SCPSYS device node to the MT8173 dtsi file.

Signed-off-by: Sascha Hauer <s.hauer-bIcnvbaLZ9MEGnE8C9+IrQ@public.gmane.org>
---
 arch/arm64/boot/dts/mediatek/mt8173.dtsi | 6 ++++++
 1 file changed, 6 insertions(+)

diff --git a/arch/arm64/boot/dts/mediatek/mt8173.dtsi b/arch/arm64/boot/dts/mediatek/mt8173.dtsi
index 8554ec3..9fa64ac 100644
--- a/arch/arm64/boot/dts/mediatek/mt8173.dtsi
+++ b/arch/arm64/boot/dts/mediatek/mt8173.dtsi
@@ -105,6 +105,12 @@
 		compatible = "simple-bus";
 		ranges;
 
+		scpsys: scpsys@10006000 {
+			compatible = "mediatek,mt8173-scpsys";
+			#power-domain-cells = <1>;
+			reg = <0 0x10006000 0 0x1000>;
+		};
+
 		sysirq: intpol-controller@10200620 {
 			compatible = "mediatek,mt8173-sysirq",
 					"mediatek,mt6577-sysirq";
-- 
2.1.4

--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

^ permalink raw reply related	[flat|nested] 40+ messages in thread

* [PATCH 4/4] ARM64: MediaTek MT8173: Add SCPSYS device node
@ 2015-03-09  8:10   ` Sascha Hauer
  0 siblings, 0 replies; 40+ messages in thread
From: Sascha Hauer @ 2015-03-09  8:10 UTC (permalink / raw)
  To: linux-arm-kernel

This adds the SCPSYS device node to the MT8173 dtsi file.

Signed-off-by: Sascha Hauer <s.hauer@pengutronix.de>
---
 arch/arm64/boot/dts/mediatek/mt8173.dtsi | 6 ++++++
 1 file changed, 6 insertions(+)

diff --git a/arch/arm64/boot/dts/mediatek/mt8173.dtsi b/arch/arm64/boot/dts/mediatek/mt8173.dtsi
index 8554ec3..9fa64ac 100644
--- a/arch/arm64/boot/dts/mediatek/mt8173.dtsi
+++ b/arch/arm64/boot/dts/mediatek/mt8173.dtsi
@@ -105,6 +105,12 @@
 		compatible = "simple-bus";
 		ranges;
 
+		scpsys: scpsys at 10006000 {
+			compatible = "mediatek,mt8173-scpsys";
+			#power-domain-cells = <1>;
+			reg = <0 0x10006000 0 0x1000>;
+		};
+
 		sysirq: intpol-controller at 10200620 {
 			compatible = "mediatek,mt8173-sysirq",
 					"mediatek,mt6577-sysirq";
-- 
2.1.4

^ permalink raw reply related	[flat|nested] 40+ messages in thread

* Re: [RFC] Mediatek SCPSYS power domain support
  2015-03-09  8:09 ` Sascha Hauer
@ 2015-03-09 20:43   ` Kevin Hilman
  -1 siblings, 0 replies; 40+ messages in thread
From: Kevin Hilman @ 2015-03-09 20:43 UTC (permalink / raw)
  To: Sascha Hauer
  Cc: linux-arm-kernel, devicetree, linux-kernel, Matthias Brugger,
	linux-mediatek, kernel

Sascha Hauer <s.hauer@pengutronix.de> writes:

> s series adds support for the MediaTek SCPSYS unit.
>
> The SCPSYS unit handles several power management related tasks such
> as thermal measurement, DVFS, interrupt filter and low level sleep
> control.
>
> The initial support only contains the generic power domain handling.
> This is needed to turn on power to the different power domains.
>
> The driver is quite straight forward now. Due to the lack of a better
> place I have put it to drivers/soc/mediatek. As the SCPSYS unit has
> several other tasks that also do not fit into some specific subsystem
> this probably is a good place for this driver.
>
> What is not clear to me is how the Kconfig dependencies should be
> handled. Some domains are disabled by bootloader default, so without
> this driver for example sound won't work. So should PM, PM_GENERIC_DOMAINS
> and this driver be made mandatory for MT8173? Or should this driver
> when PM is disabled be compiled as a stub which only enables all
> domains? I don't have a good idea how things should work out here.

IMO, a stub that enables all the domains is what you want.

Kevin

^ permalink raw reply	[flat|nested] 40+ messages in thread

* [RFC] Mediatek SCPSYS power domain support
@ 2015-03-09 20:43   ` Kevin Hilman
  0 siblings, 0 replies; 40+ messages in thread
From: Kevin Hilman @ 2015-03-09 20:43 UTC (permalink / raw)
  To: linux-arm-kernel

Sascha Hauer <s.hauer@pengutronix.de> writes:

> s series adds support for the MediaTek SCPSYS unit.
>
> The SCPSYS unit handles several power management related tasks such
> as thermal measurement, DVFS, interrupt filter and low level sleep
> control.
>
> The initial support only contains the generic power domain handling.
> This is needed to turn on power to the different power domains.
>
> The driver is quite straight forward now. Due to the lack of a better
> place I have put it to drivers/soc/mediatek. As the SCPSYS unit has
> several other tasks that also do not fit into some specific subsystem
> this probably is a good place for this driver.
>
> What is not clear to me is how the Kconfig dependencies should be
> handled. Some domains are disabled by bootloader default, so without
> this driver for example sound won't work. So should PM, PM_GENERIC_DOMAINS
> and this driver be made mandatory for MT8173? Or should this driver
> when PM is disabled be compiled as a stub which only enables all
> domains? I don't have a good idea how things should work out here.

IMO, a stub that enables all the domains is what you want.

Kevin

^ permalink raw reply	[flat|nested] 40+ messages in thread

* Re: [PATCH 1/4] dt-bindings: soc: Add documentation for the MediaTek SCPSYS unit
  2015-03-09  8:10   ` Sascha Hauer
@ 2015-03-09 20:46     ` Kevin Hilman
  -1 siblings, 0 replies; 40+ messages in thread
From: Kevin Hilman @ 2015-03-09 20:46 UTC (permalink / raw)
  To: Sascha Hauer
  Cc: linux-arm-kernel, devicetree, linux-kernel, Matthias Brugger,
	linux-mediatek, kernel

Sascha Hauer <s.hauer@pengutronix.de> writes:

> This adds documentation for the MediaTek SCPSYS unit found in MT8173 SoCs.

Curious if this IP unique to the 8173?  or maybe also used on 8135? ...

> Signed-off-by: Sascha Hauer <s.hauer@pengutronix.de>
> ---
>  .../devicetree/bindings/soc/mediatek/scpsys.txt    | 32 ++++++++++++++++++++++
>  1 file changed, 32 insertions(+)
>  create mode 100644 Documentation/devicetree/bindings/soc/mediatek/scpsys.txt
>
> diff --git a/Documentation/devicetree/bindings/soc/mediatek/scpsys.txt b/Documentation/devicetree/bindings/soc/mediatek/scpsys.txt
> new file mode 100644
> index 0000000..4764a03
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/soc/mediatek/scpsys.txt
> @@ -0,0 +1,32 @@
> +MediaTek SCPSYS
> +===============
> +
> +The System Control Processor System (SCPSYS) has several power management
> +related tasks in the system. The tasks include thermal measurement, dynamic
> +voltage frequency scaling (DVFS), interrupt filter and lowlevel sleep control.
> +The System Power Manager (SPM) inside the SCPSYS is for the MTCMOS power
> +domain control.
> +
> +The driver implements the Generic PM domain bindings described in
> +power/power_domain.txt. It provides the power domains defined in
> +include/dt-bindings/power/mt8173-power.h.
> +
> +Required properties:
> +- compatible: Must be "mediatek,mt8173-scpsys"

... if so, maybe the compatible could/should be slightly more generic?

Kevin


^ permalink raw reply	[flat|nested] 40+ messages in thread

* [PATCH 1/4] dt-bindings: soc: Add documentation for the MediaTek SCPSYS unit
@ 2015-03-09 20:46     ` Kevin Hilman
  0 siblings, 0 replies; 40+ messages in thread
From: Kevin Hilman @ 2015-03-09 20:46 UTC (permalink / raw)
  To: linux-arm-kernel

Sascha Hauer <s.hauer@pengutronix.de> writes:

> This adds documentation for the MediaTek SCPSYS unit found in MT8173 SoCs.

Curious if this IP unique to the 8173?  or maybe also used on 8135? ...

> Signed-off-by: Sascha Hauer <s.hauer@pengutronix.de>
> ---
>  .../devicetree/bindings/soc/mediatek/scpsys.txt    | 32 ++++++++++++++++++++++
>  1 file changed, 32 insertions(+)
>  create mode 100644 Documentation/devicetree/bindings/soc/mediatek/scpsys.txt
>
> diff --git a/Documentation/devicetree/bindings/soc/mediatek/scpsys.txt b/Documentation/devicetree/bindings/soc/mediatek/scpsys.txt
> new file mode 100644
> index 0000000..4764a03
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/soc/mediatek/scpsys.txt
> @@ -0,0 +1,32 @@
> +MediaTek SCPSYS
> +===============
> +
> +The System Control Processor System (SCPSYS) has several power management
> +related tasks in the system. The tasks include thermal measurement, dynamic
> +voltage frequency scaling (DVFS), interrupt filter and lowlevel sleep control.
> +The System Power Manager (SPM) inside the SCPSYS is for the MTCMOS power
> +domain control.
> +
> +The driver implements the Generic PM domain bindings described in
> +power/power_domain.txt. It provides the power domains defined in
> +include/dt-bindings/power/mt8173-power.h.
> +
> +Required properties:
> +- compatible: Must be "mediatek,mt8173-scpsys"

... if so, maybe the compatible could/should be slightly more generic?

Kevin

^ permalink raw reply	[flat|nested] 40+ messages in thread

* Re: [PATCH 2/4] soc: Mediatek: Add SCPSYS power domain driver
  2015-03-09  8:10   ` Sascha Hauer
@ 2015-03-09 21:35     ` Kevin Hilman
  -1 siblings, 0 replies; 40+ messages in thread
From: Kevin Hilman @ 2015-03-09 21:35 UTC (permalink / raw)
  To: Sascha Hauer
  Cc: linux-arm-kernel, devicetree, linux-kernel, Matthias Brugger,
	linux-mediatek, kernel

Sascha Hauer <s.hauer@pengutronix.de> writes:

> Signed-off-by: Sascha Hauer <s.hauer@pengutronix.de>

A bit of a changelog here would be useful describing this driver, that
it's only covering part of the device (e.g. power controller) with more
to come, dependency on the syscon driver, etc.

> ---
>  drivers/soc/mediatek/Kconfig             |   6 +
>  drivers/soc/mediatek/Makefile            |   1 +
>  drivers/soc/mediatek/mtk-scpsys.c        | 398 +++++++++++++++++++++++++++++++
>  include/dt-bindings/power/mt8173-power.h |  15 ++
>  4 files changed, 420 insertions(+)
>  create mode 100644 drivers/soc/mediatek/mtk-scpsys.c
>  create mode 100644 include/dt-bindings/power/mt8173-power.h
>
> diff --git a/drivers/soc/mediatek/Kconfig b/drivers/soc/mediatek/Kconfig
> index b91665a..4736f5b 100644
> --- a/drivers/soc/mediatek/Kconfig
> +++ b/drivers/soc/mediatek/Kconfig
> @@ -9,3 +9,9 @@ config MTK_PMIC_WRAP
>  	  Say yes here to add support for MediaTek PMIC Wrapper found
>  	  on the MT8135 and MT8173 SoCs. The PMIC wrapper is a proprietary
>  	  hardware to connect the PMIC.
> +
> +config MTK_SCPSYS
> +	tristate "MediaTek SCPSYS Support"
> +	help
> +	  Say yes here to add support for the MediaTek SCPSYS power domain
> +	  driver.
> diff --git a/drivers/soc/mediatek/Makefile b/drivers/soc/mediatek/Makefile
> index ecaf4de..ce88693 100644
> --- a/drivers/soc/mediatek/Makefile
> +++ b/drivers/soc/mediatek/Makefile
> @@ -1 +1,2 @@
>  obj-$(CONFIG_MTK_PMIC_WRAP) += mtk-pmic-wrap.o
> +obj-$(CONFIG_MTK_SCPSYS) += mtk-scpsys.o
> diff --git a/drivers/soc/mediatek/mtk-scpsys.c b/drivers/soc/mediatek/mtk-scpsys.c
> new file mode 100644
> index 0000000..8bbd2e8
> --- /dev/null
> +++ b/drivers/soc/mediatek/mtk-scpsys.c
> @@ -0,0 +1,398 @@
> +/*
> + * Copyright (c) 2015 Pengutronix, Sascha Hauer <kernel@pengutronix.de>
> + *
> + * This program is free software; you can redistribute it and/or modify
> + * it under the terms of the GNU General Public License version 2 as
> + * published by the Free Software Foundation.
> + *
> + * This program is distributed in the hope that it will be useful,
> + * but WITHOUT ANY WARRANTY; without even the implied warranty of
> + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
> + * GNU General Public License for more details.
> + */
> +#include <linux/clk.h>
> +#include <linux/io.h>
> +#include <linux/kernel.h>
> +#include <linux/module.h>
> +#include <linux/of_device.h>
> +#include <linux/platform_device.h>
> +#include <linux/regmap.h>
> +#include <linux/pm_domain.h>
> +#include <linux/delay.h>
> +#include <dt-bindings/power/mt8173-power.h>
> +#include <linux/mfd/syscon.h>
> +
> +#define SPM_VDE_PWR_CON			0x0210
> +#define SPM_MFG_PWR_CON			0x0214
> +#define SPM_VEN_PWR_CON			0x0230
> +#define SPM_ISP_PWR_CON			0x0238
> +#define SPM_DIS_PWR_CON			0x023c
> +#define SPM_VEN2_PWR_CON		0x0298
> +#define SPM_AUDIO_PWR_CON		0x029c
> +#define SPM_MFG_2D_PWR_CON		0x02c0
> +#define SPM_MFG_ASYNC_PWR_CON		0x02c4
> +#define SPM_USB_PWR_CON			0x02cc
> +#define SPM_PWR_STATUS			0x060c
> +#define SPM_PWR_STATUS_2ND		0x0610
> +
> +#define PWR_RST_B_BIT			BIT(0)
> +#define PWR_ISO_BIT			BIT(1)
> +#define PWR_ON_BIT			BIT(2)
> +#define PWR_ON_2ND_BIT			BIT(3)
> +#define PWR_CLK_DIS_BIT			BIT(4)
> +
> +#define DIS_PWR_STA_MASK		BIT(3)
> +#define MFG_PWR_STA_MASK		BIT(4)
> +#define ISP_PWR_STA_MASK		BIT(5)
> +#define VDE_PWR_STA_MASK		BIT(7)
> +#define VEN2_PWR_STA_MASK		BIT(20)
> +#define VEN_PWR_STA_MASK		BIT(21)
> +#define MFG_2D_PWR_STA_MASK		BIT(22)
> +#define MFG_ASYNC_PWR_STA_MASK		BIT(23)
> +#define AUDIO_PWR_STA_MASK		BIT(24)
> +#define USB_PWR_STA_MASK		BIT(25)
> +
> +/*
> + * The Infracfg unit has bus protection bits. We enable the bus protection
> + * for disabled power domains so that the system does not hang when some unit
> + * accesses the bus while in power down.
> + */

Hmm, why don't you want to know if some device is accessing another
device which is in a domain that is powered down?   Seems like this is a
good way to hide real bugs.

> +#define INFRA_TOPAXI_PROTECTEN		0x0220
> +#define INFRA_TOPAXI_PROTECTSTA1	0x0228
> +
> +#define TOP_AXI_PROT_EN_MFG_SNOOP_OUT	BIT(23)
> +#define TOP_AXI_PROT_EN_MFG_M1		BIT(22)
> +#define TOP_AXI_PROT_EN_MFG_M0		BIT(21)
> +#define TOP_AXI_PROT_EN_IOMMU		BIT(20)
> +#define TOP_AXI_PROT_EN_GCPU		BIT(19)
> +#define TOP_AXI_PROT_EN_CQ_DMA		BIT(18)
> +#define TOP_AXI_PROT_EN_DEBUGSYS	BIT(17)
> +#define TOP_AXI_PROT_EN_PERI_M1		BIT(16)
> +#define TOP_AXI_PROT_EN_PERI_M0		BIT(15)
> +#define TOP_AXI_PROT_EN_MFG_S		BIT(14)
> +#define TOP_AXI_PROT_EN_CCI_M2		BIT(13)
> +#define TOP_AXI_PROT_EN_L2SS_ADD	BIT(12)
> +#define TOP_AXI_PROT_EN_L2SS_SMI	BIT(11)
> +#define TOP_AXI_PROT_EN_L2C_M2		BIT(9)
> +#define TOP_AXI_PROT_EN_MMAPB_S		BIT(6)
> +#define TOP_AXI_PROT_EN_MM_M1		BIT(2)
> +#define TOP_AXI_PROT_EN_MM_M0		BIT(1)
> +#define TOP_AXI_PROT_EN_MCI_M2		BIT(0)
> +
> +struct scp_domain_data {
> +	const char *name;
> +	u32 sta_mask;
> +	int ctl_offs;
> +	u32 sram_pdn_bits;
> +	u32 sram_pdn_ack_bits;
> +	u32 bus_prot_mask;
> +	int id;
> +};
> +
> +static struct scp_domain_data scp_domain_data[] = {
> +	{
> +		.id = MT8173_POWER_DOMAIN_VDE,
> +		.name = "vde",
> +		.sta_mask = VDE_PWR_STA_MASK,
> +		.ctl_offs = SPM_VDE_PWR_CON,
> +		.sram_pdn_bits = GENMASK(11, 8),
> +		.sram_pdn_ack_bits = GENMASK(12, 12),
> +	}, {
> +		.id = MT8173_POWER_DOMAIN_MFG,
> +		.name = "mfg",
> +		.sta_mask = MFG_PWR_STA_MASK,
> +		.ctl_offs = SPM_MFG_PWR_CON,
> +		.sram_pdn_bits = GENMASK(13, 8),
> +		.sram_pdn_ack_bits = GENMASK(21, 16),
> +		.bus_prot_mask = TOP_AXI_PROT_EN_MFG_S | TOP_AXI_PROT_EN_MFG_M0 |
> +			TOP_AXI_PROT_EN_MFG_M1 | TOP_AXI_PROT_EN_MFG_SNOOP_OUT,
> +	}, {
> +		.id = MT8173_POWER_DOMAIN_VEN,
> +		.name = "ven",
> +		.sta_mask = VEN_PWR_STA_MASK,
> +		.ctl_offs = SPM_VEN_PWR_CON,
> +		.sram_pdn_bits = GENMASK(11, 8),
> +		.sram_pdn_ack_bits = GENMASK(15, 12),
> +	}, {
> +		.id = MT8173_POWER_DOMAIN_ISP,
> +		.name = "isp",
> +		.sta_mask = ISP_PWR_STA_MASK,
> +		.ctl_offs = SPM_ISP_PWR_CON,
> +		.sram_pdn_bits = GENMASK(11, 8),
> +		.sram_pdn_ack_bits = GENMASK(13, 12),
> +	}, {
> +		.id = MT8173_POWER_DOMAIN_DIS,
> +		.name = "dis",
> +		.sta_mask = DIS_PWR_STA_MASK,
> +		.ctl_offs = SPM_DIS_PWR_CON,
> +		.sram_pdn_bits = GENMASK(11, 8),
> +		.sram_pdn_ack_bits = GENMASK(12, 12),
> +		.bus_prot_mask = TOP_AXI_PROT_EN_MM_M0 | TOP_AXI_PROT_EN_MM_M1,
> +	}, {
> +		.id = MT8173_POWER_DOMAIN_VEN2,
> +		.name = "ven2",
> +		.sta_mask = VEN2_PWR_STA_MASK,
> +		.ctl_offs = SPM_VEN2_PWR_CON,
> +		.sram_pdn_bits = GENMASK(11, 8),
> +		.sram_pdn_ack_bits = GENMASK(15, 12),
> +	}, {
> +		.id = MT8173_POWER_DOMAIN_AUDIO,
> +		.name = "audio",
> +		.sta_mask = AUDIO_PWR_STA_MASK,
> +		.ctl_offs = SPM_AUDIO_PWR_CON,
> +		.sram_pdn_bits = GENMASK(11, 8),
> +		.sram_pdn_ack_bits = GENMASK(15, 12),
> +	}, {
> +		.id = MT8173_POWER_DOMAIN_MFG_2D,
> +		.name = "mfg_2d",
> +		.sta_mask = MFG_2D_PWR_STA_MASK,
> +		.ctl_offs = SPM_MFG_2D_PWR_CON,
> +		.sram_pdn_bits = GENMASK(11, 8),
> +		.sram_pdn_ack_bits = GENMASK(13, 12),
> +	}, {
> +		.id = MT8173_POWER_DOMAIN_MFG_ASYNC,
> +		.name = "mfg_async",
> +		.sta_mask = MFG_ASYNC_PWR_STA_MASK,
> +		.ctl_offs = SPM_MFG_ASYNC_PWR_CON,
> +		.sram_pdn_bits = GENMASK(11, 8),
> +		.sram_pdn_ack_bits = 0,
> +	}, {
> +		.id = MT8173_POWER_DOMAIN_USB,
> +		.name = "usb",
> +		.sta_mask = USB_PWR_STA_MASK,
> +		.ctl_offs = SPM_USB_PWR_CON,
> +		.sram_pdn_bits = GENMASK(11, 8),
> +		.sram_pdn_ack_bits = GENMASK(15, 12),
> +	},
> +};
> +
> +#define NUM_DOMAINS	ARRAY_SIZE(scp_domain_data)
> +
> +struct scp;
> +
> +struct scp_domain {
> +	struct generic_pm_domain pmd;
> +	struct scp_domain_data *data;
> +	struct scp *scp;
> +};
> +
> +struct scp {
> +	struct scp_domain domains[NUM_DOMAINS];
> +	struct generic_pm_domain *pmd[NUM_DOMAINS];
> +	struct genpd_onecell_data pd_data;
> +	void __iomem *base;
> +	struct regmap *infracfg;
> +};
> +
> +static int scpsys_power_on(struct generic_pm_domain *genpd)
> +{
> +	struct scp_domain *scpd = container_of(genpd, struct scp_domain, pmd);
> +	struct scp *scp = scpd->scp;
> +	struct scp_domain_data *data = scpd->data;
> +	unsigned long expired;
> +	void __iomem *ctl_addr = scpd->scp->base + data->ctl_offs;
> +	u32 sram_pdn_ack = data->sram_pdn_ack_bits;
> +	u32 val;
> +	int ret;
> +
> +	val = readl(ctl_addr);
> +	val |= PWR_ON_BIT;
> +	writel(val, ctl_addr);
> +	val |= PWR_ON_2ND_BIT;
> +	writel(val, ctl_addr);
> +
> +	/* wait until PWR_ACK = 1 */
> +	expired = jiffies + HZ;
> +	while (!(readl(scp->base + SPM_PWR_STATUS) & data->sta_mask) ||
> +			!(readl(scp->base + SPM_PWR_STATUS_2ND) & data->sta_mask)) {
> +		cpu_relax();
> +		if (time_after(jiffies, expired))
> +			return -EIO;

hmm, seems like you'd want a dev_warn() or simliar here if this times
out and fails.  There's a bunch of these below too.

> +	}
> +
> +	val &= ~PWR_CLK_DIS_BIT;
> +	writel(val, ctl_addr);
> +
> +	val &= ~PWR_ISO_BIT;
> +	writel(val, ctl_addr);
> +
> +	val |= PWR_RST_B_BIT;
> +	writel(val, ctl_addr);
> +
> +	val &= ~data->sram_pdn_bits;
> +	writel(val, ctl_addr);
> +
> +	/* wait until SRAM_PDN_ACK all 0 */
> +	expired = jiffies + HZ;
> +	while (sram_pdn_ack && (readl(ctl_addr) & sram_pdn_ack)) {
> +		cpu_relax();
> +		if (time_after(jiffies, expired))
> +			return -EIO;
> +	}
> +
> +	/* Clear bus protection bits */
> +	if (data->bus_prot_mask) {
> +		u32 mask = data->bus_prot_mask;
> +		struct regmap *infracfg = scp->infracfg;
> +
> +		regmap_update_bits(infracfg, INFRA_TOPAXI_PROTECTEN, mask, 0);
> +
> +		expired = jiffies + HZ;
> +
> +		while (1) {
> +			u32 val;
> +
> +			ret = regmap_read(infracfg, INFRA_TOPAXI_PROTECTSTA1, &val);
> +			if (ret)
> +				return ret;
> +
> +			if (!(val & mask))
> +				break;
> +
> +			cpu_relax();
> +			if (time_after(jiffies, expired))
> +				return -EIO;
> +		}
> +	}

This whole "Clear bus protection bits" part seems like it should be an
API in the infracfg driver.

> +	return 0;
> +}
> +
> +static int scpsys_power_off(struct generic_pm_domain *genpd)
> +{
> +	struct scp_domain *scpd = container_of(genpd, struct scp_domain, pmd);
> +	struct scp *scp = scpd->scp;
> +	struct scp_domain_data *data = scpd->data;
> +	unsigned long expired;
> +	void __iomem *ctl_addr = scpd->scp->base + data->ctl_offs;
> +	u32 sram_pdn_ack = data->sram_pdn_ack_bits;
> +	u32 val;
> +	int ret;
> +
> +	/* set bus protection bits */
> +	if (data->bus_prot_mask) {
> +		struct regmap *infracfg = scp->infracfg;
> +		u32 mask = data->bus_prot_mask;
> +
> +		regmap_update_bits(infracfg, INFRA_TOPAXI_PROTECTEN, mask, mask);
> +
> +		expired = jiffies + HZ;
> +
> +		while (1) {
> +			ret = regmap_read(infracfg, INFRA_TOPAXI_PROTECTSTA1, &val);
> +			if (ret)
> +				return ret;
> +
> +			if ((val & mask) == mask)
> +				break;
> +
> +			cpu_relax();
> +			if (time_after(jiffies, expired))
> +				return -EIO;
> +		}
> +	}

As with the 'clear bus protection bits', seems like this should be a
call into the infracfg driver.

> +	val = readl(ctl_addr);
> +	val |= data->sram_pdn_bits;
> +	writel(val, ctl_addr);
> +
> +	/* wait until SRAM_PDN_ACK all 1 */
> +	expired = jiffies + HZ;
> +	while ((readl(ctl_addr) & sram_pdn_ack) != sram_pdn_ack) {
> +		cpu_relax();
> +		if (time_after(jiffies, expired))
> +			return -EIO;
> +	}
> +
> +	val |= PWR_ISO_BIT;
> +	writel(val, ctl_addr);
> +
> +	val &= ~PWR_RST_B_BIT;
> +	writel(val, ctl_addr);
> +
> +	val |= PWR_CLK_DIS_BIT;
> +	writel(val, ctl_addr);
> +
> +	val &= ~PWR_ON_BIT;
> +	writel(val, ctl_addr);
> +
> +	val &= ~PWR_ON_2ND_BIT;
> +	writel(val, ctl_addr);
> +
> +	/* wait until PWR_ACK = 0 */
> +	expired = jiffies + HZ;
> +	while ((readl(scp->base + SPM_PWR_STATUS) & data->sta_mask) ||
> +			(readl(scp->base + SPM_PWR_STATUS_2ND) & data->sta_mask)) {
> +		cpu_relax();
> +		if (time_after(jiffies, expired))
> +			return -EIO;
> +	}
> +
> +	return 0;
> +}
> +
> +static int scpsys_probe(struct platform_device *pdev)
> +{
> +	struct genpd_onecell_data *pd_data;
> +	struct resource *res;
> +	int i;
> +	struct scp *scp = devm_kzalloc(&pdev->dev, sizeof(*scp), GFP_KERNEL);

This might return NULL...

> +	res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
> +	scp->base = devm_ioremap_resource(&pdev->dev, res);

... and, boom.

> +	if (IS_ERR(scp->base))
> +		return PTR_ERR(scp->base);
> +
> +	pd_data = &scp->pd_data;
> +
> +	scp->infracfg = syscon_regmap_lookup_by_compatible("mediatek,mt8173-infracfg");
> +	if (IS_ERR(scp->infracfg))
> +		return PTR_ERR(scp->infracfg);
> +
> +	pd_data->domains = scp->pmd;
> +	pd_data->num_domains = NUM_DOMAINS;
> +
> +	for (i = 0; i < NUM_DOMAINS; i++) {
> +		struct scp_domain *scpd = &scp->domains[i];
> +		struct generic_pm_domain *pmd = &scpd->pmd;
> +
> +		scp->pmd[i] = pmd;
> +		scpd->data = &scp_domain_data[i];
> +		scpd->scp = scp;
> +
> +		pmd->name = scp_domain_data[i].name;
> +		pmd->power_off = scpsys_power_off;
> +		pmd->power_on = scpsys_power_on;
> +		pmd->power_off_latency_ns = 20000;
> +		pmd->power_on_latency_ns = 20000;

Are the latencies for all domains really the same?   Seems like the
latencies should be part of the per-domain data.

Where did these numbers come from?  HW specs, measurement, etc?

Also, eventually, these latencies can (and should) come from DT
after the support from Geert[1] is merged, so putting them in the data
struct for now

> +		pd_data->domains[i] = pmd;
> +		pm_genpd_init(pmd, NULL, 1);
> +	}
> +
> +	return of_genpd_add_provider_onecell(pdev->dev.of_node, pd_data);
> +}
> +
> +static struct of_device_id of_scpsys_match_tbl[] = {
> +	{
> +		.compatible = "mediatek,mt8173-scpsys",
> +	}, {
> +		/* sentinel */
> +	}
> +};
> +MODULE_DEVICE_TABLE(of, of_scpsys_match_tbl);
> +
> +static struct platform_driver scpsys_drv = {
> +	.driver = {
> +		.name = "mtk-scpsys",
> +		.owner = THIS_MODULE,
> +		.of_match_table = of_match_ptr(of_scpsys_match_tbl),
> +	},
> +	.probe = scpsys_probe,
> +};
> +
> +module_platform_driver(scpsys_drv);

Kevin

[1] https://lkml.org/lkml/2014/11/17/270

^ permalink raw reply	[flat|nested] 40+ messages in thread

* [PATCH 2/4] soc: Mediatek: Add SCPSYS power domain driver
@ 2015-03-09 21:35     ` Kevin Hilman
  0 siblings, 0 replies; 40+ messages in thread
From: Kevin Hilman @ 2015-03-09 21:35 UTC (permalink / raw)
  To: linux-arm-kernel

Sascha Hauer <s.hauer@pengutronix.de> writes:

> Signed-off-by: Sascha Hauer <s.hauer@pengutronix.de>

A bit of a changelog here would be useful describing this driver, that
it's only covering part of the device (e.g. power controller) with more
to come, dependency on the syscon driver, etc.

> ---
>  drivers/soc/mediatek/Kconfig             |   6 +
>  drivers/soc/mediatek/Makefile            |   1 +
>  drivers/soc/mediatek/mtk-scpsys.c        | 398 +++++++++++++++++++++++++++++++
>  include/dt-bindings/power/mt8173-power.h |  15 ++
>  4 files changed, 420 insertions(+)
>  create mode 100644 drivers/soc/mediatek/mtk-scpsys.c
>  create mode 100644 include/dt-bindings/power/mt8173-power.h
>
> diff --git a/drivers/soc/mediatek/Kconfig b/drivers/soc/mediatek/Kconfig
> index b91665a..4736f5b 100644
> --- a/drivers/soc/mediatek/Kconfig
> +++ b/drivers/soc/mediatek/Kconfig
> @@ -9,3 +9,9 @@ config MTK_PMIC_WRAP
>  	  Say yes here to add support for MediaTek PMIC Wrapper found
>  	  on the MT8135 and MT8173 SoCs. The PMIC wrapper is a proprietary
>  	  hardware to connect the PMIC.
> +
> +config MTK_SCPSYS
> +	tristate "MediaTek SCPSYS Support"
> +	help
> +	  Say yes here to add support for the MediaTek SCPSYS power domain
> +	  driver.
> diff --git a/drivers/soc/mediatek/Makefile b/drivers/soc/mediatek/Makefile
> index ecaf4de..ce88693 100644
> --- a/drivers/soc/mediatek/Makefile
> +++ b/drivers/soc/mediatek/Makefile
> @@ -1 +1,2 @@
>  obj-$(CONFIG_MTK_PMIC_WRAP) += mtk-pmic-wrap.o
> +obj-$(CONFIG_MTK_SCPSYS) += mtk-scpsys.o
> diff --git a/drivers/soc/mediatek/mtk-scpsys.c b/drivers/soc/mediatek/mtk-scpsys.c
> new file mode 100644
> index 0000000..8bbd2e8
> --- /dev/null
> +++ b/drivers/soc/mediatek/mtk-scpsys.c
> @@ -0,0 +1,398 @@
> +/*
> + * Copyright (c) 2015 Pengutronix, Sascha Hauer <kernel@pengutronix.de>
> + *
> + * This program is free software; you can redistribute it and/or modify
> + * it under the terms of the GNU General Public License version 2 as
> + * published by the Free Software Foundation.
> + *
> + * This program is distributed in the hope that it will be useful,
> + * but WITHOUT ANY WARRANTY; without even the implied warranty of
> + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
> + * GNU General Public License for more details.
> + */
> +#include <linux/clk.h>
> +#include <linux/io.h>
> +#include <linux/kernel.h>
> +#include <linux/module.h>
> +#include <linux/of_device.h>
> +#include <linux/platform_device.h>
> +#include <linux/regmap.h>
> +#include <linux/pm_domain.h>
> +#include <linux/delay.h>
> +#include <dt-bindings/power/mt8173-power.h>
> +#include <linux/mfd/syscon.h>
> +
> +#define SPM_VDE_PWR_CON			0x0210
> +#define SPM_MFG_PWR_CON			0x0214
> +#define SPM_VEN_PWR_CON			0x0230
> +#define SPM_ISP_PWR_CON			0x0238
> +#define SPM_DIS_PWR_CON			0x023c
> +#define SPM_VEN2_PWR_CON		0x0298
> +#define SPM_AUDIO_PWR_CON		0x029c
> +#define SPM_MFG_2D_PWR_CON		0x02c0
> +#define SPM_MFG_ASYNC_PWR_CON		0x02c4
> +#define SPM_USB_PWR_CON			0x02cc
> +#define SPM_PWR_STATUS			0x060c
> +#define SPM_PWR_STATUS_2ND		0x0610
> +
> +#define PWR_RST_B_BIT			BIT(0)
> +#define PWR_ISO_BIT			BIT(1)
> +#define PWR_ON_BIT			BIT(2)
> +#define PWR_ON_2ND_BIT			BIT(3)
> +#define PWR_CLK_DIS_BIT			BIT(4)
> +
> +#define DIS_PWR_STA_MASK		BIT(3)
> +#define MFG_PWR_STA_MASK		BIT(4)
> +#define ISP_PWR_STA_MASK		BIT(5)
> +#define VDE_PWR_STA_MASK		BIT(7)
> +#define VEN2_PWR_STA_MASK		BIT(20)
> +#define VEN_PWR_STA_MASK		BIT(21)
> +#define MFG_2D_PWR_STA_MASK		BIT(22)
> +#define MFG_ASYNC_PWR_STA_MASK		BIT(23)
> +#define AUDIO_PWR_STA_MASK		BIT(24)
> +#define USB_PWR_STA_MASK		BIT(25)
> +
> +/*
> + * The Infracfg unit has bus protection bits. We enable the bus protection
> + * for disabled power domains so that the system does not hang when some unit
> + * accesses the bus while in power down.
> + */

Hmm, why don't you want to know if some device is accessing another
device which is in a domain that is powered down?   Seems like this is a
good way to hide real bugs.

> +#define INFRA_TOPAXI_PROTECTEN		0x0220
> +#define INFRA_TOPAXI_PROTECTSTA1	0x0228
> +
> +#define TOP_AXI_PROT_EN_MFG_SNOOP_OUT	BIT(23)
> +#define TOP_AXI_PROT_EN_MFG_M1		BIT(22)
> +#define TOP_AXI_PROT_EN_MFG_M0		BIT(21)
> +#define TOP_AXI_PROT_EN_IOMMU		BIT(20)
> +#define TOP_AXI_PROT_EN_GCPU		BIT(19)
> +#define TOP_AXI_PROT_EN_CQ_DMA		BIT(18)
> +#define TOP_AXI_PROT_EN_DEBUGSYS	BIT(17)
> +#define TOP_AXI_PROT_EN_PERI_M1		BIT(16)
> +#define TOP_AXI_PROT_EN_PERI_M0		BIT(15)
> +#define TOP_AXI_PROT_EN_MFG_S		BIT(14)
> +#define TOP_AXI_PROT_EN_CCI_M2		BIT(13)
> +#define TOP_AXI_PROT_EN_L2SS_ADD	BIT(12)
> +#define TOP_AXI_PROT_EN_L2SS_SMI	BIT(11)
> +#define TOP_AXI_PROT_EN_L2C_M2		BIT(9)
> +#define TOP_AXI_PROT_EN_MMAPB_S		BIT(6)
> +#define TOP_AXI_PROT_EN_MM_M1		BIT(2)
> +#define TOP_AXI_PROT_EN_MM_M0		BIT(1)
> +#define TOP_AXI_PROT_EN_MCI_M2		BIT(0)
> +
> +struct scp_domain_data {
> +	const char *name;
> +	u32 sta_mask;
> +	int ctl_offs;
> +	u32 sram_pdn_bits;
> +	u32 sram_pdn_ack_bits;
> +	u32 bus_prot_mask;
> +	int id;
> +};
> +
> +static struct scp_domain_data scp_domain_data[] = {
> +	{
> +		.id = MT8173_POWER_DOMAIN_VDE,
> +		.name = "vde",
> +		.sta_mask = VDE_PWR_STA_MASK,
> +		.ctl_offs = SPM_VDE_PWR_CON,
> +		.sram_pdn_bits = GENMASK(11, 8),
> +		.sram_pdn_ack_bits = GENMASK(12, 12),
> +	}, {
> +		.id = MT8173_POWER_DOMAIN_MFG,
> +		.name = "mfg",
> +		.sta_mask = MFG_PWR_STA_MASK,
> +		.ctl_offs = SPM_MFG_PWR_CON,
> +		.sram_pdn_bits = GENMASK(13, 8),
> +		.sram_pdn_ack_bits = GENMASK(21, 16),
> +		.bus_prot_mask = TOP_AXI_PROT_EN_MFG_S | TOP_AXI_PROT_EN_MFG_M0 |
> +			TOP_AXI_PROT_EN_MFG_M1 | TOP_AXI_PROT_EN_MFG_SNOOP_OUT,
> +	}, {
> +		.id = MT8173_POWER_DOMAIN_VEN,
> +		.name = "ven",
> +		.sta_mask = VEN_PWR_STA_MASK,
> +		.ctl_offs = SPM_VEN_PWR_CON,
> +		.sram_pdn_bits = GENMASK(11, 8),
> +		.sram_pdn_ack_bits = GENMASK(15, 12),
> +	}, {
> +		.id = MT8173_POWER_DOMAIN_ISP,
> +		.name = "isp",
> +		.sta_mask = ISP_PWR_STA_MASK,
> +		.ctl_offs = SPM_ISP_PWR_CON,
> +		.sram_pdn_bits = GENMASK(11, 8),
> +		.sram_pdn_ack_bits = GENMASK(13, 12),
> +	}, {
> +		.id = MT8173_POWER_DOMAIN_DIS,
> +		.name = "dis",
> +		.sta_mask = DIS_PWR_STA_MASK,
> +		.ctl_offs = SPM_DIS_PWR_CON,
> +		.sram_pdn_bits = GENMASK(11, 8),
> +		.sram_pdn_ack_bits = GENMASK(12, 12),
> +		.bus_prot_mask = TOP_AXI_PROT_EN_MM_M0 | TOP_AXI_PROT_EN_MM_M1,
> +	}, {
> +		.id = MT8173_POWER_DOMAIN_VEN2,
> +		.name = "ven2",
> +		.sta_mask = VEN2_PWR_STA_MASK,
> +		.ctl_offs = SPM_VEN2_PWR_CON,
> +		.sram_pdn_bits = GENMASK(11, 8),
> +		.sram_pdn_ack_bits = GENMASK(15, 12),
> +	}, {
> +		.id = MT8173_POWER_DOMAIN_AUDIO,
> +		.name = "audio",
> +		.sta_mask = AUDIO_PWR_STA_MASK,
> +		.ctl_offs = SPM_AUDIO_PWR_CON,
> +		.sram_pdn_bits = GENMASK(11, 8),
> +		.sram_pdn_ack_bits = GENMASK(15, 12),
> +	}, {
> +		.id = MT8173_POWER_DOMAIN_MFG_2D,
> +		.name = "mfg_2d",
> +		.sta_mask = MFG_2D_PWR_STA_MASK,
> +		.ctl_offs = SPM_MFG_2D_PWR_CON,
> +		.sram_pdn_bits = GENMASK(11, 8),
> +		.sram_pdn_ack_bits = GENMASK(13, 12),
> +	}, {
> +		.id = MT8173_POWER_DOMAIN_MFG_ASYNC,
> +		.name = "mfg_async",
> +		.sta_mask = MFG_ASYNC_PWR_STA_MASK,
> +		.ctl_offs = SPM_MFG_ASYNC_PWR_CON,
> +		.sram_pdn_bits = GENMASK(11, 8),
> +		.sram_pdn_ack_bits = 0,
> +	}, {
> +		.id = MT8173_POWER_DOMAIN_USB,
> +		.name = "usb",
> +		.sta_mask = USB_PWR_STA_MASK,
> +		.ctl_offs = SPM_USB_PWR_CON,
> +		.sram_pdn_bits = GENMASK(11, 8),
> +		.sram_pdn_ack_bits = GENMASK(15, 12),
> +	},
> +};
> +
> +#define NUM_DOMAINS	ARRAY_SIZE(scp_domain_data)
> +
> +struct scp;
> +
> +struct scp_domain {
> +	struct generic_pm_domain pmd;
> +	struct scp_domain_data *data;
> +	struct scp *scp;
> +};
> +
> +struct scp {
> +	struct scp_domain domains[NUM_DOMAINS];
> +	struct generic_pm_domain *pmd[NUM_DOMAINS];
> +	struct genpd_onecell_data pd_data;
> +	void __iomem *base;
> +	struct regmap *infracfg;
> +};
> +
> +static int scpsys_power_on(struct generic_pm_domain *genpd)
> +{
> +	struct scp_domain *scpd = container_of(genpd, struct scp_domain, pmd);
> +	struct scp *scp = scpd->scp;
> +	struct scp_domain_data *data = scpd->data;
> +	unsigned long expired;
> +	void __iomem *ctl_addr = scpd->scp->base + data->ctl_offs;
> +	u32 sram_pdn_ack = data->sram_pdn_ack_bits;
> +	u32 val;
> +	int ret;
> +
> +	val = readl(ctl_addr);
> +	val |= PWR_ON_BIT;
> +	writel(val, ctl_addr);
> +	val |= PWR_ON_2ND_BIT;
> +	writel(val, ctl_addr);
> +
> +	/* wait until PWR_ACK = 1 */
> +	expired = jiffies + HZ;
> +	while (!(readl(scp->base + SPM_PWR_STATUS) & data->sta_mask) ||
> +			!(readl(scp->base + SPM_PWR_STATUS_2ND) & data->sta_mask)) {
> +		cpu_relax();
> +		if (time_after(jiffies, expired))
> +			return -EIO;

hmm, seems like you'd want a dev_warn() or simliar here if this times
out and fails.  There's a bunch of these below too.

> +	}
> +
> +	val &= ~PWR_CLK_DIS_BIT;
> +	writel(val, ctl_addr);
> +
> +	val &= ~PWR_ISO_BIT;
> +	writel(val, ctl_addr);
> +
> +	val |= PWR_RST_B_BIT;
> +	writel(val, ctl_addr);
> +
> +	val &= ~data->sram_pdn_bits;
> +	writel(val, ctl_addr);
> +
> +	/* wait until SRAM_PDN_ACK all 0 */
> +	expired = jiffies + HZ;
> +	while (sram_pdn_ack && (readl(ctl_addr) & sram_pdn_ack)) {
> +		cpu_relax();
> +		if (time_after(jiffies, expired))
> +			return -EIO;
> +	}
> +
> +	/* Clear bus protection bits */
> +	if (data->bus_prot_mask) {
> +		u32 mask = data->bus_prot_mask;
> +		struct regmap *infracfg = scp->infracfg;
> +
> +		regmap_update_bits(infracfg, INFRA_TOPAXI_PROTECTEN, mask, 0);
> +
> +		expired = jiffies + HZ;
> +
> +		while (1) {
> +			u32 val;
> +
> +			ret = regmap_read(infracfg, INFRA_TOPAXI_PROTECTSTA1, &val);
> +			if (ret)
> +				return ret;
> +
> +			if (!(val & mask))
> +				break;
> +
> +			cpu_relax();
> +			if (time_after(jiffies, expired))
> +				return -EIO;
> +		}
> +	}

This whole "Clear bus protection bits" part seems like it should be an
API in the infracfg driver.

> +	return 0;
> +}
> +
> +static int scpsys_power_off(struct generic_pm_domain *genpd)
> +{
> +	struct scp_domain *scpd = container_of(genpd, struct scp_domain, pmd);
> +	struct scp *scp = scpd->scp;
> +	struct scp_domain_data *data = scpd->data;
> +	unsigned long expired;
> +	void __iomem *ctl_addr = scpd->scp->base + data->ctl_offs;
> +	u32 sram_pdn_ack = data->sram_pdn_ack_bits;
> +	u32 val;
> +	int ret;
> +
> +	/* set bus protection bits */
> +	if (data->bus_prot_mask) {
> +		struct regmap *infracfg = scp->infracfg;
> +		u32 mask = data->bus_prot_mask;
> +
> +		regmap_update_bits(infracfg, INFRA_TOPAXI_PROTECTEN, mask, mask);
> +
> +		expired = jiffies + HZ;
> +
> +		while (1) {
> +			ret = regmap_read(infracfg, INFRA_TOPAXI_PROTECTSTA1, &val);
> +			if (ret)
> +				return ret;
> +
> +			if ((val & mask) == mask)
> +				break;
> +
> +			cpu_relax();
> +			if (time_after(jiffies, expired))
> +				return -EIO;
> +		}
> +	}

As with the 'clear bus protection bits', seems like this should be a
call into the infracfg driver.

> +	val = readl(ctl_addr);
> +	val |= data->sram_pdn_bits;
> +	writel(val, ctl_addr);
> +
> +	/* wait until SRAM_PDN_ACK all 1 */
> +	expired = jiffies + HZ;
> +	while ((readl(ctl_addr) & sram_pdn_ack) != sram_pdn_ack) {
> +		cpu_relax();
> +		if (time_after(jiffies, expired))
> +			return -EIO;
> +	}
> +
> +	val |= PWR_ISO_BIT;
> +	writel(val, ctl_addr);
> +
> +	val &= ~PWR_RST_B_BIT;
> +	writel(val, ctl_addr);
> +
> +	val |= PWR_CLK_DIS_BIT;
> +	writel(val, ctl_addr);
> +
> +	val &= ~PWR_ON_BIT;
> +	writel(val, ctl_addr);
> +
> +	val &= ~PWR_ON_2ND_BIT;
> +	writel(val, ctl_addr);
> +
> +	/* wait until PWR_ACK = 0 */
> +	expired = jiffies + HZ;
> +	while ((readl(scp->base + SPM_PWR_STATUS) & data->sta_mask) ||
> +			(readl(scp->base + SPM_PWR_STATUS_2ND) & data->sta_mask)) {
> +		cpu_relax();
> +		if (time_after(jiffies, expired))
> +			return -EIO;
> +	}
> +
> +	return 0;
> +}
> +
> +static int scpsys_probe(struct platform_device *pdev)
> +{
> +	struct genpd_onecell_data *pd_data;
> +	struct resource *res;
> +	int i;
> +	struct scp *scp = devm_kzalloc(&pdev->dev, sizeof(*scp), GFP_KERNEL);

This might return NULL...

> +	res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
> +	scp->base = devm_ioremap_resource(&pdev->dev, res);

... and, boom.

> +	if (IS_ERR(scp->base))
> +		return PTR_ERR(scp->base);
> +
> +	pd_data = &scp->pd_data;
> +
> +	scp->infracfg = syscon_regmap_lookup_by_compatible("mediatek,mt8173-infracfg");
> +	if (IS_ERR(scp->infracfg))
> +		return PTR_ERR(scp->infracfg);
> +
> +	pd_data->domains = scp->pmd;
> +	pd_data->num_domains = NUM_DOMAINS;
> +
> +	for (i = 0; i < NUM_DOMAINS; i++) {
> +		struct scp_domain *scpd = &scp->domains[i];
> +		struct generic_pm_domain *pmd = &scpd->pmd;
> +
> +		scp->pmd[i] = pmd;
> +		scpd->data = &scp_domain_data[i];
> +		scpd->scp = scp;
> +
> +		pmd->name = scp_domain_data[i].name;
> +		pmd->power_off = scpsys_power_off;
> +		pmd->power_on = scpsys_power_on;
> +		pmd->power_off_latency_ns = 20000;
> +		pmd->power_on_latency_ns = 20000;

Are the latencies for all domains really the same?   Seems like the
latencies should be part of the per-domain data.

Where did these numbers come from?  HW specs, measurement, etc?

Also, eventually, these latencies can (and should) come from DT
after the support from Geert[1] is merged, so putting them in the data
struct for now

> +		pd_data->domains[i] = pmd;
> +		pm_genpd_init(pmd, NULL, 1);
> +	}
> +
> +	return of_genpd_add_provider_onecell(pdev->dev.of_node, pd_data);
> +}
> +
> +static struct of_device_id of_scpsys_match_tbl[] = {
> +	{
> +		.compatible = "mediatek,mt8173-scpsys",
> +	}, {
> +		/* sentinel */
> +	}
> +};
> +MODULE_DEVICE_TABLE(of, of_scpsys_match_tbl);
> +
> +static struct platform_driver scpsys_drv = {
> +	.driver = {
> +		.name = "mtk-scpsys",
> +		.owner = THIS_MODULE,
> +		.of_match_table = of_match_ptr(of_scpsys_match_tbl),
> +	},
> +	.probe = scpsys_probe,
> +};
> +
> +module_platform_driver(scpsys_drv);

Kevin

[1] https://lkml.org/lkml/2014/11/17/270

^ permalink raw reply	[flat|nested] 40+ messages in thread

* Re: [PATCH 1/4] dt-bindings: soc: Add documentation for the MediaTek SCPSYS unit
@ 2015-03-10  8:02       ` Sascha Hauer
  0 siblings, 0 replies; 40+ messages in thread
From: Sascha Hauer @ 2015-03-10  8:02 UTC (permalink / raw)
  To: Kevin Hilman
  Cc: linux-arm-kernel, devicetree, linux-kernel, Matthias Brugger,
	linux-mediatek, kernel

On Mon, Mar 09, 2015 at 01:46:25PM -0700, Kevin Hilman wrote:
> Sascha Hauer <s.hauer@pengutronix.de> writes:
> 
> > This adds documentation for the MediaTek SCPSYS unit found in MT8173 SoCs.
> 
> Curious if this IP unique to the 8173?  or maybe also used on 8135? ...

This is indeed found on the MT8135 aswell, but I already spotted the
first differences, so we'll need the SoC specific compatible anyway.

Sascha

-- 
Pengutronix e.K.                           |                             |
Industrial Linux Solutions                 | http://www.pengutronix.de/  |
Peiner Str. 6-8, 31137 Hildesheim, Germany | Phone: +49-5121-206917-0    |
Amtsgericht Hildesheim, HRA 2686           | Fax:   +49-5121-206917-5555 |

^ permalink raw reply	[flat|nested] 40+ messages in thread

* Re: [PATCH 1/4] dt-bindings: soc: Add documentation for the MediaTek SCPSYS unit
@ 2015-03-10  8:02       ` Sascha Hauer
  0 siblings, 0 replies; 40+ messages in thread
From: Sascha Hauer @ 2015-03-10  8:02 UTC (permalink / raw)
  To: Kevin Hilman
  Cc: linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
	devicetree-u79uwXL29TY76Z2rM5mHXA,
	linux-kernel-u79uwXL29TY76Z2rM5mHXA, Matthias Brugger,
	linux-mediatek-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
	kernel-bIcnvbaLZ9MEGnE8C9+IrQ

On Mon, Mar 09, 2015 at 01:46:25PM -0700, Kevin Hilman wrote:
> Sascha Hauer <s.hauer-bIcnvbaLZ9MEGnE8C9+IrQ@public.gmane.org> writes:
> 
> > This adds documentation for the MediaTek SCPSYS unit found in MT8173 SoCs.
> 
> Curious if this IP unique to the 8173?  or maybe also used on 8135? ...

This is indeed found on the MT8135 aswell, but I already spotted the
first differences, so we'll need the SoC specific compatible anyway.

Sascha

-- 
Pengutronix e.K.                           |                             |
Industrial Linux Solutions                 | http://www.pengutronix.de/  |
Peiner Str. 6-8, 31137 Hildesheim, Germany | Phone: +49-5121-206917-0    |
Amtsgericht Hildesheim, HRA 2686           | Fax:   +49-5121-206917-5555 |
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

^ permalink raw reply	[flat|nested] 40+ messages in thread

* [PATCH 1/4] dt-bindings: soc: Add documentation for the MediaTek SCPSYS unit
@ 2015-03-10  8:02       ` Sascha Hauer
  0 siblings, 0 replies; 40+ messages in thread
From: Sascha Hauer @ 2015-03-10  8:02 UTC (permalink / raw)
  To: linux-arm-kernel

On Mon, Mar 09, 2015 at 01:46:25PM -0700, Kevin Hilman wrote:
> Sascha Hauer <s.hauer@pengutronix.de> writes:
> 
> > This adds documentation for the MediaTek SCPSYS unit found in MT8173 SoCs.
> 
> Curious if this IP unique to the 8173?  or maybe also used on 8135? ...

This is indeed found on the MT8135 aswell, but I already spotted the
first differences, so we'll need the SoC specific compatible anyway.

Sascha

-- 
Pengutronix e.K.                           |                             |
Industrial Linux Solutions                 | http://www.pengutronix.de/  |
Peiner Str. 6-8, 31137 Hildesheim, Germany | Phone: +49-5121-206917-0    |
Amtsgericht Hildesheim, HRA 2686           | Fax:   +49-5121-206917-5555 |

^ permalink raw reply	[flat|nested] 40+ messages in thread

* Re: [PATCH 2/4] soc: Mediatek: Add SCPSYS power domain driver
@ 2015-03-10  9:41       ` Sascha Hauer
  0 siblings, 0 replies; 40+ messages in thread
From: Sascha Hauer @ 2015-03-10  9:41 UTC (permalink / raw)
  To: Kevin Hilman
  Cc: linux-arm-kernel, devicetree, linux-kernel, Matthias Brugger,
	linux-mediatek, kernel, James Liao


+Cc James Liao <jamesjj.liao@mediatek.com>

On Mon, Mar 09, 2015 at 02:35:03PM -0700, Kevin Hilman wrote:
> Sascha Hauer <s.hauer@pengutronix.de> writes:
> 
> > Signed-off-by: Sascha Hauer <s.hauer@pengutronix.de>
> 
> A bit of a changelog here would be useful describing this driver, that
> it's only covering part of the device (e.g. power controller) with more
> to come, dependency on the syscon driver, etc.
> 
> > +/*
> > + * The Infracfg unit has bus protection bits. We enable the bus protection
> > + * for disabled power domains so that the system does not hang when some unit
> > + * accesses the bus while in power down.
> > + */
> 
> Hmm, why don't you want to know if some device is accessing another
> device which is in a domain that is powered down?   Seems like this is a
> good way to hide real bugs.

How I understand it the system just hangs on erroneous accesses without
these protection bits enabled, so enabling them at least makes sure we
can output something.
I must admit though that my understanding of these bits is quite limited
and the only user of this driver I have available here (audio) doesn't
make use of these protection bits, so I can't test here.

James, could you shed some light on this issue?

> > +	val = readl(ctl_addr);
> > +	val |= PWR_ON_BIT;
> > +	writel(val, ctl_addr);
> > +	val |= PWR_ON_2ND_BIT;
> > +	writel(val, ctl_addr);
> > +
> > +	/* wait until PWR_ACK = 1 */
> > +	expired = jiffies + HZ;
> > +	while (!(readl(scp->base + SPM_PWR_STATUS) & data->sta_mask) ||
> > +			!(readl(scp->base + SPM_PWR_STATUS_2ND) & data->sta_mask)) {
> > +		cpu_relax();
> > +		if (time_after(jiffies, expired))
> > +			return -EIO;
> 
> hmm, seems like you'd want a dev_warn() or simliar here if this times
> out and fails.  There's a bunch of these below too.

Ok, will add.

> > +	/* Clear bus protection bits */
> > +	if (data->bus_prot_mask) {
> > +		u32 mask = data->bus_prot_mask;
> > +		struct regmap *infracfg = scp->infracfg;
> > +
> > +		regmap_update_bits(infracfg, INFRA_TOPAXI_PROTECTEN, mask, 0);
> > +
> > +		expired = jiffies + HZ;
> > +
> > +		while (1) {
> > +			u32 val;
> > +
> > +			ret = regmap_read(infracfg, INFRA_TOPAXI_PROTECTSTA1, &val);
> > +			if (ret)
> > +				return ret;
> > +
> > +			if (!(val & mask))
> > +				break;
> > +
> > +			cpu_relax();
> > +			if (time_after(jiffies, expired))
> > +				return -EIO;
> > +		}
> > +	}
> 
> This whole "Clear bus protection bits" part seems like it should be an
> API in the infracfg driver.

Ok, can do.

> 
> > +	return 0;
> > +}
> > +
> > +static int scpsys_power_off(struct generic_pm_domain *genpd)
> > +{
> > +	struct scp_domain *scpd = container_of(genpd, struct scp_domain, pmd);
> > +	struct scp *scp = scpd->scp;
> > +	struct scp_domain_data *data = scpd->data;
> > +	unsigned long expired;
> > +	void __iomem *ctl_addr = scpd->scp->base + data->ctl_offs;
> > +	u32 sram_pdn_ack = data->sram_pdn_ack_bits;
> > +	u32 val;
> > +	int ret;
> > +
> > +	/* set bus protection bits */
> > +	if (data->bus_prot_mask) {
> > +		struct regmap *infracfg = scp->infracfg;
> > +		u32 mask = data->bus_prot_mask;
> > +
> > +		regmap_update_bits(infracfg, INFRA_TOPAXI_PROTECTEN, mask, mask);
> > +
> > +		expired = jiffies + HZ;
> > +
> > +		while (1) {
> > +			ret = regmap_read(infracfg, INFRA_TOPAXI_PROTECTSTA1, &val);
> > +			if (ret)
> > +				return ret;
> > +
> > +			if ((val & mask) == mask)
> > +				break;
> > +
> > +			cpu_relax();
> > +			if (time_after(jiffies, expired))
> > +				return -EIO;
> > +		}
> > +	}
> 
> As with the 'clear bus protection bits', seems like this should be a
> call into the infracfg driver.
> 
> > +	val = readl(ctl_addr);
> > +	val |= data->sram_pdn_bits;
> > +	writel(val, ctl_addr);
> > +
> > +	/* wait until SRAM_PDN_ACK all 1 */
> > +	expired = jiffies + HZ;
> > +	while ((readl(ctl_addr) & sram_pdn_ack) != sram_pdn_ack) {
> > +		cpu_relax();
> > +		if (time_after(jiffies, expired))
> > +			return -EIO;
> > +	}
> > +
> > +	val |= PWR_ISO_BIT;
> > +	writel(val, ctl_addr);
> > +
> > +	val &= ~PWR_RST_B_BIT;
> > +	writel(val, ctl_addr);
> > +
> > +	val |= PWR_CLK_DIS_BIT;
> > +	writel(val, ctl_addr);
> > +
> > +	val &= ~PWR_ON_BIT;
> > +	writel(val, ctl_addr);
> > +
> > +	val &= ~PWR_ON_2ND_BIT;
> > +	writel(val, ctl_addr);
> > +
> > +	/* wait until PWR_ACK = 0 */
> > +	expired = jiffies + HZ;
> > +	while ((readl(scp->base + SPM_PWR_STATUS) & data->sta_mask) ||
> > +			(readl(scp->base + SPM_PWR_STATUS_2ND) & data->sta_mask)) {
> > +		cpu_relax();
> > +		if (time_after(jiffies, expired))
> > +			return -EIO;
> > +	}
> > +
> > +	return 0;
> > +}
> > +
> > +static int scpsys_probe(struct platform_device *pdev)
> > +{
> > +	struct genpd_onecell_data *pd_data;
> > +	struct resource *res;
> > +	int i;
> > +	struct scp *scp = devm_kzalloc(&pdev->dev, sizeof(*scp), GFP_KERNEL);
> 
> This might return NULL...

Actually I recently learned that this never fails [1], but the check is
missing accidently here. Will add it of course.

[1] http://lwn.net/Articles/627419/

> 
> > +	res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
> > +	scp->base = devm_ioremap_resource(&pdev->dev, res);
> 
> ... and, boom.
> 
> > +	if (IS_ERR(scp->base))
> > +		return PTR_ERR(scp->base);
> > +
> > +	pd_data = &scp->pd_data;
> > +
> > +	scp->infracfg = syscon_regmap_lookup_by_compatible("mediatek,mt8173-infracfg");
> > +	if (IS_ERR(scp->infracfg))
> > +		return PTR_ERR(scp->infracfg);
> > +
> > +	pd_data->domains = scp->pmd;
> > +	pd_data->num_domains = NUM_DOMAINS;
> > +
> > +	for (i = 0; i < NUM_DOMAINS; i++) {
> > +		struct scp_domain *scpd = &scp->domains[i];
> > +		struct generic_pm_domain *pmd = &scpd->pmd;
> > +
> > +		scp->pmd[i] = pmd;
> > +		scpd->data = &scp_domain_data[i];
> > +		scpd->scp = scp;
> > +
> > +		pmd->name = scp_domain_data[i].name;
> > +		pmd->power_off = scpsys_power_off;
> > +		pmd->power_on = scpsys_power_on;
> > +		pmd->power_off_latency_ns = 20000;
> > +		pmd->power_on_latency_ns = 20000;
> 
> Are the latencies for all domains really the same?   Seems like the
> latencies should be part of the per-domain data.
> 
> Where did these numbers come from?  HW specs, measurement, etc?

They are from measurement. actually they are around 11us.

> 
> Also, eventually, these latencies can (and should) come from DT
> after the support from Geert[1] is merged, so putting them in the data
> struct for now

I agree for domains created from regulators somewhere on the board, but
in this case the domains are completely SoC internal. The
"mediatek,mt8173-scpsys" compatible gives me enough information so I see
no point adding this to the device tree.

Sascha

-- 
Pengutronix e.K.                           |                             |
Industrial Linux Solutions                 | http://www.pengutronix.de/  |
Peiner Str. 6-8, 31137 Hildesheim, Germany | Phone: +49-5121-206917-0    |
Amtsgericht Hildesheim, HRA 2686           | Fax:   +49-5121-206917-5555 |

^ permalink raw reply	[flat|nested] 40+ messages in thread

* Re: [PATCH 2/4] soc: Mediatek: Add SCPSYS power domain driver
@ 2015-03-10  9:41       ` Sascha Hauer
  0 siblings, 0 replies; 40+ messages in thread
From: Sascha Hauer @ 2015-03-10  9:41 UTC (permalink / raw)
  To: Kevin Hilman
  Cc: linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
	devicetree-u79uwXL29TY76Z2rM5mHXA,
	linux-kernel-u79uwXL29TY76Z2rM5mHXA, Matthias Brugger,
	linux-mediatek-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
	kernel-bIcnvbaLZ9MEGnE8C9+IrQ, James Liao


+Cc James Liao <jamesjj.liao-NuS5LvNUpcJWk0Htik3J/w@public.gmane.org>

On Mon, Mar 09, 2015 at 02:35:03PM -0700, Kevin Hilman wrote:
> Sascha Hauer <s.hauer-bIcnvbaLZ9MEGnE8C9+IrQ@public.gmane.org> writes:
> 
> > Signed-off-by: Sascha Hauer <s.hauer-bIcnvbaLZ9MEGnE8C9+IrQ@public.gmane.org>
> 
> A bit of a changelog here would be useful describing this driver, that
> it's only covering part of the device (e.g. power controller) with more
> to come, dependency on the syscon driver, etc.
> 
> > +/*
> > + * The Infracfg unit has bus protection bits. We enable the bus protection
> > + * for disabled power domains so that the system does not hang when some unit
> > + * accesses the bus while in power down.
> > + */
> 
> Hmm, why don't you want to know if some device is accessing another
> device which is in a domain that is powered down?   Seems like this is a
> good way to hide real bugs.

How I understand it the system just hangs on erroneous accesses without
these protection bits enabled, so enabling them at least makes sure we
can output something.
I must admit though that my understanding of these bits is quite limited
and the only user of this driver I have available here (audio) doesn't
make use of these protection bits, so I can't test here.

James, could you shed some light on this issue?

> > +	val = readl(ctl_addr);
> > +	val |= PWR_ON_BIT;
> > +	writel(val, ctl_addr);
> > +	val |= PWR_ON_2ND_BIT;
> > +	writel(val, ctl_addr);
> > +
> > +	/* wait until PWR_ACK = 1 */
> > +	expired = jiffies + HZ;
> > +	while (!(readl(scp->base + SPM_PWR_STATUS) & data->sta_mask) ||
> > +			!(readl(scp->base + SPM_PWR_STATUS_2ND) & data->sta_mask)) {
> > +		cpu_relax();
> > +		if (time_after(jiffies, expired))
> > +			return -EIO;
> 
> hmm, seems like you'd want a dev_warn() or simliar here if this times
> out and fails.  There's a bunch of these below too.

Ok, will add.

> > +	/* Clear bus protection bits */
> > +	if (data->bus_prot_mask) {
> > +		u32 mask = data->bus_prot_mask;
> > +		struct regmap *infracfg = scp->infracfg;
> > +
> > +		regmap_update_bits(infracfg, INFRA_TOPAXI_PROTECTEN, mask, 0);
> > +
> > +		expired = jiffies + HZ;
> > +
> > +		while (1) {
> > +			u32 val;
> > +
> > +			ret = regmap_read(infracfg, INFRA_TOPAXI_PROTECTSTA1, &val);
> > +			if (ret)
> > +				return ret;
> > +
> > +			if (!(val & mask))
> > +				break;
> > +
> > +			cpu_relax();
> > +			if (time_after(jiffies, expired))
> > +				return -EIO;
> > +		}
> > +	}
> 
> This whole "Clear bus protection bits" part seems like it should be an
> API in the infracfg driver.

Ok, can do.

> 
> > +	return 0;
> > +}
> > +
> > +static int scpsys_power_off(struct generic_pm_domain *genpd)
> > +{
> > +	struct scp_domain *scpd = container_of(genpd, struct scp_domain, pmd);
> > +	struct scp *scp = scpd->scp;
> > +	struct scp_domain_data *data = scpd->data;
> > +	unsigned long expired;
> > +	void __iomem *ctl_addr = scpd->scp->base + data->ctl_offs;
> > +	u32 sram_pdn_ack = data->sram_pdn_ack_bits;
> > +	u32 val;
> > +	int ret;
> > +
> > +	/* set bus protection bits */
> > +	if (data->bus_prot_mask) {
> > +		struct regmap *infracfg = scp->infracfg;
> > +		u32 mask = data->bus_prot_mask;
> > +
> > +		regmap_update_bits(infracfg, INFRA_TOPAXI_PROTECTEN, mask, mask);
> > +
> > +		expired = jiffies + HZ;
> > +
> > +		while (1) {
> > +			ret = regmap_read(infracfg, INFRA_TOPAXI_PROTECTSTA1, &val);
> > +			if (ret)
> > +				return ret;
> > +
> > +			if ((val & mask) == mask)
> > +				break;
> > +
> > +			cpu_relax();
> > +			if (time_after(jiffies, expired))
> > +				return -EIO;
> > +		}
> > +	}
> 
> As with the 'clear bus protection bits', seems like this should be a
> call into the infracfg driver.
> 
> > +	val = readl(ctl_addr);
> > +	val |= data->sram_pdn_bits;
> > +	writel(val, ctl_addr);
> > +
> > +	/* wait until SRAM_PDN_ACK all 1 */
> > +	expired = jiffies + HZ;
> > +	while ((readl(ctl_addr) & sram_pdn_ack) != sram_pdn_ack) {
> > +		cpu_relax();
> > +		if (time_after(jiffies, expired))
> > +			return -EIO;
> > +	}
> > +
> > +	val |= PWR_ISO_BIT;
> > +	writel(val, ctl_addr);
> > +
> > +	val &= ~PWR_RST_B_BIT;
> > +	writel(val, ctl_addr);
> > +
> > +	val |= PWR_CLK_DIS_BIT;
> > +	writel(val, ctl_addr);
> > +
> > +	val &= ~PWR_ON_BIT;
> > +	writel(val, ctl_addr);
> > +
> > +	val &= ~PWR_ON_2ND_BIT;
> > +	writel(val, ctl_addr);
> > +
> > +	/* wait until PWR_ACK = 0 */
> > +	expired = jiffies + HZ;
> > +	while ((readl(scp->base + SPM_PWR_STATUS) & data->sta_mask) ||
> > +			(readl(scp->base + SPM_PWR_STATUS_2ND) & data->sta_mask)) {
> > +		cpu_relax();
> > +		if (time_after(jiffies, expired))
> > +			return -EIO;
> > +	}
> > +
> > +	return 0;
> > +}
> > +
> > +static int scpsys_probe(struct platform_device *pdev)
> > +{
> > +	struct genpd_onecell_data *pd_data;
> > +	struct resource *res;
> > +	int i;
> > +	struct scp *scp = devm_kzalloc(&pdev->dev, sizeof(*scp), GFP_KERNEL);
> 
> This might return NULL...

Actually I recently learned that this never fails [1], but the check is
missing accidently here. Will add it of course.

[1] http://lwn.net/Articles/627419/

> 
> > +	res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
> > +	scp->base = devm_ioremap_resource(&pdev->dev, res);
> 
> ... and, boom.
> 
> > +	if (IS_ERR(scp->base))
> > +		return PTR_ERR(scp->base);
> > +
> > +	pd_data = &scp->pd_data;
> > +
> > +	scp->infracfg = syscon_regmap_lookup_by_compatible("mediatek,mt8173-infracfg");
> > +	if (IS_ERR(scp->infracfg))
> > +		return PTR_ERR(scp->infracfg);
> > +
> > +	pd_data->domains = scp->pmd;
> > +	pd_data->num_domains = NUM_DOMAINS;
> > +
> > +	for (i = 0; i < NUM_DOMAINS; i++) {
> > +		struct scp_domain *scpd = &scp->domains[i];
> > +		struct generic_pm_domain *pmd = &scpd->pmd;
> > +
> > +		scp->pmd[i] = pmd;
> > +		scpd->data = &scp_domain_data[i];
> > +		scpd->scp = scp;
> > +
> > +		pmd->name = scp_domain_data[i].name;
> > +		pmd->power_off = scpsys_power_off;
> > +		pmd->power_on = scpsys_power_on;
> > +		pmd->power_off_latency_ns = 20000;
> > +		pmd->power_on_latency_ns = 20000;
> 
> Are the latencies for all domains really the same?   Seems like the
> latencies should be part of the per-domain data.
> 
> Where did these numbers come from?  HW specs, measurement, etc?

They are from measurement. actually they are around 11us.

> 
> Also, eventually, these latencies can (and should) come from DT
> after the support from Geert[1] is merged, so putting them in the data
> struct for now

I agree for domains created from regulators somewhere on the board, but
in this case the domains are completely SoC internal. The
"mediatek,mt8173-scpsys" compatible gives me enough information so I see
no point adding this to the device tree.

Sascha

-- 
Pengutronix e.K.                           |                             |
Industrial Linux Solutions                 | http://www.pengutronix.de/  |
Peiner Str. 6-8, 31137 Hildesheim, Germany | Phone: +49-5121-206917-0    |
Amtsgericht Hildesheim, HRA 2686           | Fax:   +49-5121-206917-5555 |
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

^ permalink raw reply	[flat|nested] 40+ messages in thread

* [PATCH 2/4] soc: Mediatek: Add SCPSYS power domain driver
@ 2015-03-10  9:41       ` Sascha Hauer
  0 siblings, 0 replies; 40+ messages in thread
From: Sascha Hauer @ 2015-03-10  9:41 UTC (permalink / raw)
  To: linux-arm-kernel


+Cc James Liao <jamesjj.liao@mediatek.com>

On Mon, Mar 09, 2015 at 02:35:03PM -0700, Kevin Hilman wrote:
> Sascha Hauer <s.hauer@pengutronix.de> writes:
> 
> > Signed-off-by: Sascha Hauer <s.hauer@pengutronix.de>
> 
> A bit of a changelog here would be useful describing this driver, that
> it's only covering part of the device (e.g. power controller) with more
> to come, dependency on the syscon driver, etc.
> 
> > +/*
> > + * The Infracfg unit has bus protection bits. We enable the bus protection
> > + * for disabled power domains so that the system does not hang when some unit
> > + * accesses the bus while in power down.
> > + */
> 
> Hmm, why don't you want to know if some device is accessing another
> device which is in a domain that is powered down?   Seems like this is a
> good way to hide real bugs.

How I understand it the system just hangs on erroneous accesses without
these protection bits enabled, so enabling them at least makes sure we
can output something.
I must admit though that my understanding of these bits is quite limited
and the only user of this driver I have available here (audio) doesn't
make use of these protection bits, so I can't test here.

James, could you shed some light on this issue?

> > +	val = readl(ctl_addr);
> > +	val |= PWR_ON_BIT;
> > +	writel(val, ctl_addr);
> > +	val |= PWR_ON_2ND_BIT;
> > +	writel(val, ctl_addr);
> > +
> > +	/* wait until PWR_ACK = 1 */
> > +	expired = jiffies + HZ;
> > +	while (!(readl(scp->base + SPM_PWR_STATUS) & data->sta_mask) ||
> > +			!(readl(scp->base + SPM_PWR_STATUS_2ND) & data->sta_mask)) {
> > +		cpu_relax();
> > +		if (time_after(jiffies, expired))
> > +			return -EIO;
> 
> hmm, seems like you'd want a dev_warn() or simliar here if this times
> out and fails.  There's a bunch of these below too.

Ok, will add.

> > +	/* Clear bus protection bits */
> > +	if (data->bus_prot_mask) {
> > +		u32 mask = data->bus_prot_mask;
> > +		struct regmap *infracfg = scp->infracfg;
> > +
> > +		regmap_update_bits(infracfg, INFRA_TOPAXI_PROTECTEN, mask, 0);
> > +
> > +		expired = jiffies + HZ;
> > +
> > +		while (1) {
> > +			u32 val;
> > +
> > +			ret = regmap_read(infracfg, INFRA_TOPAXI_PROTECTSTA1, &val);
> > +			if (ret)
> > +				return ret;
> > +
> > +			if (!(val & mask))
> > +				break;
> > +
> > +			cpu_relax();
> > +			if (time_after(jiffies, expired))
> > +				return -EIO;
> > +		}
> > +	}
> 
> This whole "Clear bus protection bits" part seems like it should be an
> API in the infracfg driver.

Ok, can do.

> 
> > +	return 0;
> > +}
> > +
> > +static int scpsys_power_off(struct generic_pm_domain *genpd)
> > +{
> > +	struct scp_domain *scpd = container_of(genpd, struct scp_domain, pmd);
> > +	struct scp *scp = scpd->scp;
> > +	struct scp_domain_data *data = scpd->data;
> > +	unsigned long expired;
> > +	void __iomem *ctl_addr = scpd->scp->base + data->ctl_offs;
> > +	u32 sram_pdn_ack = data->sram_pdn_ack_bits;
> > +	u32 val;
> > +	int ret;
> > +
> > +	/* set bus protection bits */
> > +	if (data->bus_prot_mask) {
> > +		struct regmap *infracfg = scp->infracfg;
> > +		u32 mask = data->bus_prot_mask;
> > +
> > +		regmap_update_bits(infracfg, INFRA_TOPAXI_PROTECTEN, mask, mask);
> > +
> > +		expired = jiffies + HZ;
> > +
> > +		while (1) {
> > +			ret = regmap_read(infracfg, INFRA_TOPAXI_PROTECTSTA1, &val);
> > +			if (ret)
> > +				return ret;
> > +
> > +			if ((val & mask) == mask)
> > +				break;
> > +
> > +			cpu_relax();
> > +			if (time_after(jiffies, expired))
> > +				return -EIO;
> > +		}
> > +	}
> 
> As with the 'clear bus protection bits', seems like this should be a
> call into the infracfg driver.
> 
> > +	val = readl(ctl_addr);
> > +	val |= data->sram_pdn_bits;
> > +	writel(val, ctl_addr);
> > +
> > +	/* wait until SRAM_PDN_ACK all 1 */
> > +	expired = jiffies + HZ;
> > +	while ((readl(ctl_addr) & sram_pdn_ack) != sram_pdn_ack) {
> > +		cpu_relax();
> > +		if (time_after(jiffies, expired))
> > +			return -EIO;
> > +	}
> > +
> > +	val |= PWR_ISO_BIT;
> > +	writel(val, ctl_addr);
> > +
> > +	val &= ~PWR_RST_B_BIT;
> > +	writel(val, ctl_addr);
> > +
> > +	val |= PWR_CLK_DIS_BIT;
> > +	writel(val, ctl_addr);
> > +
> > +	val &= ~PWR_ON_BIT;
> > +	writel(val, ctl_addr);
> > +
> > +	val &= ~PWR_ON_2ND_BIT;
> > +	writel(val, ctl_addr);
> > +
> > +	/* wait until PWR_ACK = 0 */
> > +	expired = jiffies + HZ;
> > +	while ((readl(scp->base + SPM_PWR_STATUS) & data->sta_mask) ||
> > +			(readl(scp->base + SPM_PWR_STATUS_2ND) & data->sta_mask)) {
> > +		cpu_relax();
> > +		if (time_after(jiffies, expired))
> > +			return -EIO;
> > +	}
> > +
> > +	return 0;
> > +}
> > +
> > +static int scpsys_probe(struct platform_device *pdev)
> > +{
> > +	struct genpd_onecell_data *pd_data;
> > +	struct resource *res;
> > +	int i;
> > +	struct scp *scp = devm_kzalloc(&pdev->dev, sizeof(*scp), GFP_KERNEL);
> 
> This might return NULL...

Actually I recently learned that this never fails [1], but the check is
missing accidently here. Will add it of course.

[1] http://lwn.net/Articles/627419/

> 
> > +	res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
> > +	scp->base = devm_ioremap_resource(&pdev->dev, res);
> 
> ... and, boom.
> 
> > +	if (IS_ERR(scp->base))
> > +		return PTR_ERR(scp->base);
> > +
> > +	pd_data = &scp->pd_data;
> > +
> > +	scp->infracfg = syscon_regmap_lookup_by_compatible("mediatek,mt8173-infracfg");
> > +	if (IS_ERR(scp->infracfg))
> > +		return PTR_ERR(scp->infracfg);
> > +
> > +	pd_data->domains = scp->pmd;
> > +	pd_data->num_domains = NUM_DOMAINS;
> > +
> > +	for (i = 0; i < NUM_DOMAINS; i++) {
> > +		struct scp_domain *scpd = &scp->domains[i];
> > +		struct generic_pm_domain *pmd = &scpd->pmd;
> > +
> > +		scp->pmd[i] = pmd;
> > +		scpd->data = &scp_domain_data[i];
> > +		scpd->scp = scp;
> > +
> > +		pmd->name = scp_domain_data[i].name;
> > +		pmd->power_off = scpsys_power_off;
> > +		pmd->power_on = scpsys_power_on;
> > +		pmd->power_off_latency_ns = 20000;
> > +		pmd->power_on_latency_ns = 20000;
> 
> Are the latencies for all domains really the same?   Seems like the
> latencies should be part of the per-domain data.
> 
> Where did these numbers come from?  HW specs, measurement, etc?

They are from measurement. actually they are around 11us.

> 
> Also, eventually, these latencies can (and should) come from DT
> after the support from Geert[1] is merged, so putting them in the data
> struct for now

I agree for domains created from regulators somewhere on the board, but
in this case the domains are completely SoC internal. The
"mediatek,mt8173-scpsys" compatible gives me enough information so I see
no point adding this to the device tree.

Sascha

-- 
Pengutronix e.K.                           |                             |
Industrial Linux Solutions                 | http://www.pengutronix.de/  |
Peiner Str. 6-8, 31137 Hildesheim, Germany | Phone: +49-5121-206917-0    |
Amtsgericht Hildesheim, HRA 2686           | Fax:   +49-5121-206917-5555 |

^ permalink raw reply	[flat|nested] 40+ messages in thread

* Re: [PATCH 2/4] soc: Mediatek: Add SCPSYS power domain driver
  2015-03-10  9:41       ` Sascha Hauer
@ 2015-03-10 14:40         ` Sascha Hauer
  -1 siblings, 0 replies; 40+ messages in thread
From: Sascha Hauer @ 2015-03-10 14:40 UTC (permalink / raw)
  To: Kevin Hilman
  Cc: devicetree, James Liao, linux-kernel, linux-mediatek, kernel,
	Matthias Brugger, linux-arm-kernel

On Tue, Mar 10, 2015 at 10:41:42AM +0100, Sascha Hauer wrote:
> > > +	if (data->bus_prot_mask) {
> > > +		u32 mask = data->bus_prot_mask;
> > > +		struct regmap *infracfg = scp->infracfg;
> > > +
> > > +		regmap_update_bits(infracfg, INFRA_TOPAXI_PROTECTEN, mask, 0);
> > > +
> > > +		expired = jiffies + HZ;
> > > +
> > > +		while (1) {
> > > +			u32 val;
> > > +
> > > +			ret = regmap_read(infracfg, INFRA_TOPAXI_PROTECTSTA1, &val);
> > > +			if (ret)
> > > +				return ret;
> > > +
> > > +			if (!(val & mask))
> > > +				break;
> > > +
> > > +			cpu_relax();
> > > +			if (time_after(jiffies, expired))
> > > +				return -EIO;
> > > +		}
> > > +	}
> > 
> > This whole "Clear bus protection bits" part seems like it should be an
> > API in the infracfg driver.
> 
> Ok, can do.

Since the infracfg driver (which is really a clk driver) currently is
pending for inclusion I don't want to add more patches to it. I decided
to drop the protection bits for now and come back to this once the
infracfg driver is merged.

Sascha


-- 
Pengutronix e.K.                           |                             |
Industrial Linux Solutions                 | http://www.pengutronix.de/  |
Peiner Str. 6-8, 31137 Hildesheim, Germany | Phone: +49-5121-206917-0    |
Amtsgericht Hildesheim, HRA 2686           | Fax:   +49-5121-206917-5555 |

^ permalink raw reply	[flat|nested] 40+ messages in thread

* [PATCH 2/4] soc: Mediatek: Add SCPSYS power domain driver
@ 2015-03-10 14:40         ` Sascha Hauer
  0 siblings, 0 replies; 40+ messages in thread
From: Sascha Hauer @ 2015-03-10 14:40 UTC (permalink / raw)
  To: linux-arm-kernel

On Tue, Mar 10, 2015 at 10:41:42AM +0100, Sascha Hauer wrote:
> > > +	if (data->bus_prot_mask) {
> > > +		u32 mask = data->bus_prot_mask;
> > > +		struct regmap *infracfg = scp->infracfg;
> > > +
> > > +		regmap_update_bits(infracfg, INFRA_TOPAXI_PROTECTEN, mask, 0);
> > > +
> > > +		expired = jiffies + HZ;
> > > +
> > > +		while (1) {
> > > +			u32 val;
> > > +
> > > +			ret = regmap_read(infracfg, INFRA_TOPAXI_PROTECTSTA1, &val);
> > > +			if (ret)
> > > +				return ret;
> > > +
> > > +			if (!(val & mask))
> > > +				break;
> > > +
> > > +			cpu_relax();
> > > +			if (time_after(jiffies, expired))
> > > +				return -EIO;
> > > +		}
> > > +	}
> > 
> > This whole "Clear bus protection bits" part seems like it should be an
> > API in the infracfg driver.
> 
> Ok, can do.

Since the infracfg driver (which is really a clk driver) currently is
pending for inclusion I don't want to add more patches to it. I decided
to drop the protection bits for now and come back to this once the
infracfg driver is merged.

Sascha


-- 
Pengutronix e.K.                           |                             |
Industrial Linux Solutions                 | http://www.pengutronix.de/  |
Peiner Str. 6-8, 31137 Hildesheim, Germany | Phone: +49-5121-206917-0    |
Amtsgericht Hildesheim, HRA 2686           | Fax:   +49-5121-206917-5555 |

^ permalink raw reply	[flat|nested] 40+ messages in thread

* Re: [PATCH 2/4] soc: Mediatek: Add SCPSYS power domain driver
@ 2015-03-10 16:00           ` Kevin Hilman
  0 siblings, 0 replies; 40+ messages in thread
From: Kevin Hilman @ 2015-03-10 16:00 UTC (permalink / raw)
  To: Sascha Hauer
  Cc: devicetree, James Liao, linux-kernel, linux-mediatek, kernel,
	Matthias Brugger, linux-arm-kernel

Sascha Hauer <s.hauer@pengutronix.de> writes:

> On Tue, Mar 10, 2015 at 10:41:42AM +0100, Sascha Hauer wrote:
>> > > +	if (data->bus_prot_mask) {
>> > > +		u32 mask = data->bus_prot_mask;
>> > > +		struct regmap *infracfg = scp->infracfg;
>> > > +
>> > > +		regmap_update_bits(infracfg, INFRA_TOPAXI_PROTECTEN, mask, 0);
>> > > +
>> > > +		expired = jiffies + HZ;
>> > > +
>> > > +		while (1) {
>> > > +			u32 val;
>> > > +
>> > > +			ret = regmap_read(infracfg, INFRA_TOPAXI_PROTECTSTA1, &val);
>> > > +			if (ret)
>> > > +				return ret;
>> > > +
>> > > +			if (!(val & mask))
>> > > +				break;
>> > > +
>> > > +			cpu_relax();
>> > > +			if (time_after(jiffies, expired))
>> > > +				return -EIO;
>> > > +		}
>> > > +	}
>> > 
>> > This whole "Clear bus protection bits" part seems like it should be an
>> > API in the infracfg driver.
>> 
>> Ok, can do.
>
> Since the infracfg driver (which is really a clk driver) currently is
> pending for inclusion I don't want to add more patches to it. I decided
> to drop the protection bits for now and come back to this once the
> infracfg driver is merged.

Makes sense to me.  Hopefully by then, we can have a bit more clarity
from the MTK folks also.

Kevin

^ permalink raw reply	[flat|nested] 40+ messages in thread

* Re: [PATCH 2/4] soc: Mediatek: Add SCPSYS power domain driver
@ 2015-03-10 16:00           ` Kevin Hilman
  0 siblings, 0 replies; 40+ messages in thread
From: Kevin Hilman @ 2015-03-10 16:00 UTC (permalink / raw)
  To: Sascha Hauer
  Cc: devicetree-u79uwXL29TY76Z2rM5mHXA, James Liao,
	linux-kernel-u79uwXL29TY76Z2rM5mHXA,
	linux-mediatek-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
	kernel-bIcnvbaLZ9MEGnE8C9+IrQ, Matthias Brugger,
	linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r

Sascha Hauer <s.hauer-bIcnvbaLZ9MEGnE8C9+IrQ@public.gmane.org> writes:

> On Tue, Mar 10, 2015 at 10:41:42AM +0100, Sascha Hauer wrote:
>> > > +	if (data->bus_prot_mask) {
>> > > +		u32 mask = data->bus_prot_mask;
>> > > +		struct regmap *infracfg = scp->infracfg;
>> > > +
>> > > +		regmap_update_bits(infracfg, INFRA_TOPAXI_PROTECTEN, mask, 0);
>> > > +
>> > > +		expired = jiffies + HZ;
>> > > +
>> > > +		while (1) {
>> > > +			u32 val;
>> > > +
>> > > +			ret = regmap_read(infracfg, INFRA_TOPAXI_PROTECTSTA1, &val);
>> > > +			if (ret)
>> > > +				return ret;
>> > > +
>> > > +			if (!(val & mask))
>> > > +				break;
>> > > +
>> > > +			cpu_relax();
>> > > +			if (time_after(jiffies, expired))
>> > > +				return -EIO;
>> > > +		}
>> > > +	}
>> > 
>> > This whole "Clear bus protection bits" part seems like it should be an
>> > API in the infracfg driver.
>> 
>> Ok, can do.
>
> Since the infracfg driver (which is really a clk driver) currently is
> pending for inclusion I don't want to add more patches to it. I decided
> to drop the protection bits for now and come back to this once the
> infracfg driver is merged.

Makes sense to me.  Hopefully by then, we can have a bit more clarity
from the MTK folks also.

Kevin
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

^ permalink raw reply	[flat|nested] 40+ messages in thread

* [PATCH 2/4] soc: Mediatek: Add SCPSYS power domain driver
@ 2015-03-10 16:00           ` Kevin Hilman
  0 siblings, 0 replies; 40+ messages in thread
From: Kevin Hilman @ 2015-03-10 16:00 UTC (permalink / raw)
  To: linux-arm-kernel

Sascha Hauer <s.hauer@pengutronix.de> writes:

> On Tue, Mar 10, 2015 at 10:41:42AM +0100, Sascha Hauer wrote:
>> > > +	if (data->bus_prot_mask) {
>> > > +		u32 mask = data->bus_prot_mask;
>> > > +		struct regmap *infracfg = scp->infracfg;
>> > > +
>> > > +		regmap_update_bits(infracfg, INFRA_TOPAXI_PROTECTEN, mask, 0);
>> > > +
>> > > +		expired = jiffies + HZ;
>> > > +
>> > > +		while (1) {
>> > > +			u32 val;
>> > > +
>> > > +			ret = regmap_read(infracfg, INFRA_TOPAXI_PROTECTSTA1, &val);
>> > > +			if (ret)
>> > > +				return ret;
>> > > +
>> > > +			if (!(val & mask))
>> > > +				break;
>> > > +
>> > > +			cpu_relax();
>> > > +			if (time_after(jiffies, expired))
>> > > +				return -EIO;
>> > > +		}
>> > > +	}
>> > 
>> > This whole "Clear bus protection bits" part seems like it should be an
>> > API in the infracfg driver.
>> 
>> Ok, can do.
>
> Since the infracfg driver (which is really a clk driver) currently is
> pending for inclusion I don't want to add more patches to it. I decided
> to drop the protection bits for now and come back to this once the
> infracfg driver is merged.

Makes sense to me.  Hopefully by then, we can have a bit more clarity
from the MTK folks also.

Kevin

^ permalink raw reply	[flat|nested] 40+ messages in thread

* Re: [PATCH 2/4] soc: Mediatek: Add SCPSYS power domain driver
@ 2015-03-11  3:16         ` James Liao
  0 siblings, 0 replies; 40+ messages in thread
From: James Liao @ 2015-03-11  3:16 UTC (permalink / raw)
  To: Sascha Hauer
  Cc: Kevin Hilman, linux-arm-kernel, devicetree, linux-kernel,
	Matthias Brugger, linux-mediatek, kernel

Hi,

On Tue, 2015-03-10 at 10:41 +0100, Sascha Hauer wrote:
> On Mon, Mar 09, 2015 at 02:35:03PM -0700, Kevin Hilman wrote:
> > Sascha Hauer <s.hauer@pengutronix.de> writes:
> > 
> > > Signed-off-by: Sascha Hauer <s.hauer@pengutronix.de>
> > 
> > A bit of a changelog here would be useful describing this driver, that
> > it's only covering part of the device (e.g. power controller) with more
> > to come, dependency on the syscon driver, etc.
> > 
> > > +/*
> > > + * The Infracfg unit has bus protection bits. We enable the bus protection
> > > + * for disabled power domains so that the system does not hang when some unit
> > > + * accesses the bus while in power down.
> > > + */
> > 
> > Hmm, why don't you want to know if some device is accessing another
> > device which is in a domain that is powered down?   Seems like this is a
> > good way to hide real bugs.
> 
> How I understand it the system just hangs on erroneous accesses without
> these protection bits enabled, so enabling them at least makes sure we
> can output something.
> I must admit though that my understanding of these bits is quite limited
> and the only user of this driver I have available here (audio) doesn't
> make use of these protection bits, so I can't test here.
> 
> James, could you shed some light on this issue?

I asked our designer about the bus protection feature, here is his
response:

"
It's for unexpected signal glitch in Power switch process.

During Power switch process, we have clock switch, reset, isolation
enable/disable and  power switch involved where the transition of
asynchronous reset and  isolation is the most critical one,  which have
risk to introduce a unexpected short period signal transition from
MTCMOS’s interface to other alive HW . 
"

That means it protects unexpected bus accessing from HW, not from SW. So
it will not hide bugs from wrong SW access.


Best regards,

James

************* Email Confidentiality Notice ********************
The information contained in this e-mail message (including any 
attachments) may be confidential, proprietary, privileged, or otherwise
exempt from disclosure under applicable laws. It is intended to be 
conveyed only to the designated recipient(s). Any use, dissemination, 
distribution, printing, retaining or copying of this e-mail (including its 
attachments) by unintended recipient(s) is strictly prohibited and may 
be unlawful. If you are not an intended recipient of this e-mail, or believe 
that you have received this e-mail in error, please notify the sender 
immediately (by replying to this e-mail), delete any and all copies of 
this e-mail (including any attachments) from your system, and do not
disclose the content of this e-mail to any other person. Thank you!

^ permalink raw reply	[flat|nested] 40+ messages in thread

* Re: [PATCH 2/4] soc: Mediatek: Add SCPSYS power domain driver
@ 2015-03-11  3:16         ` James Liao
  0 siblings, 0 replies; 40+ messages in thread
From: James Liao @ 2015-03-11  3:16 UTC (permalink / raw)
  To: Sascha Hauer
  Cc: Kevin Hilman, linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
	devicetree-u79uwXL29TY76Z2rM5mHXA,
	linux-kernel-u79uwXL29TY76Z2rM5mHXA, Matthias Brugger,
	linux-mediatek-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
	kernel-bIcnvbaLZ9MEGnE8C9+IrQ

Hi,

On Tue, 2015-03-10 at 10:41 +0100, Sascha Hauer wrote:
> On Mon, Mar 09, 2015 at 02:35:03PM -0700, Kevin Hilman wrote:
> > Sascha Hauer <s.hauer-bIcnvbaLZ9MEGnE8C9+IrQ@public.gmane.org> writes:
> > 
> > > Signed-off-by: Sascha Hauer <s.hauer-bIcnvbaLZ9MEGnE8C9+IrQ@public.gmane.org>
> > 
> > A bit of a changelog here would be useful describing this driver, that
> > it's only covering part of the device (e.g. power controller) with more
> > to come, dependency on the syscon driver, etc.
> > 
> > > +/*
> > > + * The Infracfg unit has bus protection bits. We enable the bus protection
> > > + * for disabled power domains so that the system does not hang when some unit
> > > + * accesses the bus while in power down.
> > > + */
> > 
> > Hmm, why don't you want to know if some device is accessing another
> > device which is in a domain that is powered down?   Seems like this is a
> > good way to hide real bugs.
> 
> How I understand it the system just hangs on erroneous accesses without
> these protection bits enabled, so enabling them at least makes sure we
> can output something.
> I must admit though that my understanding of these bits is quite limited
> and the only user of this driver I have available here (audio) doesn't
> make use of these protection bits, so I can't test here.
> 
> James, could you shed some light on this issue?

I asked our designer about the bus protection feature, here is his
response:

"
It's for unexpected signal glitch in Power switch process.

During Power switch process, we have clock switch, reset, isolation
enable/disable and  power switch involved where the transition of
asynchronous reset and  isolation is the most critical one,  which have
risk to introduce a unexpected short period signal transition from
MTCMOS’s interface to other alive HW . 
"

That means it protects unexpected bus accessing from HW, not from SW. So
it will not hide bugs from wrong SW access.


Best regards,

James

************* Email Confidentiality Notice ********************
The information contained in this e-mail message (including any 
attachments) may be confidential, proprietary, privileged, or otherwise
exempt from disclosure under applicable laws. It is intended to be 
conveyed only to the designated recipient(s). Any use, dissemination, 
distribution, printing, retaining or copying of this e-mail (including its 
attachments) by unintended recipient(s) is strictly prohibited and may 
be unlawful. If you are not an intended recipient of this e-mail, or believe 
that you have received this e-mail in error, please notify the sender 
immediately (by replying to this e-mail), delete any and all copies of 
this e-mail (including any attachments) from your system, and do not
disclose the content of this e-mail to any other person. Thank you!
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

^ permalink raw reply	[flat|nested] 40+ messages in thread

* [PATCH 2/4] soc: Mediatek: Add SCPSYS power domain driver
@ 2015-03-11  3:16         ` James Liao
  0 siblings, 0 replies; 40+ messages in thread
From: James Liao @ 2015-03-11  3:16 UTC (permalink / raw)
  To: linux-arm-kernel

Hi,

On Tue, 2015-03-10 at 10:41 +0100, Sascha Hauer wrote:
> On Mon, Mar 09, 2015 at 02:35:03PM -0700, Kevin Hilman wrote:
> > Sascha Hauer <s.hauer@pengutronix.de> writes:
> > 
> > > Signed-off-by: Sascha Hauer <s.hauer@pengutronix.de>
> > 
> > A bit of a changelog here would be useful describing this driver, that
> > it's only covering part of the device (e.g. power controller) with more
> > to come, dependency on the syscon driver, etc.
> > 
> > > +/*
> > > + * The Infracfg unit has bus protection bits. We enable the bus protection
> > > + * for disabled power domains so that the system does not hang when some unit
> > > + * accesses the bus while in power down.
> > > + */
> > 
> > Hmm, why don't you want to know if some device is accessing another
> > device which is in a domain that is powered down?   Seems like this is a
> > good way to hide real bugs.
> 
> How I understand it the system just hangs on erroneous accesses without
> these protection bits enabled, so enabling them at least makes sure we
> can output something.
> I must admit though that my understanding of these bits is quite limited
> and the only user of this driver I have available here (audio) doesn't
> make use of these protection bits, so I can't test here.
> 
> James, could you shed some light on this issue?

I asked our designer about the bus protection feature, here is his
response:

"
It's for unexpected signal glitch in Power switch process.

During Power switch process, we have clock switch, reset, isolation
enable/disable and  power switch involved where the transition of
asynchronous reset and  isolation is the most critical one,  which have
risk to introduce a unexpected short period signal transition from
MTCMOS?s interface to other alive HW . 
"

That means it protects unexpected bus accessing from HW, not from SW. So
it will not hide bugs from wrong SW access.


Best regards,

James

************* Email Confidentiality Notice ********************
The information contained in this e-mail message (including any 
attachments) may be confidential, proprietary, privileged, or otherwise
exempt from disclosure under applicable laws. It is intended to be 
conveyed only to the designated recipient(s). Any use, dissemination, 
distribution, printing, retaining or copying of this e-mail (including its 
attachments) by unintended recipient(s) is strictly prohibited and may 
be unlawful. If you are not an intended recipient of this e-mail, or believe 
that you have received this e-mail in error, please notify the sender 
immediately (by replying to this e-mail), delete any and all copies of 
this e-mail (including any attachments) from your system, and do not
disclose the content of this e-mail to any other person. Thank you!

^ permalink raw reply	[flat|nested] 40+ messages in thread

* Re: [PATCH 2/4] soc: Mediatek: Add SCPSYS power domain driver
  2015-03-11  3:16         ` James Liao
  (?)
@ 2015-03-11  9:03           ` Sascha Hauer
  -1 siblings, 0 replies; 40+ messages in thread
From: Sascha Hauer @ 2015-03-11  9:03 UTC (permalink / raw)
  To: James Liao
  Cc: Kevin Hilman, linux-arm-kernel, devicetree, linux-kernel,
	Matthias Brugger, linux-mediatek, kernel

On Wed, Mar 11, 2015 at 11:16:31AM +0800, James Liao wrote:
> Hi,
> 
> On Tue, 2015-03-10 at 10:41 +0100, Sascha Hauer wrote:
> > On Mon, Mar 09, 2015 at 02:35:03PM -0700, Kevin Hilman wrote:
> > > Sascha Hauer <s.hauer@pengutronix.de> writes:
> > > 
> > > > Signed-off-by: Sascha Hauer <s.hauer@pengutronix.de>
> > > 
> > > A bit of a changelog here would be useful describing this driver, that
> > > it's only covering part of the device (e.g. power controller) with more
> > > to come, dependency on the syscon driver, etc.
> > > 
> > > > +/*
> > > > + * The Infracfg unit has bus protection bits. We enable the bus protection
> > > > + * for disabled power domains so that the system does not hang when some unit
> > > > + * accesses the bus while in power down.
> > > > + */
> > > 
> > > Hmm, why don't you want to know if some device is accessing another
> > > device which is in a domain that is powered down?   Seems like this is a
> > > good way to hide real bugs.
> > 
> > How I understand it the system just hangs on erroneous accesses without
> > these protection bits enabled, so enabling them at least makes sure we
> > can output something.
> > I must admit though that my understanding of these bits is quite limited
> > and the only user of this driver I have available here (audio) doesn't
> > make use of these protection bits, so I can't test here.
> > 
> > James, could you shed some light on this issue?
> 
> I asked our designer about the bus protection feature, here is his
> response:
> 
> "
> It's for unexpected signal glitch in Power switch process.
> 
> During Power switch process, we have clock switch, reset, isolation
> enable/disable and  power switch involved where the transition of
> asynchronous reset and  isolation is the most critical one,  which have
> risk to introduce a unexpected short period signal transition from
> MTCMOS’s interface to other alive HW . 
> "
> 
> That means it protects unexpected bus accessing from HW, not from SW. So
> it will not hide bugs from wrong SW access.

Ok, thanks for clarifying. This means we should enable this feature
sooner or later. Since the audio driver which is likely the first user
of this driver doesn't need the protection bits I think we have some
time and can add the protection bits once the clock patches have been
merged.

Sascha

-- 
Pengutronix e.K.                           |                             |
Industrial Linux Solutions                 | http://www.pengutronix.de/  |
Peiner Str. 6-8, 31137 Hildesheim, Germany | Phone: +49-5121-206917-0    |
Amtsgericht Hildesheim, HRA 2686           | Fax:   +49-5121-206917-5555 |

^ permalink raw reply	[flat|nested] 40+ messages in thread

* Re: [PATCH 2/4] soc: Mediatek: Add SCPSYS power domain driver
@ 2015-03-11  9:03           ` Sascha Hauer
  0 siblings, 0 replies; 40+ messages in thread
From: Sascha Hauer @ 2015-03-11  9:03 UTC (permalink / raw)
  To: James Liao
  Cc: Kevin Hilman, linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
	devicetree-u79uwXL29TY76Z2rM5mHXA,
	linux-kernel-u79uwXL29TY76Z2rM5mHXA, Matthias Brugger,
	linux-mediatek-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
	kernel-bIcnvbaLZ9MEGnE8C9+IrQ

On Wed, Mar 11, 2015 at 11:16:31AM +0800, James Liao wrote:
> Hi,
> 
> On Tue, 2015-03-10 at 10:41 +0100, Sascha Hauer wrote:
> > On Mon, Mar 09, 2015 at 02:35:03PM -0700, Kevin Hilman wrote:
> > > Sascha Hauer <s.hauer-bIcnvbaLZ9MEGnE8C9+IrQ@public.gmane.org> writes:
> > > 
> > > > Signed-off-by: Sascha Hauer <s.hauer-bIcnvbaLZ9MEGnE8C9+IrQ@public.gmane.org>
> > > 
> > > A bit of a changelog here would be useful describing this driver, that
> > > it's only covering part of the device (e.g. power controller) with more
> > > to come, dependency on the syscon driver, etc.
> > > 
> > > > +/*
> > > > + * The Infracfg unit has bus protection bits. We enable the bus protection
> > > > + * for disabled power domains so that the system does not hang when some unit
> > > > + * accesses the bus while in power down.
> > > > + */
> > > 
> > > Hmm, why don't you want to know if some device is accessing another
> > > device which is in a domain that is powered down?   Seems like this is a
> > > good way to hide real bugs.
> > 
> > How I understand it the system just hangs on erroneous accesses without
> > these protection bits enabled, so enabling them at least makes sure we
> > can output something.
> > I must admit though that my understanding of these bits is quite limited
> > and the only user of this driver I have available here (audio) doesn't
> > make use of these protection bits, so I can't test here.
> > 
> > James, could you shed some light on this issue?
> 
> I asked our designer about the bus protection feature, here is his
> response:
> 
> "
> It's for unexpected signal glitch in Power switch process.
> 
> During Power switch process, we have clock switch, reset, isolation
> enable/disable and  power switch involved where the transition of
> asynchronous reset and  isolation is the most critical one,  which have
> risk to introduce a unexpected short period signal transition from
> MTCMOS’s interface to other alive HW . 
> "
> 
> That means it protects unexpected bus accessing from HW, not from SW. So
> it will not hide bugs from wrong SW access.

Ok, thanks for clarifying. This means we should enable this feature
sooner or later. Since the audio driver which is likely the first user
of this driver doesn't need the protection bits I think we have some
time and can add the protection bits once the clock patches have been
merged.

Sascha

-- 
Pengutronix e.K.                           |                             |
Industrial Linux Solutions                 | http://www.pengutronix.de/  |
Peiner Str. 6-8, 31137 Hildesheim, Germany | Phone: +49-5121-206917-0    |
Amtsgericht Hildesheim, HRA 2686           | Fax:   +49-5121-206917-5555 |
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

^ permalink raw reply	[flat|nested] 40+ messages in thread

* [PATCH 2/4] soc: Mediatek: Add SCPSYS power domain driver
@ 2015-03-11  9:03           ` Sascha Hauer
  0 siblings, 0 replies; 40+ messages in thread
From: Sascha Hauer @ 2015-03-11  9:03 UTC (permalink / raw)
  To: linux-arm-kernel

On Wed, Mar 11, 2015 at 11:16:31AM +0800, James Liao wrote:
> Hi,
> 
> On Tue, 2015-03-10 at 10:41 +0100, Sascha Hauer wrote:
> > On Mon, Mar 09, 2015 at 02:35:03PM -0700, Kevin Hilman wrote:
> > > Sascha Hauer <s.hauer@pengutronix.de> writes:
> > > 
> > > > Signed-off-by: Sascha Hauer <s.hauer@pengutronix.de>
> > > 
> > > A bit of a changelog here would be useful describing this driver, that
> > > it's only covering part of the device (e.g. power controller) with more
> > > to come, dependency on the syscon driver, etc.
> > > 
> > > > +/*
> > > > + * The Infracfg unit has bus protection bits. We enable the bus protection
> > > > + * for disabled power domains so that the system does not hang when some unit
> > > > + * accesses the bus while in power down.
> > > > + */
> > > 
> > > Hmm, why don't you want to know if some device is accessing another
> > > device which is in a domain that is powered down?   Seems like this is a
> > > good way to hide real bugs.
> > 
> > How I understand it the system just hangs on erroneous accesses without
> > these protection bits enabled, so enabling them at least makes sure we
> > can output something.
> > I must admit though that my understanding of these bits is quite limited
> > and the only user of this driver I have available here (audio) doesn't
> > make use of these protection bits, so I can't test here.
> > 
> > James, could you shed some light on this issue?
> 
> I asked our designer about the bus protection feature, here is his
> response:
> 
> "
> It's for unexpected signal glitch in Power switch process.
> 
> During Power switch process, we have clock switch, reset, isolation
> enable/disable and  power switch involved where the transition of
> asynchronous reset and  isolation is the most critical one,  which have
> risk to introduce a unexpected short period signal transition from
> MTCMOS?s interface to other alive HW . 
> "
> 
> That means it protects unexpected bus accessing from HW, not from SW. So
> it will not hide bugs from wrong SW access.

Ok, thanks for clarifying. This means we should enable this feature
sooner or later. Since the audio driver which is likely the first user
of this driver doesn't need the protection bits I think we have some
time and can add the protection bits once the clock patches have been
merged.

Sascha

-- 
Pengutronix e.K.                           |                             |
Industrial Linux Solutions                 | http://www.pengutronix.de/  |
Peiner Str. 6-8, 31137 Hildesheim, Germany | Phone: +49-5121-206917-0    |
Amtsgericht Hildesheim, HRA 2686           | Fax:   +49-5121-206917-5555 |

^ permalink raw reply	[flat|nested] 40+ messages in thread

* Re: [PATCH 2/4] soc: Mediatek: Add SCPSYS power domain driver
  2015-03-11  9:03           ` Sascha Hauer
@ 2015-03-11 17:14             ` Kevin Hilman
  -1 siblings, 0 replies; 40+ messages in thread
From: Kevin Hilman @ 2015-03-11 17:14 UTC (permalink / raw)
  To: Sascha Hauer
  Cc: James Liao, linux-arm-kernel, devicetree, linux-kernel,
	Matthias Brugger, linux-mediatek, kernel

Sascha Hauer <s.hauer@pengutronix.de> writes:

> On Wed, Mar 11, 2015 at 11:16:31AM +0800, James Liao wrote:
>> Hi,
>> 
>> On Tue, 2015-03-10 at 10:41 +0100, Sascha Hauer wrote:
>> > On Mon, Mar 09, 2015 at 02:35:03PM -0700, Kevin Hilman wrote:
>> > > Sascha Hauer <s.hauer@pengutronix.de> writes:
>> > > 
>> > > > Signed-off-by: Sascha Hauer <s.hauer@pengutronix.de>
>> > > 
>> > > A bit of a changelog here would be useful describing this driver, that
>> > > it's only covering part of the device (e.g. power controller) with more
>> > > to come, dependency on the syscon driver, etc.
>> > > 
>> > > > +/*
>> > > > + * The Infracfg unit has bus protection bits. We enable the bus protection
>> > > > + * for disabled power domains so that the system does not hang when some unit
>> > > > + * accesses the bus while in power down.
>> > > > + */
>> > > 
>> > > Hmm, why don't you want to know if some device is accessing another
>> > > device which is in a domain that is powered down?   Seems like this is a
>> > > good way to hide real bugs.
>> > 
>> > How I understand it the system just hangs on erroneous accesses without
>> > these protection bits enabled, so enabling them at least makes sure we
>> > can output something.
>> > I must admit though that my understanding of these bits is quite limited
>> > and the only user of this driver I have available here (audio) doesn't
>> > make use of these protection bits, so I can't test here.
>> > 
>> > James, could you shed some light on this issue?
>> 
>> I asked our designer about the bus protection feature, here is his
>> response:
>> 
>> "
>> It's for unexpected signal glitch in Power switch process.
>> 
>> During Power switch process, we have clock switch, reset, isolation
>> enable/disable and  power switch involved where the transition of
>> asynchronous reset and  isolation is the most critical one,  which have
>> risk to introduce a unexpected short period signal transition from
>> MTCMOS’s interface to other alive HW . 
>> "
>> 
>> That means it protects unexpected bus accessing from HW, not from SW. So
>> it will not hide bugs from wrong SW access.
>
> Ok, thanks for clarifying. This means we should enable this feature
> sooner or later. Since the audio driver which is likely the first user
> of this driver doesn't need the protection bits I think we have some
> time and can add the protection bits once the clock patches have been
> merged.

Sounds OK to me.

But I still think it belongs in the infracfg layer, and not in the PM
domain layer.

Kevin

^ permalink raw reply	[flat|nested] 40+ messages in thread

* [PATCH 2/4] soc: Mediatek: Add SCPSYS power domain driver
@ 2015-03-11 17:14             ` Kevin Hilman
  0 siblings, 0 replies; 40+ messages in thread
From: Kevin Hilman @ 2015-03-11 17:14 UTC (permalink / raw)
  To: linux-arm-kernel

Sascha Hauer <s.hauer@pengutronix.de> writes:

> On Wed, Mar 11, 2015 at 11:16:31AM +0800, James Liao wrote:
>> Hi,
>> 
>> On Tue, 2015-03-10 at 10:41 +0100, Sascha Hauer wrote:
>> > On Mon, Mar 09, 2015 at 02:35:03PM -0700, Kevin Hilman wrote:
>> > > Sascha Hauer <s.hauer@pengutronix.de> writes:
>> > > 
>> > > > Signed-off-by: Sascha Hauer <s.hauer@pengutronix.de>
>> > > 
>> > > A bit of a changelog here would be useful describing this driver, that
>> > > it's only covering part of the device (e.g. power controller) with more
>> > > to come, dependency on the syscon driver, etc.
>> > > 
>> > > > +/*
>> > > > + * The Infracfg unit has bus protection bits. We enable the bus protection
>> > > > + * for disabled power domains so that the system does not hang when some unit
>> > > > + * accesses the bus while in power down.
>> > > > + */
>> > > 
>> > > Hmm, why don't you want to know if some device is accessing another
>> > > device which is in a domain that is powered down?   Seems like this is a
>> > > good way to hide real bugs.
>> > 
>> > How I understand it the system just hangs on erroneous accesses without
>> > these protection bits enabled, so enabling them at least makes sure we
>> > can output something.
>> > I must admit though that my understanding of these bits is quite limited
>> > and the only user of this driver I have available here (audio) doesn't
>> > make use of these protection bits, so I can't test here.
>> > 
>> > James, could you shed some light on this issue?
>> 
>> I asked our designer about the bus protection feature, here is his
>> response:
>> 
>> "
>> It's for unexpected signal glitch in Power switch process.
>> 
>> During Power switch process, we have clock switch, reset, isolation
>> enable/disable and  power switch involved where the transition of
>> asynchronous reset and  isolation is the most critical one,  which have
>> risk to introduce a unexpected short period signal transition from
>> MTCMOS?s interface to other alive HW . 
>> "
>> 
>> That means it protects unexpected bus accessing from HW, not from SW. So
>> it will not hide bugs from wrong SW access.
>
> Ok, thanks for clarifying. This means we should enable this feature
> sooner or later. Since the audio driver which is likely the first user
> of this driver doesn't need the protection bits I think we have some
> time and can add the protection bits once the clock patches have been
> merged.

Sounds OK to me.

But I still think it belongs in the infracfg layer, and not in the PM
domain layer.

Kevin

^ permalink raw reply	[flat|nested] 40+ messages in thread

* Re: [PATCH 2/4] soc: Mediatek: Add SCPSYS power domain driver
  2015-03-11 17:14             ` Kevin Hilman
@ 2015-03-12  7:21               ` Sascha Hauer
  -1 siblings, 0 replies; 40+ messages in thread
From: Sascha Hauer @ 2015-03-12  7:21 UTC (permalink / raw)
  To: Kevin Hilman
  Cc: James Liao, linux-arm-kernel, devicetree, linux-kernel,
	Matthias Brugger, linux-mediatek, kernel

On Wed, Mar 11, 2015 at 10:14:23AM -0700, Kevin Hilman wrote:
> Sascha Hauer <s.hauer@pengutronix.de> writes:
> 
> >> I asked our designer about the bus protection feature, here is his
> >> response:
> >> 
> >> "
> >> It's for unexpected signal glitch in Power switch process.
> >> 
> >> During Power switch process, we have clock switch, reset, isolation
> >> enable/disable and  power switch involved where the transition of
> >> asynchronous reset and  isolation is the most critical one,  which have
> >> risk to introduce a unexpected short period signal transition from
> >> MTCMOS’s interface to other alive HW . 
> >> "
> >> 
> >> That means it protects unexpected bus accessing from HW, not from SW. So
> >> it will not hide bugs from wrong SW access.
> >
> > Ok, thanks for clarifying. This means we should enable this feature
> > sooner or later. Since the audio driver which is likely the first user
> > of this driver doesn't need the protection bits I think we have some
> > time and can add the protection bits once the clock patches have been
> > merged.
> 
> Sounds OK to me.
> 
> But I still think it belongs in the infracfg layer, and not in the PM
> domain layer.

I already have plans how to put the code into the infracfg driver. Where
the code is going to be called from remains to be seen. The power domain
driver might or might not be a good place for it.

Sascha

-- 
Pengutronix e.K.                           |                             |
Industrial Linux Solutions                 | http://www.pengutronix.de/  |
Peiner Str. 6-8, 31137 Hildesheim, Germany | Phone: +49-5121-206917-0    |
Amtsgericht Hildesheim, HRA 2686           | Fax:   +49-5121-206917-5555 |

^ permalink raw reply	[flat|nested] 40+ messages in thread

* [PATCH 2/4] soc: Mediatek: Add SCPSYS power domain driver
@ 2015-03-12  7:21               ` Sascha Hauer
  0 siblings, 0 replies; 40+ messages in thread
From: Sascha Hauer @ 2015-03-12  7:21 UTC (permalink / raw)
  To: linux-arm-kernel

On Wed, Mar 11, 2015 at 10:14:23AM -0700, Kevin Hilman wrote:
> Sascha Hauer <s.hauer@pengutronix.de> writes:
> 
> >> I asked our designer about the bus protection feature, here is his
> >> response:
> >> 
> >> "
> >> It's for unexpected signal glitch in Power switch process.
> >> 
> >> During Power switch process, we have clock switch, reset, isolation
> >> enable/disable and  power switch involved where the transition of
> >> asynchronous reset and  isolation is the most critical one,  which have
> >> risk to introduce a unexpected short period signal transition from
> >> MTCMOS?s interface to other alive HW . 
> >> "
> >> 
> >> That means it protects unexpected bus accessing from HW, not from SW. So
> >> it will not hide bugs from wrong SW access.
> >
> > Ok, thanks for clarifying. This means we should enable this feature
> > sooner or later. Since the audio driver which is likely the first user
> > of this driver doesn't need the protection bits I think we have some
> > time and can add the protection bits once the clock patches have been
> > merged.
> 
> Sounds OK to me.
> 
> But I still think it belongs in the infracfg layer, and not in the PM
> domain layer.

I already have plans how to put the code into the infracfg driver. Where
the code is going to be called from remains to be seen. The power domain
driver might or might not be a good place for it.

Sascha

-- 
Pengutronix e.K.                           |                             |
Industrial Linux Solutions                 | http://www.pengutronix.de/  |
Peiner Str. 6-8, 31137 Hildesheim, Germany | Phone: +49-5121-206917-0    |
Amtsgericht Hildesheim, HRA 2686           | Fax:   +49-5121-206917-5555 |

^ permalink raw reply	[flat|nested] 40+ messages in thread

end of thread, other threads:[~2015-03-12  7:22 UTC | newest]

Thread overview: 40+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2015-03-09  8:09 [RFC] Mediatek SCPSYS power domain support Sascha Hauer
2015-03-09  8:09 ` Sascha Hauer
2015-03-09  8:09 ` Sascha Hauer
2015-03-09  8:10 ` [PATCH 1/4] dt-bindings: soc: Add documentation for the MediaTek SCPSYS unit Sascha Hauer
2015-03-09  8:10   ` Sascha Hauer
2015-03-09 20:46   ` Kevin Hilman
2015-03-09 20:46     ` Kevin Hilman
2015-03-10  8:02     ` Sascha Hauer
2015-03-10  8:02       ` Sascha Hauer
2015-03-10  8:02       ` Sascha Hauer
2015-03-09  8:10 ` [PATCH 2/4] soc: Mediatek: Add SCPSYS power domain driver Sascha Hauer
2015-03-09  8:10   ` Sascha Hauer
2015-03-09 21:35   ` Kevin Hilman
2015-03-09 21:35     ` Kevin Hilman
2015-03-10  9:41     ` Sascha Hauer
2015-03-10  9:41       ` Sascha Hauer
2015-03-10  9:41       ` Sascha Hauer
2015-03-10 14:40       ` Sascha Hauer
2015-03-10 14:40         ` Sascha Hauer
2015-03-10 16:00         ` Kevin Hilman
2015-03-10 16:00           ` Kevin Hilman
2015-03-10 16:00           ` Kevin Hilman
2015-03-11  3:16       ` James Liao
2015-03-11  3:16         ` James Liao
2015-03-11  3:16         ` James Liao
2015-03-11  9:03         ` Sascha Hauer
2015-03-11  9:03           ` Sascha Hauer
2015-03-11  9:03           ` Sascha Hauer
2015-03-11 17:14           ` Kevin Hilman
2015-03-11 17:14             ` Kevin Hilman
2015-03-12  7:21             ` Sascha Hauer
2015-03-12  7:21               ` Sascha Hauer
2015-03-09  8:10 ` [PATCH 3/4] ARM64: MediaTek: Add generic pm domain support Sascha Hauer
2015-03-09  8:10   ` Sascha Hauer
2015-03-09  8:10   ` Sascha Hauer
2015-03-09  8:10 ` [PATCH 4/4] ARM64: MediaTek MT8173: Add SCPSYS device node Sascha Hauer
2015-03-09  8:10   ` Sascha Hauer
2015-03-09  8:10   ` Sascha Hauer
2015-03-09 20:43 ` [RFC] Mediatek SCPSYS power domain support Kevin Hilman
2015-03-09 20:43   ` Kevin Hilman

This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.