[PATCH 2/4] soc: Mediatek: Add SCPSYS power domain driver
From: khilman@kernel.org (Kevin Hilman)
Date: 2015-05-28 17:22:53
Also in:
linux-devicetree, linux-mediatek, lkml
Sascha Hauer [off-list ref] writes:
On Tue, May 26, 2015 at 03:35:14PM -0700, Kevin Hilman wrote:quoted
Sascha Hauer [off-list ref] writes:quoted
This adds a power domain driver for the Mediatek SCPSYS unit. 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. For now this driver only adds power domain support, the more advanced features are not yet supported. The driver implements the generic PM domain device tree bindings, the first user will most likely be the Mediatek AFE audio driver. 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 | 345 +++++++++++++++++++++++++++++++ include/dt-bindings/power/mt8173-power.h | 15 ++ 4 files changed, 367 insertions(+) create mode 100644 drivers/soc/mediatek/mtk-scpsys.c create mode 100644 include/dt-bindings/power/mt8173-power.hdiff --git a/drivers/soc/mediatek/Kconfig b/drivers/soc/mediatek/Kconfig index bcdb22d..1d34819 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 different MediaTek SoCs. The PMIC wrapper is a proprietary hardware to connect the PMIC. + +config MTK_SCPSYS + tristate "MediaTek SCPSYS Support"depends on ARCH_MEDIATEK ?You are reviewing v2 of this series. This is already fixed in v3 sent out last wednesday.
Yeah, sorry about that. I noticed that after sending.
quoted
quoted
+ 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;I think I mentioned this before... are these numbers really identical for all domains? I suggest you make these each a field in the domain data so they can be different for each domain, and eventually come from DT data.For the record, here are the numbers I just measured: mtk-scpsys 10006000.scpsys: vdec on: 31000 off: 10769 mtk-scpsys 10006000.scpsys: venc on: 6000 off: 5923 mtk-scpsys 10006000.scpsys: isp on: 5923 off: 5923 mtk-scpsys 10006000.scpsys: mm on: 7616 off: 7692 mtk-scpsys 10006000.scpsys: venc_lt on: 5924 off: 6000 mtk-scpsys 10006000.scpsys: audio on: 5462 off: 5615 mtk-scpsys 10006000.scpsys: usb on: 5461 off: 5462 mtk-scpsys 10006000.scpsys: mfg_async on: 29923 off: 11077 mtk-scpsys 10006000.scpsys: mfg_2d on: 5923 off: 5616 mtk-scpsys 10006000.scpsys: mfg on: 11231 off: 16153 Anyway, the pm domain core measures these times itself, so there should not be a need to fill in anything here. I was irritated by the warning message I got each time when the times were exceeded. This message seemed to imply that something was wrong and I had to fill in sane values in the latency fields. Since we now have [1] I'll just drop the initialisation of these fields.
OK. However, I suspect you will still want these numbers on a per-domain basis eventually when you consider having genpd governors that want to make decisions. But that can always be added later also. Kevin