diff mbox

[RESEND,2/6] soc: Mediatek: Add SCPSYS CPU power domain driver

Message ID 1434650481-39421-3-git-send-email-scott.shu@mediatek.com (mailing list archive)
State New, archived
Headers show

Commit Message

Scott Shu June 18, 2015, 6:01 p.m. UTC
This adds a CPU power domain driver for the Mediatek SCPSYS unit on
MT6580.
---
 arch/arm/mach-mediatek/Makefile  |   2 +-
 arch/arm/mach-mediatek/generic.h |  24 +++++
 arch/arm/mach-mediatek/hotplug.c | 228 +++++++++++++++++++++++++++++++++++++++
 3 files changed, 253 insertions(+), 1 deletion(-)
 create mode 100644 arch/arm/mach-mediatek/generic.h
 create mode 100644 arch/arm/mach-mediatek/hotplug.c

Comments

Sascha Hauer June 23, 2015, 5:53 a.m. UTC | #1
Hi Scott,

On Fri, Jun 19, 2015 at 02:01:17AM +0800, Scott Shu wrote:
> This adds a CPU power domain driver for the Mediatek SCPSYS unit on
> MT6580.

This seems to be support for the very same hardware as I am posting
here:

https://lkml.org/lkml/2015/6/22/41

We should consolidate this.

My driver is currently handles all power domains except the CPUs while
yours handles only the CPUs.
I currently haven't looked whether CPUs can just be part of a power
domain aswell, but if that works this would probably be the way to go.

Sascha
Scott Shu July 3, 2015, 5:58 a.m. UTC | #2
Hi Sascha,
   I just wonder can we separate the MTCMOS into cpu and non-cpu part? 
Just like qcom's xcc driver, they put cpu related code under
"arch/arm/mach-xxx" but put the others under "driver".

Thanks,
Scott  

On Tue, 2015-06-23 at 07:53 +0200, Sascha Hauer wrote:
> Hi Scott,
> 
> On Fri, Jun 19, 2015 at 02:01:17AM +0800, Scott Shu wrote:
> > This adds a CPU power domain driver for the Mediatek SCPSYS unit on
> > MT6580.
> 
> This seems to be support for the very same hardware as I am posting
> here:
> 
> https://lkml.org/lkml/2015/6/22/41
> 
> We should consolidate this.
> 
> My driver is currently handles all power domains except the CPUs while
> yours handles only the CPUs.
> I currently haven't looked whether CPUs can just be part of a power
> domain aswell, but if that works this would probably be the way to go.
> 
> Sascha
> 
>
Scott Shu July 24, 2015, 2:02 a.m. UTC | #3
On Tue, 2015-06-23 at 07:53 +0200, Sascha Hauer wrote:
> Hi Scott,
> 
> On Fri, Jun 19, 2015 at 02:01:17AM +0800, Scott Shu wrote:
> > This adds a CPU power domain driver for the Mediatek SCPSYS unit on
> > MT6580.
> 
> This seems to be support for the very same hardware as I am posting
> here:
> 
> https://lkml.org/lkml/2015/6/22/41
> 
> We should consolidate this.
> 
> My driver is currently handles all power domains except the CPUs while
> yours handles only the CPUs.
> I currently haven't looked whether CPUs can just be part of a power
> domain aswell, but if that works this would probably be the way to go.
> 
> Sascha
> 
> 
Hi Sascga,

We had posted new patch set in following link, but still keep our
original framework.
http://lists.infradead.org/pipermail/linux-mediatek/2015-July/001498.html

As we mentioned in the new email thread, the SMP operations (smp_boot_secondary)
will be executed before registering the scpsys_drv driver, so the CPUs power
domain is controlled on arch/arm/mach-$(MACHINE) directory. 

Please kindly provide your comments and suggestion. Thank you very much. 

Best Regards,
Scott Shu
Sascha Hauer July 24, 2015, 5:50 a.m. UTC | #4
On Fri, Jul 24, 2015 at 10:02:03AM +0800, Scott Shu wrote:
> On Tue, 2015-06-23 at 07:53 +0200, Sascha Hauer wrote:
> > Hi Scott,
> > 
> > On Fri, Jun 19, 2015 at 02:01:17AM +0800, Scott Shu wrote:
> > > This adds a CPU power domain driver for the Mediatek SCPSYS unit on
> > > MT6580.
> > 
> > This seems to be support for the very same hardware as I am posting
> > here:
> > 
> > https://lkml.org/lkml/2015/6/22/41
> > 
> > We should consolidate this.
> > 
> > My driver is currently handles all power domains except the CPUs while
> > yours handles only the CPUs.
> > I currently haven't looked whether CPUs can just be part of a power
> > domain aswell, but if that works this would probably be the way to go.
> > 
> > Sascha
> > 
> > 
> Hi Sascga,
> 
> We had posted new patch set in following link, but still keep our
> original framework.
> http://lists.infradead.org/pipermail/linux-mediatek/2015-July/001498.html
> 
> As we mentioned in the new email thread, the SMP operations (smp_boot_secondary)
> will be executed before registering the scpsys_drv driver, so the CPUs power
> domain is controlled on arch/arm/mach-$(MACHINE) directory. 
> 
> Please kindly provide your comments and suggestion. Thank you very much.

I think that instead of explaining why have to duplicate the code you
should rather search for ways how the code can be shared. Yes, we'll
need a second (early) entry point to the driver. Maybe we even have to
create the shared code which is then called from the driver and your
early architecture code.
You'll probably have to do this separation between early code and
regular driver code in your driver anyway, since I bet the MT6580 also
has some power domains which shall be controlled by the regular Linux
power domain code later. Also we probably could control the CPU power
domains for the MT8173 in the SCPSYS driver aswell, we just don't have
to because we use PSCI there. You see we are approaching the same
problem from two different corners. Let's find a way to share the code.

Sascha
Scott Shu July 25, 2015, 9:13 a.m. UTC | #5
On Fri, 2015-07-24 at 07:50 +0200, Sascha Hauer wrote:
> On Fri, Jul 24, 2015 at 10:02:03AM +0800, Scott Shu wrote:
> > On Tue, 2015-06-23 at 07:53 +0200, Sascha Hauer wrote:
> > > Hi Scott,
> > > 
> > > On Fri, Jun 19, 2015 at 02:01:17AM +0800, Scott Shu wrote:
> > > > This adds a CPU power domain driver for the Mediatek SCPSYS unit on
> > > > MT6580.
> > > 
> > > This seems to be support for the very same hardware as I am posting
> > > here:
> > > 
> > > https://lkml.org/lkml/2015/6/22/41
> > > 
> > > We should consolidate this.
> > > 
> > > My driver is currently handles all power domains except the CPUs while
> > > yours handles only the CPUs.
> > > I currently haven't looked whether CPUs can just be part of a power
> > > domain aswell, but if that works this would probably be the way to go.
> > > 
> > > Sascha
> > > 
> > > 
> > Hi Sascga,
> > 
> > We had posted new patch set in following link, but still keep our
> > original framework.
> > http://lists.infradead.org/pipermail/linux-mediatek/2015-July/001498.html
> > 
> > As we mentioned in the new email thread, the SMP operations (smp_boot_secondary)
> > will be executed before registering the scpsys_drv driver, so the CPUs power
> > domain is controlled on arch/arm/mach-$(MACHINE) directory. 
> > 
> > Please kindly provide your comments and suggestion. Thank you very much.
> 
> I think that instead of explaining why have to duplicate the code you
> should rather search for ways how the code can be shared. Yes, we'll
> need a second (early) entry point to the driver. Maybe we even have to
> create the shared code which is then called from the driver and your
> early architecture code.
> You'll probably have to do this separation between early code and
> regular driver code in your driver anyway, since I bet the MT6580 also
> has some power domains which shall be controlled by the regular Linux
> power domain code later. Also we probably could control the CPU power
> domains for the MT8173 in the SCPSYS driver aswell, we just don't have
> to because we use PSCI there. You see we are approaching the same
> problem from two different corners. Let's find a way to share the code.
> 
> Sascha
> 
Hi Sascha,
   Thanks. OK, we move all CPU MTCMOS driver from hotplug.c to
mtk-scpsys.c and the test is passed. Next, we need spend some time to
integrate the code better.

Scott
Matthias Brugger July 27, 2015, 10:22 a.m. UTC | #6
On Saturday, July 25, 2015 05:13:00 PM Scott Shu wrote:
> On Fri, 2015-07-24 at 07:50 +0200, Sascha Hauer wrote:
> > On Fri, Jul 24, 2015 at 10:02:03AM +0800, Scott Shu wrote:
> > > On Tue, 2015-06-23 at 07:53 +0200, Sascha Hauer wrote:
> > > > Hi Scott,
> > > > 
> > > > On Fri, Jun 19, 2015 at 02:01:17AM +0800, Scott Shu wrote:
> > > > > This adds a CPU power domain driver for the Mediatek SCPSYS unit on
> > > > > MT6580.
> > > > 
> > > > This seems to be support for the very same hardware as I am posting
> > > > here:
> > > > 
> > > > https://lkml.org/lkml/2015/6/22/41
> > > > 
> > > > We should consolidate this.
> > > > 
> > > > My driver is currently handles all power domains except the CPUs while
> > > > yours handles only the CPUs.
> > > > I currently haven't looked whether CPUs can just be part of a power
> > > > domain aswell, but if that works this would probably be the way to go.
> > > > 
> > > > Sascha
> > > 
> > > Hi Sascga,
> > > 
> > > We had posted new patch set in following link, but still keep our
> > > original framework.
> > > http://lists.infradead.org/pipermail/linux-mediatek/2015-July/001498.htm
> > > l
> > > 
> > > As we mentioned in the new email thread, the SMP operations
> > > (smp_boot_secondary) will be executed before registering the scpsys_drv
> > > driver, so the CPUs power domain is controlled on
> > > arch/arm/mach-$(MACHINE) directory.
> > > 
> > > Please kindly provide your comments and suggestion. Thank you very much.
> > 
> > I think that instead of explaining why have to duplicate the code you
> > should rather search for ways how the code can be shared. Yes, we'll
> > need a second (early) entry point to the driver. Maybe we even have to
> > create the shared code which is then called from the driver and your
> > early architecture code.
> > You'll probably have to do this separation between early code and
> > regular driver code in your driver anyway, since I bet the MT6580 also
> > has some power domains which shall be controlled by the regular Linux
> > power domain code later. Also we probably could control the CPU power
> > domains for the MT8173 in the SCPSYS driver aswell, we just don't have
> > to because we use PSCI there. You see we are approaching the same
> > problem from two different corners. Let's find a way to share the code.
> > 
> > Sascha
> 
> Hi Sascha,
>    Thanks. OK, we move all CPU MTCMOS driver from hotplug.c to
> mtk-scpsys.c and the test is passed. Next, we need spend some time to
> integrate the code better.
> 

Good to hear that. We should try to keep mach-mediatek code a little as 
possible.

Cheers,
Matthias
diff mbox

Patch

diff --git a/arch/arm/mach-mediatek/Makefile b/arch/arm/mach-mediatek/Makefile
index 2116460..b2e4ef5 100644
--- a/arch/arm/mach-mediatek/Makefile
+++ b/arch/arm/mach-mediatek/Makefile
@@ -1,4 +1,4 @@ 
 ifeq ($(CONFIG_SMP),y)
-obj-$(CONFIG_ARCH_MEDIATEK) += platsmp.o
+obj-$(CONFIG_ARCH_MEDIATEK) += platsmp.o hotplug.o
 endif
 obj-$(CONFIG_ARCH_MEDIATEK) += mediatek.o
diff --git a/arch/arm/mach-mediatek/generic.h b/arch/arm/mach-mediatek/generic.h
new file mode 100644
index 0000000..2a0d0c8
--- /dev/null
+++ b/arch/arm/mach-mediatek/generic.h
@@ -0,0 +1,24 @@ 
+/*
+ * Copyright (c) 2015 Mediatek Inc.
+ * Author: Scott Shu <scott.shu@mediatek.com>
+ *
+ * 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.
+ *
+ */
+#ifndef __MACH_MTK_COMMON__
+#define __MACH_MTK_COMMON__
+
+#include <linux/kernel.h>
+
+int spm_cpu_mtcmos_init(void);
+int spm_cpu_mtcmos_on(int cpu);
+int spm_cpu_mtcmos_off(int cpu, bool wfi);
+
+#endif
diff --git a/arch/arm/mach-mediatek/hotplug.c b/arch/arm/mach-mediatek/hotplug.c
new file mode 100644
index 0000000..be0305d
--- /dev/null
+++ b/arch/arm/mach-mediatek/hotplug.c
@@ -0,0 +1,228 @@ 
+/*
+ * Copyright (c) 2015 Mediatek Inc.
+ * Author: Scott Shu <scott.shu@mediatek.com>
+ *
+ * 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/init.h>
+#include <linux/module.h>
+#include <linux/kernel.h>
+#include <linux/spinlock.h>
+#include <linux/delay.h>
+#include <linux/of.h>
+#include <linux/of_irq.h>
+#include <linux/of_address.h>
+
+/* SCPSYS registers */
+#define SPM_POWERON_CONFIG_SET		0x0000
+
+#define SPM_CA7_CPU0_PWR_CON		0x0200
+#define SPM_CA7_CPU1_PWR_CON		0x0218
+#define SPM_CA7_CPU2_PWR_CON		0x021c
+#define SPM_CA7_CPU3_PWR_CON		0x0220
+
+#define SPM_CA7_CPU0_L1_PDN		0x025c
+#define SPM_CA7_CPU1_L1_PDN		0x0264
+#define SPM_CA7_CPU2_L1_PDN		0x026c
+#define SPM_CA7_CPU3_L1_PDN		0x0274
+
+#define SPM_PWR_STATUS			0x060c
+#define SPM_PWR_STATUS_2ND		0x0610
+#define SPM_SLEEP_TIMER_STA		0x0720
+
+/*
+ * bit definition in SPM_CA7_CPUx_PWR_CON
+ */
+#define SRAM_ISOINT_B		BIT(6)
+#define SRAM_CKISO		BIT(5)
+#define PWR_CLK_DIS		BIT(4)
+#define PWR_ON_2ND		BIT(3)
+#define PWR_ON			BIT(2)
+#define PWR_ISO			BIT(1)
+#define PWR_RST_B		BIT(0)
+
+/*
+ * bit definition in SPM_CA7_CPUx_L1_PDN
+ */
+#define L1_PDN_ACK		BIT(8)
+#define L1_PDN			BIT(0)
+
+void __iomem *spm_cpu_base;
+
+u32 spm_cpu_pwr_con[4] = {
+	SPM_CA7_CPU0_PWR_CON,
+	SPM_CA7_CPU1_PWR_CON,
+	SPM_CA7_CPU2_PWR_CON,
+	SPM_CA7_CPU3_PWR_CON,
+};
+
+u32 spm_cpu_l1_pdn[4] = {
+	SPM_CA7_CPU0_L1_PDN,
+	SPM_CA7_CPU1_L1_PDN,
+	SPM_CA7_CPU2_L1_PDN,
+	SPM_CA7_CPU3_L1_PDN,
+};
+
+#define SPM_REGWR_EN		(1U << 0)
+#define SPM_PROJECT_CODE	0x0B16
+
+int spm_cpu_mtcmos_on(int cpu)
+{
+	static DEFINE_SPINLOCK(spm_cpu_lock);
+	unsigned long flags;
+	static u32 spmcpu_pwr_con, spmcpu_l1_pdn;
+	unsigned int temp;
+
+	temp = (SPM_PROJECT_CODE << 16) | SPM_REGWR_EN;
+	writel_relaxed(temp, spm_cpu_base + SPM_POWERON_CONFIG_SET);
+
+	spmcpu_pwr_con = spm_cpu_pwr_con[cpu];
+	spmcpu_l1_pdn = spm_cpu_l1_pdn[cpu];
+
+	spin_lock_irqsave(&spm_cpu_lock, flags);
+
+	temp = readl_relaxed(spm_cpu_base + spmcpu_pwr_con);
+	temp |= PWR_ON;
+	writel_relaxed(temp, spm_cpu_base + spmcpu_pwr_con);
+
+	udelay(1);
+
+	temp = readl_relaxed(spm_cpu_base + spmcpu_pwr_con);
+	temp |= PWR_ON_2ND;
+	writel_relaxed(temp, spm_cpu_base + spmcpu_pwr_con);
+
+	while (((readl_relaxed(spm_cpu_base + SPM_PWR_STATUS) &
+		(1U << (13 - cpu))) != (1U << (13 - cpu))) ||
+		((readl_relaxed(spm_cpu_base + SPM_PWR_STATUS_2ND) &
+		(1U << (13 - cpu))) != (1U << (13 - cpu)))) {
+		;
+	}
+
+	temp = readl_relaxed(spm_cpu_base + spmcpu_pwr_con);
+	temp &= ~PWR_ISO;
+	writel_relaxed(temp, spm_cpu_base + spmcpu_pwr_con);
+
+	/* L1 power on */
+	temp = readl_relaxed(spm_cpu_base + spmcpu_l1_pdn);
+	temp &= ~L1_PDN;
+	writel_relaxed(temp, spm_cpu_base + spmcpu_l1_pdn);
+	while ((readl_relaxed(spm_cpu_base + spmcpu_l1_pdn) &
+		L1_PDN_ACK) != 0)
+		;
+
+	udelay(1);
+	temp = readl_relaxed(spm_cpu_base + spmcpu_pwr_con);
+	temp |= SRAM_ISOINT_B;
+	writel_relaxed(temp, spm_cpu_base + spmcpu_pwr_con);
+
+	temp = readl_relaxed(spm_cpu_base + spmcpu_pwr_con);
+	temp &= ~SRAM_CKISO;
+	writel_relaxed(temp, spm_cpu_base + spmcpu_pwr_con);
+
+	temp = readl_relaxed(spm_cpu_base + spmcpu_pwr_con);
+	temp &= ~PWR_CLK_DIS;
+	writel_relaxed(temp, spm_cpu_base + spmcpu_pwr_con);
+
+	temp = readl_relaxed(spm_cpu_base + spmcpu_pwr_con);
+	temp |= PWR_RST_B;
+	writel_relaxed(temp, spm_cpu_base + spmcpu_pwr_con);
+
+	spin_unlock_irqrestore(&spm_cpu_lock, flags);
+
+	return 0;
+}
+
+int spm_cpu_mtcmos_off(int cpu, bool wfi)
+{
+	static DEFINE_SPINLOCK(spm_cpu_lock);
+	unsigned long flags;
+	static u32 spmcpu_pwr_con, spmcpu_l1_pdn;
+	unsigned int temp;
+
+	temp = (SPM_PROJECT_CODE << 16) | SPM_REGWR_EN;
+	writel_relaxed(temp, spm_cpu_base + SPM_POWERON_CONFIG_SET);
+
+	spmcpu_pwr_con = spm_cpu_pwr_con[cpu];
+	spmcpu_l1_pdn = spm_cpu_l1_pdn[cpu];
+
+	if (wfi) {
+		while ((readl_relaxed(spm_cpu_base + SPM_SLEEP_TIMER_STA) &
+			(1U << (16 + cpu))) == 0)
+			;
+	}
+
+	spin_lock_irqsave(&spm_cpu_lock, flags);
+
+	temp = readl_relaxed(spm_cpu_base + spmcpu_pwr_con);
+	temp |= PWR_ISO;
+	writel_relaxed(temp, spm_cpu_base + spmcpu_pwr_con);
+
+	temp = readl_relaxed(spm_cpu_base + spmcpu_pwr_con);
+	temp |= SRAM_CKISO;
+	writel_relaxed(temp, spm_cpu_base + spmcpu_pwr_con);
+
+	temp = readl_relaxed(spm_cpu_base + spmcpu_pwr_con);
+	temp &= ~SRAM_ISOINT_B;
+	writel_relaxed(temp, spm_cpu_base + spmcpu_pwr_con);
+
+	/* L1 power off */
+	temp = readl_relaxed(spm_cpu_base + spmcpu_l1_pdn);
+	temp |= L1_PDN;
+	writel_relaxed(temp, spm_cpu_base + spmcpu_l1_pdn);
+	while ((readl_relaxed(spm_cpu_base + spmcpu_l1_pdn)
+		& L1_PDN_ACK) != L1_PDN_ACK)
+		;
+
+	temp = readl_relaxed(spm_cpu_base + spmcpu_pwr_con);
+	temp &= ~PWR_RST_B;
+	writel_relaxed(temp, spm_cpu_base + spmcpu_pwr_con);
+
+	temp = readl_relaxed(spm_cpu_base + spmcpu_pwr_con);
+	temp |= PWR_CLK_DIS;
+	writel_relaxed(temp, spm_cpu_base + spmcpu_pwr_con);
+
+	temp = readl_relaxed(spm_cpu_base + spmcpu_pwr_con);
+	temp &= ~PWR_ON;
+	writel_relaxed(temp, spm_cpu_base + spmcpu_pwr_con);
+
+	temp = readl_relaxed(spm_cpu_base + spmcpu_pwr_con);
+	temp &= ~PWR_ON_2ND;
+	writel_relaxed(temp, spm_cpu_base + spmcpu_pwr_con);
+
+	while (((readl_relaxed(spm_cpu_base + SPM_PWR_STATUS) &
+		(1U << (13 - cpu))) != 0) ||
+	       ((readl_relaxed(spm_cpu_base + SPM_PWR_STATUS_2ND) &
+		(1U << (13 - cpu))) != 0))
+		;
+
+	spin_unlock_irqrestore(&spm_cpu_lock, flags);
+
+	return 0;
+}
+
+int spm_cpu_mtcmos_init(void)
+{
+	struct device_node *node;
+
+	node = of_find_compatible_node(NULL, NULL, "mediatek,mt6580-scpsys");
+	if (!node) {
+		pr_err("Missing mt6580-scpsys node in the device tree\n");
+		return -EINVAL;
+	}
+
+	spm_cpu_base = of_iomap(node, 0);
+	if (!spm_cpu_base) {
+		pr_err("%s: Unable to map I/O memory\n", __func__);
+		return -EINVAL;
+	}
+
+	return 0;
+}