Re: [RFC PATCH 03/11] arm:omap:am33xx: Add power domain data
[..] diff --git a/arch/arm/mach-omap2/prm-regbits-33xx.h b/arch/arm/mach-omap2/prm-regbits-33xx.h new file mode 100644 index 000..5299287 --- /dev/null +++ b/arch/arm/mach-omap2/prm-regbits-33xx.h @@ -0,0 +1,357 @@ +/* + * AM33XX Power Management register bits + * + * Copyright (C) 2011 Texas Instruments Incorporated - http://www.ti.com/ + * + * This program is free software; you can redistribute it and/or + * modify it under the terms of the GNU General Public License as + * published by the Free Software Foundation version 2. + * + * This program is distributed as is WITHOUT ANY WARRANTY of any + * kind, whether express or implied; without even the implied warranty + * of MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the + * GNU General Public License for more details. + */ + + +#ifndef __ARCH_ARM_MACH_OMAP2_PRM_REGBITS_33XX_H +#define __ARCH_ARM_MACH_OMAP2_PRM_REGBITS_33XX_H + +#include prm.h + +/* Used by PRM_LDO_SRAM_CORE_SETUP, PRM_LDO_SRAM_MPU_SETUP */ +#define AM33XX_ABBOFF_ACT_EXPORT_SHIFT 1 +#define AM33XX_ABBOFF_ACT_EXPORT_MASK BITFIELD(1, 1) This seems like an output from an old autogen script. The BITFIELD macro does not exist anymore. -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC PATCH 03/11] arm:omap:am33xx: Add power domain data
Rajendra Nayak rna...@ti.com writes: [..] First some general comments: At first glance, it seems like there could be much more reuse with OMAP4 code here. From what I see, AM33x has only one partition compared to several on OMAP4, but that doesn't mean you couldn't reuse the OMAP4 functions and just use a single partition. Kevin, Indeed it looks close to OMAP4, but it becomes difficult and ugly once you Start getting into implementation details, for example, - All PRM offsets don't match, you will end up with cpu_is_xxx check and handle this. Applicable to all power domains. OMAP4430_PRM_MPU_INST 0x0300 Vs AM33XX_PRM_MPU_MOD 0x0E00 OMAP4430_PRM_WKUP_INST 0x1700 Vs AM33XX_PRM_WKUP_MOD 0x0D00 The above prcm offsets being different on am33xx doesn't really seem to be the issue since its already part of the powerdomain struct. See how omap2 and omap3 have different offsets and still end up using common code. You won't need any cpu_is_* checks for those. The real problem however seems to be with the completely different PWSTCTRL and PWSTST offsets. They seem to be so messed up that they are not even consistent across all powerdomains in the same SoC. The only solution I could think of to handle these was if we had a provision to specify the offsets on a per powerdomain level by adding them to the powerdomain struct. It could be populated only on SoC's which have these weirdly different offsets and for the rest it could just get initialized with fixed values for all powerdomains at init. Kevin/Paul/Benoit any thoughts? Something tells me that AM33x is not the last device we're going to see where there clearly wansn't a unified design around PRCM integration. So I suspect adding this to the powerdomain struct is the best way to go, but Paul/Benoit should make the final call. Kevin -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: [RFC PATCH 03/11] arm:omap:am33xx: Add power domain data
On Thu, Dec 01, 2011 at 06:34:19, Hilman, Kevin wrote: Vaibhav Hiremath hvaib...@ti.com writes: From: Afzal Mohammed af...@ti.com This patch adds AM33XX power domain data, corresponding API's to access PRM module and PRM register offsets bit fields. Signed-off-by: Rachna Patil rac...@ti.com Signed-off-by: Vaibhav Hiremath hvaib...@ti.com Signed-off-by: Afzal Mohammed af...@ti.com First some general comments: At first glance, it seems like there could be much more reuse with OMAP4 code here. From what I see, AM33x has only one partition compared to several on OMAP4, but that doesn't mean you couldn't reuse the OMAP4 functions and just use a single partition. IOW, it seems to me that all the pwrdm_ops could be shared with OMAP4. From what I read (after an admittedly quick glance), the main thing you need is a way to override the PRM offsets due to the fact that some crazy person decided to make each instance different. If its any consolation, this has been fed back to the chip designers and is expected to be corrected for the next AM335x derivative. Thanks, Sekhar -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC PATCH 03/11] arm:omap:am33xx: Add power domain data
Nori, Sekhar nsek...@ti.com writes: On Thu, Dec 01, 2011 at 06:34:19, Hilman, Kevin wrote: Vaibhav Hiremath hvaib...@ti.com writes: From: Afzal Mohammed af...@ti.com This patch adds AM33XX power domain data, corresponding API's to access PRM module and PRM register offsets bit fields. Signed-off-by: Rachna Patil rac...@ti.com Signed-off-by: Vaibhav Hiremath hvaib...@ti.com Signed-off-by: Afzal Mohammed af...@ti.com First some general comments: At first glance, it seems like there could be much more reuse with OMAP4 code here. From what I see, AM33x has only one partition compared to several on OMAP4, but that doesn't mean you couldn't reuse the OMAP4 functions and just use a single partition. IOW, it seems to me that all the pwrdm_ops could be shared with OMAP4. From what I read (after an admittedly quick glance), the main thing you need is a way to override the PRM offsets due to the fact that some crazy person decided to make each instance different. If its any consolation, this has been fed back to the chip designers and is expected to be corrected for the next AM335x derivative. Great, Thanks! Assuming mainline kernel support is a priority for the other SoCs in this family, keeping SW compatibility with other existing SoCs in the OMAP family should be a high priority. This is especially true when large portions of the IP are reused from existing SoCs, as is clearly the case in AM33x. Kevin -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: [RFC PATCH 03/11] arm:omap:am33xx: Add power domain data
-Original Message- From: Hilman, Kevin Sent: Thursday, December 01, 2011 6:34 AM To: Hiremath, Vaibhav Cc: linux-omap@vger.kernel.org; t...@atomide.com; p...@pwsan.com; linux- arm-ker...@lists.infradead.org; Cousson, Benoit; Mohammed, Afzal; Patil, Rachna Subject: Re: [RFC PATCH 03/11] arm:omap:am33xx: Add power domain data Vaibhav Hiremath hvaib...@ti.com writes: From: Afzal Mohammed af...@ti.com This patch adds AM33XX power domain data, corresponding API's to access PRM module and PRM register offsets bit fields. Signed-off-by: Rachna Patil rac...@ti.com Signed-off-by: Vaibhav Hiremath hvaib...@ti.com Signed-off-by: Afzal Mohammed af...@ti.com First some general comments: At first glance, it seems like there could be much more reuse with OMAP4 code here. From what I see, AM33x has only one partition compared to several on OMAP4, but that doesn't mean you couldn't reuse the OMAP4 functions and just use a single partition. Kevin, Indeed it looks close to OMAP4, but it becomes difficult and ugly once you Start getting into implementation details, for example, - All PRM offsets don't match, you will end up with cpu_is_xxx check and handle this. Applicable to all power domains. OMAP4430_PRM_MPU_INST 0x0300 Vs AM33XX_PRM_MPU_MOD 0x0E00 OMAP4430_PRM_WKUP_INST 0x1700 Vs AM33XX_PRM_WKUP_MOD 0x0D00 - Also there are some differences in logic states of domains as well. Another important point is, we have considered AM33xx as OMAP3 family of device (ARCH_OMAP3). So you may end up with number of cpu_is_xxx checks in code. IOW, it seems to me that all the pwrdm_ops could be shared with OMAP4. From what I read (after an admittedly quick glance), the main thing you need is a way to override the PRM offsets due to the fact that some crazy person decided to make each instance different. This was one of the major reason why I had chosen and implemented separately for AM33xx. If you modified the OMAP4 base so that the _prminst_read_inst_reg() could be customized, wouldn't that work for AM33xx? --- arch/arm/mach-omap2/powerdomain.h |4 +- arch/arm/mach-omap2/powerdomain33xx.c | 155 arch/arm/mach-omap2/powerdomains33xx_data.c | 115 + arch/arm/mach-omap2/prm-regbits-33xx.h | 357 +++ arch/arm/mach-omap2/prm33xx.h | 123 + arch/arm/mach-omap2/prminst33xx.c | 74 ++ arch/arm/mach-omap2/prminst33xx.h | 25 ++ 7 files changed, 852 insertions(+), 1 deletions(-) create mode 100644 arch/arm/mach-omap2/powerdomain33xx.c create mode 100644 arch/arm/mach-omap2/powerdomains33xx_data.c create mode 100644 arch/arm/mach-omap2/prm-regbits-33xx.h create mode 100644 arch/arm/mach-omap2/prm33xx.h create mode 100644 arch/arm/mach-omap2/prminst33xx.c create mode 100644 arch/arm/mach-omap2/prminst33xx.h diff --git a/arch/arm/mach-omap2/powerdomain.h b/arch/arm/mach- omap2/powerdomain.h index 0d72a8a..9efa823 100644 --- a/arch/arm/mach-omap2/powerdomain.h +++ b/arch/arm/mach-omap2/powerdomain.h @@ -69,7 +69,7 @@ * Maximum number of clockdomains that can be associated with a powerdomain. * CORE powerdomain on OMAP4 is the worst case */ -#define PWRDM_MAX_CLKDMS 9 +#define PWRDM_MAX_CLKDMS 11 Comment before this needs update as well. Ok. /* XXX A completely arbitrary number. What is reasonable here? */ #define PWRDM_TRANSITION_BAILOUT 10 @@ -223,10 +223,12 @@ bool pwrdm_can_ever_lose_context(struct powerdomain *pwrdm); extern void omap242x_powerdomains_init(void); extern void omap243x_powerdomains_init(void); extern void omap3xxx_powerdomains_init(void); +extern void am33xx_powerdomains_init(void); extern void omap44xx_powerdomains_init(void); extern struct pwrdm_ops omap2_pwrdm_operations; extern struct pwrdm_ops omap3_pwrdm_operations; +extern struct pwrdm_ops am33xx_pwrdm_operations; extern struct pwrdm_ops omap4_pwrdm_operations; /* Common Internal functions used across OMAP rev's */ [...] diff --git a/arch/arm/mach-omap2/prm33xx.h b/arch/arm/mach- omap2/prm33xx.h new file mode 100644 index 000..0fd5c6e --- /dev/null +++ b/arch/arm/mach-omap2/prm33xx.h @@ -0,0 +1,123 @@ +/* + * AM33XX PRM instance offset macros + * + * Copyright (C) 2011 Texas Instruments Incorporated - http://www.ti.com/ + * + * This program is free software; you can redistribute it and/or + * modify it under the terms of the GNU General Public License as + * published by the Free Software Foundation version 2. + * + * This program is distributed as is WITHOUT ANY WARRANTY of any + * kind, whether express or implied; without even the implied warranty + * of MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See
Re: [RFC PATCH 03/11] arm:omap:am33xx: Add power domain data
Hiremath, Vaibhav hvaib...@ti.com writes: -Original Message- From: Hilman, Kevin Sent: Thursday, December 01, 2011 6:34 AM To: Hiremath, Vaibhav Cc: linux-omap@vger.kernel.org; t...@atomide.com; p...@pwsan.com; linux- arm-ker...@lists.infradead.org; Cousson, Benoit; Mohammed, Afzal; Patil, Rachna Subject: Re: [RFC PATCH 03/11] arm:omap:am33xx: Add power domain data Vaibhav Hiremath hvaib...@ti.com writes: From: Afzal Mohammed af...@ti.com This patch adds AM33XX power domain data, corresponding API's to access PRM module and PRM register offsets bit fields. Signed-off-by: Rachna Patil rac...@ti.com Signed-off-by: Vaibhav Hiremath hvaib...@ti.com Signed-off-by: Afzal Mohammed af...@ti.com First some general comments: At first glance, it seems like there could be much more reuse with OMAP4 code here. From what I see, AM33x has only one partition compared to several on OMAP4, but that doesn't mean you couldn't reuse the OMAP4 functions and just use a single partition. Kevin, Indeed it looks close to OMAP4, but it becomes difficult and ugly once you Start getting into implementation details, for example, - All PRM offsets don't match, you will end up with cpu_is_xxx check and handle this. Applicable to all power domains. OMAP4430_PRM_MPU_INST 0x0300 Vs AM33XX_PRM_MPU_MOD 0x0E00 OMAP4430_PRM_WKUP_INST 0x1700 Vs AM33XX_PRM_WKUP_MOD 0x0D00 - Also there are some differences in logic states of domains as well. Another important point is, we have considered AM33xx as OMAP3 family of device (ARCH_OMAP3). So you may end up with number of cpu_is_xxx checks in code. If we end up with cpu_is_* checks in the code, we're doing it wrong. I understand there are lots of differences with OMAP4, but from what I'm looking at (at least for the power domains in this patch) there most of those differences are handled in the data files, and the code could be shared. For example, looking at powerdomain33xx.c, this looks exactly like the OMAP4 version except - you have 2 new AM33XX_PRM_* defines (which are the same as OMAP4 version) - you have a new register access functions: am33xx_prminst_read_inst_reg()... So, my question is: if you could update the OMAP4 code to be able to override the register access read/write functions, would you even need a new powerdomain33xx.c? Your am33xx_ version doesn't take a partition argument, but that would be easy to remedy, and the AM33x powerdomains could be updated to all declare a default partition. Anyways, I'll let Benoit/Paul/Rajendra take it from here, as they're the ones who know this code the best. Kevin -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC PATCH 03/11] arm:omap:am33xx: Add power domain data
[..] First some general comments: At first glance, it seems like there could be much more reuse with OMAP4 code here. From what I see, AM33x has only one partition compared to several on OMAP4, but that doesn't mean you couldn't reuse the OMAP4 functions and just use a single partition. Kevin, Indeed it looks close to OMAP4, but it becomes difficult and ugly once you Start getting into implementation details, for example, - All PRM offsets don't match, you will end up with cpu_is_xxx check and handle this. Applicable to all power domains. OMAP4430_PRM_MPU_INST 0x0300 Vs AM33XX_PRM_MPU_MOD 0x0E00 OMAP4430_PRM_WKUP_INST 0x1700 Vs AM33XX_PRM_WKUP_MOD 0x0D00 The above prcm offsets being different on am33xx doesn't really seem to be the issue since its already part of the powerdomain struct. See how omap2 and omap3 have different offsets and still end up using common code. You won't need any cpu_is_* checks for those. The real problem however seems to be with the completely different PWSTCTRL and PWSTST offsets. They seem to be so messed up that they are not even consistent across all powerdomains in the same SoC. The only solution I could think of to handle these was if we had a provision to specify the offsets on a per powerdomain level by adding them to the powerdomain struct. It could be populated only on SoC's which have these weirdly different offsets and for the rest it could just get initialized with fixed values for all powerdomains at init. Kevin/Paul/Benoit any thoughts? - Also there are some differences in logic states of domains as well. Another important point is, we have considered AM33xx as OMAP3 family of device (ARCH_OMAP3). So you may end up with number of cpu_is_xxx checks in code. IOW, it seems to me that all the pwrdm_ops could be shared with OMAP4. From what I read (after an admittedly quick glance), the main thing you need is a way to override the PRM offsets due to the fact that some crazy person decided to make each instance different. This was one of the major reason why I had chosen and implemented separately for AM33xx. -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC PATCH 03/11] arm:omap:am33xx: Add power domain data
Vaibhav Hiremath hvaib...@ti.com writes: From: Afzal Mohammed af...@ti.com This patch adds AM33XX power domain data, corresponding API's to access PRM module and PRM register offsets bit fields. Signed-off-by: Rachna Patil rac...@ti.com Signed-off-by: Vaibhav Hiremath hvaib...@ti.com Signed-off-by: Afzal Mohammed af...@ti.com First some general comments: At first glance, it seems like there could be much more reuse with OMAP4 code here. From what I see, AM33x has only one partition compared to several on OMAP4, but that doesn't mean you couldn't reuse the OMAP4 functions and just use a single partition. IOW, it seems to me that all the pwrdm_ops could be shared with OMAP4. From what I read (after an admittedly quick glance), the main thing you need is a way to override the PRM offsets due to the fact that some crazy person decided to make each instance different. If you modified the OMAP4 base so that the _prminst_read_inst_reg() could be customized, wouldn't that work for AM33xx? --- arch/arm/mach-omap2/powerdomain.h |4 +- arch/arm/mach-omap2/powerdomain33xx.c | 155 arch/arm/mach-omap2/powerdomains33xx_data.c | 115 + arch/arm/mach-omap2/prm-regbits-33xx.h | 357 +++ arch/arm/mach-omap2/prm33xx.h | 123 + arch/arm/mach-omap2/prminst33xx.c | 74 ++ arch/arm/mach-omap2/prminst33xx.h | 25 ++ 7 files changed, 852 insertions(+), 1 deletions(-) create mode 100644 arch/arm/mach-omap2/powerdomain33xx.c create mode 100644 arch/arm/mach-omap2/powerdomains33xx_data.c create mode 100644 arch/arm/mach-omap2/prm-regbits-33xx.h create mode 100644 arch/arm/mach-omap2/prm33xx.h create mode 100644 arch/arm/mach-omap2/prminst33xx.c create mode 100644 arch/arm/mach-omap2/prminst33xx.h diff --git a/arch/arm/mach-omap2/powerdomain.h b/arch/arm/mach-omap2/powerdomain.h index 0d72a8a..9efa823 100644 --- a/arch/arm/mach-omap2/powerdomain.h +++ b/arch/arm/mach-omap2/powerdomain.h @@ -69,7 +69,7 @@ * Maximum number of clockdomains that can be associated with a powerdomain. * CORE powerdomain on OMAP4 is the worst case */ -#define PWRDM_MAX_CLKDMS 9 +#define PWRDM_MAX_CLKDMS 11 Comment before this needs update as well. /* XXX A completely arbitrary number. What is reasonable here? */ #define PWRDM_TRANSITION_BAILOUT 10 @@ -223,10 +223,12 @@ bool pwrdm_can_ever_lose_context(struct powerdomain *pwrdm); extern void omap242x_powerdomains_init(void); extern void omap243x_powerdomains_init(void); extern void omap3xxx_powerdomains_init(void); +extern void am33xx_powerdomains_init(void); extern void omap44xx_powerdomains_init(void); extern struct pwrdm_ops omap2_pwrdm_operations; extern struct pwrdm_ops omap3_pwrdm_operations; +extern struct pwrdm_ops am33xx_pwrdm_operations; extern struct pwrdm_ops omap4_pwrdm_operations; /* Common Internal functions used across OMAP rev's */ [...] diff --git a/arch/arm/mach-omap2/prm33xx.h b/arch/arm/mach-omap2/prm33xx.h new file mode 100644 index 000..0fd5c6e --- /dev/null +++ b/arch/arm/mach-omap2/prm33xx.h @@ -0,0 +1,123 @@ +/* + * AM33XX PRM instance offset macros + * + * Copyright (C) 2011 Texas Instruments Incorporated - http://www.ti.com/ + * + * This program is free software; you can redistribute it and/or + * modify it under the terms of the GNU General Public License as + * published by the Free Software Foundation version 2. + * + * This program is distributed as is WITHOUT ANY WARRANTY of any + * kind, whether express or implied; without even the implied warranty + * of MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the + * GNU General Public License for more details. + */ + +#ifndef __ARCH_ARM_MACH_OMAP2_PRM33XX_H +#define __ARCH_ARM_MACH_OMAP2_PRM33XX_H + +#include prcm-common.h +#include prm.h + +#define AM33XX_PRM_BASE 0x44E0 + +#define AM33XX_PRM_REGADDR(inst, reg) \ + AM33XX_L4_WK_IO_ADDRESS(AM33XX_PRM_BASE + (inst) + (reg)) + + +/* PRM instances */ +#define AM33XX_PRM_OCP_SOCKET_MOD0x0B00 +#define AM33XX_PRM_PER_MOD 0x0C00 +#define AM33XX_PRM_WKUP_MOD 0x0D00 +#define AM33XX_PRM_MPU_MOD 0x0E00 +#define AM33XX_PRM_DEVICE_MOD0x0F00 +#define AM33XX_PRM_RTC_MOD 0x1000 +#define AM33XX_PRM_GFX_MOD 0x1100 +#define AM33XX_PRM_CEFUSE_MOD0x1200 + +/* Register offsets (used from OMAP4) */ Probably could just include prm44xx.h and use OMAP4_PM_... instead. +#define AM33XX_PM_PWSTCTRL 0x +#define AM33XX_PM_PWSTST 0x0004 However, since thes are just dummy offsets into a fixup table anyways, maybe it's best to use use 0 and 1 here and have a comment here to that effect. Otherwise, it's a bit confusing since one would assume these are actual register
