| Message ID | 1399704998-13321-7-git-send-email-pankaj.dubey@samsung.com (mailing list archive) |
|---|---|
| State | New, archived |
| Headers | show |
Hi, On 10.05.2014 08:56, Pankaj Dubey wrote: > From: Young-Gun Jang <yg1004.jang@samsung.com> > > Add support for mapping Samsung Power Management Unit (PMU) > base address from device tree. This patch also adds helper > function as "get_exynos_pmuregmap". This function can be used > by other machine files such as "pm.c", "hotplug.c" for accessing > PMU regmap handle. > I don't think there is a need to use regmap to provide access to PMU to such low level code such as pm.c or hotplug.c. Moreover, I believe that it might be undesirable in some cases, e.g. very low level code running at early resume or late suspend. IMHO, based on what we now have for SYSRAM, you could simply map PMU from device tree one time, before SMP init, and keep the address in some globally accessible variable, like those for SYSRAM we have right now (sysram_base_addr, sysram_ns_base_addr -> pmu_base_addr). Then, registration of the normal syscon would happen through standard platform driver mechanisms and no special early handling would be necessary. Best regards, Tomasz
Hi Tomasz, > Hi, > > On 10.05.2014 08:56, Pankaj Dubey wrote: > > From: Young-Gun Jang <yg1004.jang@samsung.com> > > > > Add support for mapping Samsung Power Management Unit (PMU) base > > address from device tree. This patch also adds helper function as > > "get_exynos_pmuregmap". This function can be used by other machine > > files such as "pm.c", "hotplug.c" for accessing PMU regmap handle. > > > > I don't think there is a need to use regmap to provide access to PMU to such low > level code such as pm.c or hotplug.c. Moreover, I believe that it might be undesirable > in some cases, e.g. very low level code running at early resume or late suspend. > > IMHO, based on what we now have for SYSRAM, you could simply map PMU from > device tree one time, before SMP init, and keep the address in some globally > accessible variable, like those for SYSRAM we have right now (sysram_base_addr, > sysram_ns_base_addr -> pmu_base_addr). > Thanks for review. Well I adopted same approach in V1 of this patch series. V1: https://lkml.org/lkml/2014/4/2/48 So, if we do not have issues with that approach, I think we can map PMU address one time and use it for all machine files including pmu.c. Also I can see that early_syscon patch [1] is not progressing anymore, so in next version of this series better I remove dependency of early syscon and usage of regmap. 1: https://lkml.org/lkml/2014/4/8/239 Tomasz, It will be good if you can review remaining patches under this series, specially patch [2]. So that, I can update this series after addressing all comments. 2: https://lkml.org/lkml/2014/5/10/26 > Then, registration of the normal syscon would happen through standard platform > driver mechanisms and no special early handling would be necessary. > > Best regards, > Tomasz Thanks, Pankaj Dubey
Hi Pankaj, On 17.06.2014 08:43, Pankaj Dubey wrote: > Hi Tomasz, > >> Hi, >> >> On 10.05.2014 08:56, Pankaj Dubey wrote: >>> From: Young-Gun Jang <yg1004.jang@samsung.com> >>> >>> Add support for mapping Samsung Power Management Unit (PMU) base >>> address from device tree. This patch also adds helper function as >>> "get_exynos_pmuregmap". This function can be used by other machine >>> files such as "pm.c", "hotplug.c" for accessing PMU regmap handle. >>> >> >> I don't think there is a need to use regmap to provide access to PMU to > such low >> level code such as pm.c or hotplug.c. Moreover, I believe that it might be > undesirable >> in some cases, e.g. very low level code running at early resume or late > suspend. >> >> IMHO, based on what we now have for SYSRAM, you could simply map PMU from >> device tree one time, before SMP init, and keep the address in some > globally >> accessible variable, like those for SYSRAM we have right now > (sysram_base_addr, >> sysram_ns_base_addr -> pmu_base_addr). >> > > Thanks for review. > > Well I adopted same approach in V1 of this patch series. > > V1: https://lkml.org/lkml/2014/4/2/48 > > So, if we do not have issues with that approach, I think we can map PMU > address > one time and use it for all machine files including pmu.c. The approach itself is fine, but I believe there is no reason to use fdt there. My recommendation is to follow the method used to map SYSRAMs in patch "b3205dea8f ARM: EXYNOS: Map SYSRAM through generic DT bindings" and taking into account patch "b87abf7deb ARM: exynos: move sysram info to exynos.c", which moves things around source files. > Also I can see that early_syscon patch [1] is not progressing anymore, > so in next version of this series better I remove dependency of early syscon > and usage > of regmap. I have another proposal, basically something I already proposed in review of one of previous versions of this series. I will send a patch as a reply to this message. > > 1: https://lkml.org/lkml/2014/4/8/239 > > Tomasz, It will be good if you can review remaining patches under this > series, specially patch [2]. > So that, I can update this series after addressing all comments. > > 2: https://lkml.org/lkml/2014/5/10/26 > Most of the patches have already received my reviewed-by tag. I'm generally hesitating to review remaining ones, because the general architecture will be quite different after changing things mentioned above. However let me see and try to point issues I can find. Best regards, Tomasz
diff --git a/arch/arm/Kconfig b/arch/arm/Kconfig index 732a134..a4eac2f 100644 --- a/arch/arm/Kconfig +++ b/arch/arm/Kconfig @@ -855,6 +855,7 @@ config ARCH_EXYNOS select SPARSE_IRQ select SRAM select USE_OF + select MFD_SYSCON help Support for SAMSUNG's EXYNOS SoCs (EXYNOS4/5) diff --git a/arch/arm/mach-exynos/common.h b/arch/arm/mach-exynos/common.h index 69739e4..d533e2d 100644 --- a/arch/arm/mach-exynos/common.h +++ b/arch/arm/mach-exynos/common.h @@ -57,4 +57,6 @@ struct exynos_pmu_conf { extern void exynos_sys_powerdown_conf(enum sys_powerdown mode); extern void exynos_enter_aftr(void); +extern struct regmap *get_exynos_pmuregmap(void); + #endif /* __ARCH_ARM_MACH_EXYNOS_COMMON_H */ diff --git a/arch/arm/mach-exynos/exynos.c b/arch/arm/mach-exynos/exynos.c index e4a4be0..3b1d245 100644 --- a/arch/arm/mach-exynos/exynos.c +++ b/arch/arm/mach-exynos/exynos.c @@ -19,6 +19,7 @@ #include <linux/of_platform.h> #include <linux/platform_device.h> #include <linux/pm_domain.h> +#include <linux/mfd/syscon.h> #include <asm/cacheflush.h> #include <asm/hardware/cache-l2x0.h> @@ -36,6 +37,8 @@ #define L2_AUX_VAL 0x7C470001 #define L2_AUX_MASK 0xC200ffff +static struct regmap *exynos_pmu_regmap; + static struct map_desc exynos4_iodesc[] __initdata = { { .virtual = (unsigned long)S3C_VA_SYS, @@ -210,6 +213,14 @@ static int __init exynos_fdt_map_chipid(unsigned long node, const char *uname, return 1; } +static const struct of_device_id exynos_dt_pmu_match[] = { + { .compatible = "samsung,exynos4210-pmu" }, + { .compatible = "samsung,exynos4212-pmu" }, + { .compatible = "samsung,exynos4412-pmu" }, + { .compatible = "samsung,exynos5250-pmu" }, + {}, +}; + /* * exynos_map_io * @@ -263,6 +274,32 @@ static int __init exynos4_l2x0_cache_init(void) } early_initcall(exynos4_l2x0_cache_init); + +struct regmap *get_exynos_pmuregmap() +{ + return exynos_pmu_regmap; +} + +void __init exynos_map_pmu(void) +{ + struct device_node *np = NULL; + + early_syscon_init(); + + np = of_find_matching_node(NULL, exynos_dt_pmu_match); + + if (!np) { + pr_err("Failed to find PMU node\n"); + return; + } else { + exynos_pmu_regmap = syscon_early_regmap_lookup_by_phandle(np, + NULL); + } + + if (IS_ERR(exynos_pmu_regmap)) + pr_err("failed to find exynos_pmu_regmap\n"); +} + static void __init exynos_dt_machine_init(void) { struct device_node *i2c_np; @@ -291,6 +328,8 @@ static void __init exynos_dt_machine_init(void) } } + exynos_map_pmu(); + if (!soc_is_exynos5440()) platform_device_register(&exynos_cpuidle);