Re: [PATCH 02/13] ARM: OMAP5: Add minimal support for OMAP5430 SOC
Tony, [snip] So after the cleanup patch introducing CONFIG_SOC_OMAP4PLUS it can be changed as #ifdef (CONFIG_SOC_OMAP4PLUS) !(defined(CONFIG_ARCH_OMAP2) || defined(CONFIG_ARCH_OMAP3)) So this will avoid patching this for the future socs. ? Well it seems that we've come to a conclusion that if we introduce new config options, they should be based on features instead. So CONFIG_SOC_HAS_OMAPXYZ_BLAH rather than CONFIG_SOC_OMAP4PLUS. Sure thanks for clarifying. Then i will introduce a relevant config in my cleanup patch first and then add OMAP5. Thanks, Sricharan -- 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: [PATCH 02/13] ARM: OMAP5: Add minimal support for OMAP5430 SOC
Hi, On 05/03/2012 10:26 AM, R Sricharan wrote: OMAP5430 is Texas Instrument's SOC based on ARM Cortex-A15 SMP architecture. It's a dual core SOC with GIC used for interrupt handling and with an integrated L2 cache controller. OMAP5432 is another variant of OMAP5430, with a memory controller supporting DDR3 and SATA. Patch includes: - The machine specific headers and sources updates. - Platform header updates. - Minimum initialisation support for serial. - IO table init Signed-off-by: R Sricharan r.sricha...@ti.com Signed-off-by: Santosh Shilimkar santosh.shilim...@ti.com --- arch/arm/mach-omap2/Makefile | 26 ++ arch/arm/mach-omap2/clock.c|3 +- arch/arm/mach-omap2/cminst44xx.h |2 +- arch/arm/mach-omap2/common.c | 24 + arch/arm/mach-omap2/common.h | 11 ++ arch/arm/mach-omap2/include/mach/debug-macro.S |8 ++-- arch/arm/mach-omap2/io.c | 44 arch/arm/mach-omap2/iomap.h| 27 ++ arch/arm/mach-omap2/prcm.c |2 +- arch/arm/mach-omap2/prm2xxx_3xxx.h |5 ++- arch/arm/plat-omap/Makefile|4 +-- arch/arm/plat-omap/include/plat/clkdev_omap.h |1 + arch/arm/plat-omap/include/plat/clock.h|4 ++- arch/arm/plat-omap/include/plat/hardware.h |1 + arch/arm/plat-omap/include/plat/multi.h|9 + arch/arm/plat-omap/include/plat/omap54xx.h | 32 + arch/arm/plat-omap/include/plat/serial.h | 10 + arch/arm/plat-omap/include/plat/uncompress.h |6 +++ arch/arm/plat-omap/sram.c | 11 +- 19 files changed, 208 insertions(+), 22 deletions(-) create mode 100644 arch/arm/plat-omap/include/plat/omap54xx.h diff --git a/arch/arm/mach-omap2/Makefile b/arch/arm/mach-omap2/Makefile index 669e2b1..fbb6b3d 100644 --- a/arch/arm/mach-omap2/Makefile +++ b/arch/arm/mach-omap2/Makefile @@ -16,6 +16,7 @@ secure-common = omap-smc.o omap-secure.o obj-$(CONFIG_ARCH_OMAP2) += $(omap-2-3-common) $(hwmod-common) obj-$(CONFIG_ARCH_OMAP3) += $(omap-2-3-common) $(hwmod-common) $(secure-common) obj-$(CONFIG_ARCH_OMAP4) += prm44xx.o $(hwmod-common) $(secure-common) +obj-$(CONFIG_ARCH_OMAP5) += prm44xx.o $(hwmod-common) $(secure-common) ifneq ($(CONFIG_SND_OMAP_SOC_MCBSP),) obj-y += mcbsp.o @@ -27,8 +28,10 @@ obj-$(CONFIG_TWL4030_CORE) += omap_twl.o obj-$(CONFIG_SMP)+= omap-smp.o omap-headsmp.o obj-$(CONFIG_HOTPLUG_CPU)+= omap-hotplug.o -obj-$(CONFIG_ARCH_OMAP4) += omap4-common.o omap-wakeupgen.o -obj-$(CONFIG_ARCH_OMAP4) += sleep44xx.o +omap-4-5-common = omap4-common.o omap-wakeupgen.o \ +sleep44xx.o +obj-$(CONFIG_ARCH_OMAP4) += $(omap-4-5-common) +obj-$(CONFIG_ARCH_OMAP5)+= $(omap-4-5-common) plus_sec := $(call as-instr,.arch_extension sec,+sec) AFLAGS_omap-headsmp.o:=-Wa,-march=armv7-a$(plus_sec) @@ -68,6 +71,7 @@ obj-$(CONFIG_ARCH_OMAP2)+= sleep24xx.o obj-$(CONFIG_ARCH_OMAP3) += pm34xx.o sleep34xx.o obj-$(CONFIG_ARCH_OMAP3) += cpuidle34xx.o obj-$(CONFIG_ARCH_OMAP4) += pm44xx.o omap-mpuss-lowpower.o +obj-$(CONFIG_ARCH_OMAP5) += omap-mpuss-lowpower.o obj-$(CONFIG_ARCH_OMAP4) += cpuidle44xx.o obj-$(CONFIG_PM_DEBUG) += pm-debug.o obj-$(CONFIG_OMAP_SMARTREFLEX) += sr_device.o smartreflex.o @@ -87,9 +91,11 @@ obj-y += prm_common.o obj-$(CONFIG_ARCH_OMAP2) += prcm.o cm2xxx_3xxx.o prm2xxx_3xxx.o obj-$(CONFIG_ARCH_OMAP3) += prcm.o cm2xxx_3xxx.o prm2xxx_3xxx.o obj-$(CONFIG_ARCH_OMAP3) += vc3xxx_data.o vp3xxx_data.o -obj-$(CONFIG_ARCH_OMAP4) += prcm.o cminst44xx.o cm44xx.o -obj-$(CONFIG_ARCH_OMAP4) += prcm_mpu44xx.o prminst44xx.o -obj-$(CONFIG_ARCH_OMAP4) += vc44xx_data.o vp44xx_data.o prm44xx.o +omap-prcm-4-5-common = prcm.o cminst44xx.o cm44xx.o \ +prcm_mpu44xx.o prminst44xx.o \ +vc44xx_data.o vp44xx_data.o +obj-$(CONFIG_ARCH_OMAP4) += $(omap-prcm-4-5-common) prm44xx.o +obj-$(CONFIG_ARCH_OMAP5)+= $(omap-prcm-4-5-common) # OMAP voltage domains voltagedomain-common := voltage.o vc.o vp.o @@ -99,6 +105,7 @@ obj-$(CONFIG_ARCH_OMAP3) += $(voltagedomain-common) obj-$(CONFIG_ARCH_OMAP3) += voltagedomains3xxx_data.o obj-$(CONFIG_ARCH_OMAP4) +=
Re: [PATCH 02/13] ARM: OMAP5: Add minimal support for OMAP5430 SOC
Tony,
[snip]
-#if defined(CONFIG_ARCH_OMAP4) !(defined(CONFIG_ARCH_OMAP2) || \
- defined(CONFIG_ARCH_OMAP3))
+#if (defined(CONFIG_ARCH_OMAP5) || defined(CONFIG_ARCH_OMAP4)) \
+ !(defined(CONFIG_ARCH_OMAP2) || defined(CONFIG_ARCH_OMAP3))
+
static inline u32 omap2_prm_read_mod_reg(s16 module, u16 idx)
{
WARN(1, prm: omap2xxx/omap3xxx specific function and
Maybe these functions could be just set up as __weak to avoid the
ifdeffery?
sorry to understand,
you mean make this weak and have a strong override for OMAP2 ?
Yeah that should do the trick, right?
Ok, There are multiple functions under that #ifdef.
Also i see that __weak cannot be used for inline functions.
So should those functions should be moved to .c file and qualify them
__weak. There is already a strong override for OMAP2 and 3 which
should not be a problem.
[OR]
So after the cleanup patch introducing CONFIG_SOC_OMAP4PLUS
it can be changed as
#ifdef (CONFIG_SOC_OMAP4PLUS) !(defined(CONFIG_ARCH_OMAP2) ||
defined(CONFIG_ARCH_OMAP3))
So this will avoid patching this for the future socs. ?
Thanks,
Sricharan
--
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: [PATCH 02/13] ARM: OMAP5: Add minimal support for OMAP5430 SOC
* R, Sricharan r.sricha...@ti.com [120509 02:09]:
Tony,
[snip]
-#if defined(CONFIG_ARCH_OMAP4) !(defined(CONFIG_ARCH_OMAP2) || \
- defined(CONFIG_ARCH_OMAP3))
+#if (defined(CONFIG_ARCH_OMAP5) || defined(CONFIG_ARCH_OMAP4)) \
+ !(defined(CONFIG_ARCH_OMAP2) ||
defined(CONFIG_ARCH_OMAP3))
+
static inline u32 omap2_prm_read_mod_reg(s16 module, u16 idx)
{
WARN(1, prm: omap2xxx/omap3xxx specific function and
Maybe these functions could be just set up as __weak to avoid the
ifdeffery?
sorry to understand,
you mean make this weak and have a strong override for OMAP2 ?
Yeah that should do the trick, right?
Ok, There are multiple functions under that #ifdef.
Also i see that __weak cannot be used for inline functions.
So should those functions should be moved to .c file and qualify them
__weak. There is already a strong override for OMAP2 and 3 which
should not be a problem.
Yes that's worth experimenting with to set up things in a way where
we don't need to add new ifdefs to add a new SoC.
[OR]
So after the cleanup patch introducing CONFIG_SOC_OMAP4PLUS
it can be changed as
#ifdef (CONFIG_SOC_OMAP4PLUS) !(defined(CONFIG_ARCH_OMAP2) ||
defined(CONFIG_ARCH_OMAP3))
So this will avoid patching this for the future socs. ?
Well it seems that we've come to a conclusion that if we introduce
new config options, they should be based on features instead. So
CONFIG_SOC_HAS_OMAPXYZ_BLAH rather than CONFIG_SOC_OMAP4PLUS.
Regards,
Tony
--
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: [PATCH 02/13] ARM: OMAP5: Add minimal support for OMAP5430 SOC
* Paul Walmsley p...@pwsan.com [120507 22:35]: On Mon, 7 May 2012, Tony Lindgren wrote: http://www.mail-archive.com/linux-omap@vger.kernel.org/msg67938.html I see. Yeah, the problem is that it's hard to figure out which SoCs should go into SOC_OMAP3PLUS. AM33xx? TI81xx? etc. Some of these chips draw some aspects from chips that we've historically considered part of OMAP3, and other aspects from OMAP4-style chips. Yes agreed it should be finer grained and feature specific. What seems better to me would be to use a more specific, IP block-focused macro as needed. So to pick a random example, in mach-omap2/control.c, we currently skip compilation of the scratchpad functions unless CONFIG_ARCH_OMAP3 is defined. Instead of making this SOC_OMAP3PLUS-dependent, or dependent on a mess of CONFIG_SOC_* macros, maybe something like CONFIG_OMAP3430_SCM_SCRATCHPAD_FORMAT? Yes that makes sense. How about let's standardize on naming like SOC_HAS_OMAP3430_SCM_SCRATCHPAD_FORMAT? We already have similar naming for generic things like ARCH_HAS_XYZ. Of course, for some of these cases, maybe it makes more sense to move the code out into a separate file, control-omap3-scratchpad.c or something, and just conditionally compile it to avoid the #ifdefs. Agreed. Regards, Tony -- 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: [PATCH 02/13] ARM: OMAP5: Add minimal support for OMAP5430 SOC
* Hiremath, Vaibhav hvaib...@ti.com [120507 22:52]: On Tue, May 08, 2012 at 01:05:01, Tony Lindgren wrote: * Tony Lindgren t...@atomide.com [120507 12:22]: * Paul Walmsley p...@pwsan.com [120507 12:11]: Hi, On Fri, 4 May 2012, Tony Lindgren wrote: How about we add CONFIG_SOC_OMAP3PLUS in the clean-up series? Then this becomes just: #ifdef CONFIG_SOC_OMAP3PLUS We might want to consider having separate CONFIG_SOC_* values for each SoC. So rather than CONFIG_SOC_OMAP3PLUS, we'd have CONFIG_SOC_OMAP3430, CONFIG_SOC_OMAP3630, etc. Hmm but this would be in addition to the SOC specific options. The goal is to cut down the ifdeffery needed all over the place to add new SoCs, see the experimental patch I posted: http://www.mail-archive.com/linux-omap@vger.kernel.org/msg67938.html Of course we could make this finer grained based on features like SOC_HAS_XYZ or SOC_HAS_OMAP3PLUS_PRMXYZBITS if you have some grouping like that in mind. This is much better approach than both ARCH_OMAPx and SOC_OMAP. OK good, so now the question is just what groupings we need.. Got any suggestions? Regards, Tony -- 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: [PATCH 02/13] ARM: OMAP5: Add minimal support for OMAP5430 SOC
On Tue, May 08, 2012 at 21:18:29, Tony Lindgren wrote: * Hiremath, Vaibhav hvaib...@ti.com [120507 22:52]: On Tue, May 08, 2012 at 01:05:01, Tony Lindgren wrote: * Tony Lindgren t...@atomide.com [120507 12:22]: * Paul Walmsley p...@pwsan.com [120507 12:11]: Hi, On Fri, 4 May 2012, Tony Lindgren wrote: How about we add CONFIG_SOC_OMAP3PLUS in the clean-up series? Then this becomes just: #ifdef CONFIG_SOC_OMAP3PLUS We might want to consider having separate CONFIG_SOC_* values for each SoC. So rather than CONFIG_SOC_OMAP3PLUS, we'd have CONFIG_SOC_OMAP3430, CONFIG_SOC_OMAP3630, etc. Hmm but this would be in addition to the SOC specific options. The goal is to cut down the ifdeffery needed all over the place to add new SoCs, see the experimental patch I posted: http://www.mail-archive.com/linux-omap@vger.kernel.org/msg67938.html Of course we could make this finer grained based on features like SOC_HAS_XYZ or SOC_HAS_OMAP3PLUS_PRMXYZBITS if you have some grouping like that in mind. This is much better approach than both ARCH_OMAPx and SOC_OMAP. OK good, so now the question is just what groupings we need.. Got any suggestions? Tony I have submitted first round of cleanup patches in the same direction, can you please take a look at them? Most of them are trivial and should be considered for upstream. I am trying to take cleanup thing one-by-one, and keep submitting them. Please let me know if you have any suggestions or pointers for me. Thanks, Vaibhav -- 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: [PATCH 02/13] ARM: OMAP5: Add minimal support for OMAP5430 SOC
* Hiremath, Vaibhav hvaib...@ti.com [120508 10:04]: On Tue, May 08, 2012 at 21:18:29, Tony Lindgren wrote: * Hiremath, Vaibhav hvaib...@ti.com [120507 22:52]: On Tue, May 08, 2012 at 01:05:01, Tony Lindgren wrote: * Tony Lindgren t...@atomide.com [120507 12:22]: * Paul Walmsley p...@pwsan.com [120507 12:11]: Hi, On Fri, 4 May 2012, Tony Lindgren wrote: How about we add CONFIG_SOC_OMAP3PLUS in the clean-up series? Then this becomes just: #ifdef CONFIG_SOC_OMAP3PLUS We might want to consider having separate CONFIG_SOC_* values for each SoC. So rather than CONFIG_SOC_OMAP3PLUS, we'd have CONFIG_SOC_OMAP3430, CONFIG_SOC_OMAP3630, etc. Hmm but this would be in addition to the SOC specific options. The goal is to cut down the ifdeffery needed all over the place to add new SoCs, see the experimental patch I posted: http://www.mail-archive.com/linux-omap@vger.kernel.org/msg67938.html Of course we could make this finer grained based on features like SOC_HAS_XYZ or SOC_HAS_OMAP3PLUS_PRMXYZBITS if you have some grouping like that in mind. This is much better approach than both ARCH_OMAPx and SOC_OMAP. OK good, so now the question is just what groupings we need.. Got any suggestions? Tony I have submitted first round of cleanup patches in the same direction, can you please take a look at them? Most of them are trivial and should be considered for upstream. I am trying to take cleanup thing one-by-one, and keep submitting them. Please let me know if you have any suggestions or pointers for me. Yes looking good thanks, made few comments there as you noticed. Tony -- 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: [PATCH 02/13] ARM: OMAP5: Add minimal support for OMAP5430 SOC
* R, Sricharan r.sricha...@ti.com [120506 00:40]:
Also, please change the whole series to use CONFIG_SOC_OMAP5 instead
of CONFIG_ARCH_OMAP5. CONFIG_ARCH_OMAP stuff will go away except
for CONFIG_ARCH_OMAP2PLUS. Sorry forgot to mention that earlier.
ok. sure. will change this.
Thanks.
-#if defined(CONFIG_ARCH_OMAP4) !(defined(CONFIG_ARCH_OMAP2) || \
- defined(CONFIG_ARCH_OMAP3))
+#if (defined(CONFIG_ARCH_OMAP5) || defined(CONFIG_ARCH_OMAP4)) \
+ !(defined(CONFIG_ARCH_OMAP2) || defined(CONFIG_ARCH_OMAP3))
+
static inline u32 omap2_prm_read_mod_reg(s16 module, u16 idx)
{
WARN(1, prm: omap2xxx/omap3xxx specific function and
Maybe these functions could be just set up as __weak to avoid the
ifdeffery?
sorry to understand,
you mean make this weak and have a strong override for OMAP2 ?
Yeah that should do the trick, right?
Regards,
Tony
--
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: [PATCH 02/13] ARM: OMAP5: Add minimal support for OMAP5430 SOC
Hi, On Fri, 4 May 2012, Tony Lindgren wrote: How about we add CONFIG_SOC_OMAP3PLUS in the clean-up series? Then this becomes just: #ifdef CONFIG_SOC_OMAP3PLUS We might want to consider having separate CONFIG_SOC_* values for each SoC. So rather than CONFIG_SOC_OMAP3PLUS, we'd have CONFIG_SOC_OMAP3430, CONFIG_SOC_OMAP3630, etc. This would be for two main reasons. One is that Kconfig options like CONFIG_SOC_OMAP3PLUS don't have much meaning. It is really unclear to me what SoCs would be included in CONFIG_SOC_OMAP3PLUS, since some of them differ so radically -- different interconnects, different power and system management IP blocks, different CPU subsystems, different RAM controllers, etc. The advantage of using SoC-specific Kconfig options, from this point of view, is that it is easy to know what they mean. Then those SoC-specific Kconfig options can select the appropriate SoC-independent interconnect driver, PRCM drivers, CPU options, etc. The other motivation would be to support device manufacturers who only wish to build a kernel for the single device that they are shipping. In terms of kernels shipped, this is probably the most popular use-case. With something like CONFIG_SOC_OMAPAM33XX, they can avoid building quite a bit of code and data (and potentially bugs) that are not needed for their specific device. - Paul -- 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: [PATCH 02/13] ARM: OMAP5: Add minimal support for OMAP5430 SOC
* Paul Walmsley p...@pwsan.com [120507 12:11]: Hi, On Fri, 4 May 2012, Tony Lindgren wrote: How about we add CONFIG_SOC_OMAP3PLUS in the clean-up series? Then this becomes just: #ifdef CONFIG_SOC_OMAP3PLUS We might want to consider having separate CONFIG_SOC_* values for each SoC. So rather than CONFIG_SOC_OMAP3PLUS, we'd have CONFIG_SOC_OMAP3430, CONFIG_SOC_OMAP3630, etc. Hmm but this would be in addition to the SOC specific options. The goal is to cut down the ifdeffery needed all over the place to add new SoCs, see the experimental patch I posted: http://www.mail-archive.com/linux-omap@vger.kernel.org/msg67938.html This would be for two main reasons. One is that Kconfig options like CONFIG_SOC_OMAP3PLUS don't have much meaning. It is really unclear to me what SoCs would be included in CONFIG_SOC_OMAP3PLUS, since some of them differ so radically -- different interconnects, different power and system management IP blocks, different CPU subsystems, different RAM controllers, etc. The advantage of using SoC-specific Kconfig options, from this point of view, is that it is easy to know what they mean. Then those SoC-specific Kconfig options can select the appropriate SoC-independent interconnect driver, PRCM drivers, CPU options, etc. Just to continue exploring just using the SoC specific options, we would currently end up with more of this kind of nastiness: #if defined(CONFIG_ARCH_OMAP4) !(defined(CONFIG_ARCH_OMAP2) || \ defined(CONFIG_ARCH_OMAP3)) The other motivation would be to support device manufacturers who only wish to build a kernel for the single device that they are shipping. In terms of kernels shipped, this is probably the most popular use-case. With something like CONFIG_SOC_OMAPAM33XX, they can avoid building quite a bit of code and data (and potentially bugs) that are not needed for their specific device. Sure, but I think you're missing the point: This would be in addition to the SoC specific options. Do you still see issues with that? Regards, Tony -- 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: [PATCH 02/13] ARM: OMAP5: Add minimal support for OMAP5430 SOC
* Tony Lindgren t...@atomide.com [120507 12:22]: * Paul Walmsley p...@pwsan.com [120507 12:11]: Hi, On Fri, 4 May 2012, Tony Lindgren wrote: How about we add CONFIG_SOC_OMAP3PLUS in the clean-up series? Then this becomes just: #ifdef CONFIG_SOC_OMAP3PLUS We might want to consider having separate CONFIG_SOC_* values for each SoC. So rather than CONFIG_SOC_OMAP3PLUS, we'd have CONFIG_SOC_OMAP3430, CONFIG_SOC_OMAP3630, etc. Hmm but this would be in addition to the SOC specific options. The goal is to cut down the ifdeffery needed all over the place to add new SoCs, see the experimental patch I posted: http://www.mail-archive.com/linux-omap@vger.kernel.org/msg67938.html Of course we could make this finer grained based on features like SOC_HAS_XYZ or SOC_HAS_OMAP3PLUS_PRMXYZBITS if you have some grouping like that in mind. Regards, Tony -- 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: [PATCH 02/13] ARM: OMAP5: Add minimal support for OMAP5430 SOC
On Mon, 7 May 2012, Tony Lindgren wrote: * Paul Walmsley p...@pwsan.com [120507 12:11]: On Fri, 4 May 2012, Tony Lindgren wrote: How about we add CONFIG_SOC_OMAP3PLUS in the clean-up series? Then this becomes just: #ifdef CONFIG_SOC_OMAP3PLUS We might want to consider having separate CONFIG_SOC_* values for each SoC. So rather than CONFIG_SOC_OMAP3PLUS, we'd have CONFIG_SOC_OMAP3430, CONFIG_SOC_OMAP3630, etc. Hmm but this would be in addition to the SOC specific options. The goal is to cut down the ifdeffery needed all over the place to add new SoCs, see the experimental patch I posted: http://www.mail-archive.com/linux-omap@vger.kernel.org/msg67938.html I see. Yeah, the problem is that it's hard to figure out which SoCs should go into SOC_OMAP3PLUS. AM33xx? TI81xx? etc. Some of these chips draw some aspects from chips that we've historically considered part of OMAP3, and other aspects from OMAP4-style chips. What seems better to me would be to use a more specific, IP block-focused macro as needed. So to pick a random example, in mach-omap2/control.c, we currently skip compilation of the scratchpad functions unless CONFIG_ARCH_OMAP3 is defined. Instead of making this SOC_OMAP3PLUS-dependent, or dependent on a mess of CONFIG_SOC_* macros, maybe something like CONFIG_OMAP3430_SCM_SCRATCHPAD_FORMAT? Of course, for some of these cases, maybe it makes more sense to move the code out into a separate file, control-omap3-scratchpad.c or something, and just conditionally compile it to avoid the #ifdefs. Just to continue exploring just using the SoC specific options, we would currently end up with more of this kind of nastiness: #if defined(CONFIG_ARCH_OMAP4) !(defined(CONFIG_ARCH_OMAP2) || \ defined(CONFIG_ARCH_OMAP3)) Yep, agreed that we don't want that. The other motivation would be to support device manufacturers who only wish to build a kernel for the single device that they are shipping. In terms of kernels shipped, this is probably the most popular use-case. With something like CONFIG_SOC_OMAPAM33XX, they can avoid building quite a bit of code and data (and potentially bugs) that are not needed for their specific device. Sure, but I think you're missing the point: This would be in addition to the SoC specific options. Do you still see issues with that? Indeed, I misunderstood your proposal, sorry about that. Anyway, to me it seems like it would be a little better to have CONFIG_* macros that are specific to the IP block in question, only because of the SoC grouping problem that I mentioned above. - Paul -- 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: [PATCH 02/13] ARM: OMAP5: Add minimal support for OMAP5430 SOC
On Mon, 7 May 2012, Tony Lindgren wrote: Of course we could make this finer grained based on features like SOC_HAS_XYZ or SOC_HAS_OMAP3PLUS_PRMXYZBITS if you have some grouping like that in mind. Yep, I like that idea. - Paul -- 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: [PATCH 02/13] ARM: OMAP5: Add minimal support for OMAP5430 SOC
On Tue, May 08, 2012 at 01:05:01, Tony Lindgren wrote: * Tony Lindgren t...@atomide.com [120507 12:22]: * Paul Walmsley p...@pwsan.com [120507 12:11]: Hi, On Fri, 4 May 2012, Tony Lindgren wrote: How about we add CONFIG_SOC_OMAP3PLUS in the clean-up series? Then this becomes just: #ifdef CONFIG_SOC_OMAP3PLUS We might want to consider having separate CONFIG_SOC_* values for each SoC. So rather than CONFIG_SOC_OMAP3PLUS, we'd have CONFIG_SOC_OMAP3430, CONFIG_SOC_OMAP3630, etc. Hmm but this would be in addition to the SOC specific options. The goal is to cut down the ifdeffery needed all over the place to add new SoCs, see the experimental patch I posted: http://www.mail-archive.com/linux-omap@vger.kernel.org/msg67938.html Of course we could make this finer grained based on features like SOC_HAS_XYZ or SOC_HAS_OMAP3PLUS_PRMXYZBITS if you have some grouping like that in mind. This is much better approach than both ARCH_OMAPx and SOC_OMAP. Thanks, Vaibhav -- 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: [PATCH 02/13] ARM: OMAP5: Add minimal support for OMAP5430 SOC
Hi Tony,
[snip]
OK this seems to be based on Santosh' Makefile cleanup.
yes..
-#if defined(CONFIG_ARCH_OMAP3) || defined(CONFIG_ARCH_OMAP4)
+#if defined(CONFIG_ARCH_OMAP3) || defined(CONFIG_ARCH_OMAP4) || \
+ defined(CONFIG_ARCH_OMAP5)
How about we add CONFIG_SOC_OMAP3PLUS in the clean-up series?
Then this becomes just:
#ifdef CONFIG_SOC_OMAP3PLUS
Ok, thanks for the example later. I will do a cleanup patch and
rebase this one.
-# ifdef CONFIG_ARCH_OMAP4
+#if defined(CONFIG_ARCH_OMAP4) || defined(CONFIG_ARCH_OMAP5)
extern int omap4_cminst_wait_module_idle(u8 part, u16 inst, s16 cdoffs,
u16 clkctrl_offs);
And this would be:
#ifdef CONFIG_SOC_OMAP4PLUS
ok..
Also, please change the whole series to use CONFIG_SOC_OMAP5 instead
of CONFIG_ARCH_OMAP5. CONFIG_ARCH_OMAP stuff will go away except
for CONFIG_ARCH_OMAP2PLUS. Sorry forgot to mention that earlier.
ok. sure. will change this.
-#if defined(CONFIG_ARCH_OMAP4) !(defined(CONFIG_ARCH_OMAP2) || \
- defined(CONFIG_ARCH_OMAP3))
+#if (defined(CONFIG_ARCH_OMAP5) || defined(CONFIG_ARCH_OMAP4)) \
+ !(defined(CONFIG_ARCH_OMAP2) || defined(CONFIG_ARCH_OMAP3))
+
static inline u32 omap2_prm_read_mod_reg(s16 module, u16 idx)
{
WARN(1, prm: omap2xxx/omap3xxx specific function and
Maybe these functions could be just set up as __weak to avoid the
ifdeffery?
sorry to understand,
you mean make this weak and have a strong override for OMAP2 ?
#define CK_443X (1 11)
#define CK_TI816X (1 12)
#define CK_446X (1 13)
+#define CK_54XX (1 14)
#define CK_1710 (1 15) /* 1710 extra for rate
selection */
Are we going to have to patch tons of existing clocks just to add
CK_54XX? If so, we should init clocks using SoC specific lists instead.
diff --git a/arch/arm/plat-omap/include/plat/clock.h
b/arch/arm/plat-omap/include/plat/clock.h
index d0ef57c..41858f4 100644
--- a/arch/arm/plat-omap/include/plat/clock.h
+++ b/arch/arm/plat-omap/include/plat/clock.h
@@ -61,6 +61,7 @@ struct clkops {
#define RATE_IN_4460 (1 7)
#define RATE_IN_AM33XX (1 8)
#define RATE_IN_TI814X (1 9)
+#define RATE_IN_54XX (1 10)
This too may have similar issues, but I guess that's really a different
patch series to sort out..
ok. agree
-#if defined(CONFIG_ARCH_OMAP3) || defined(CONFIG_ARCH_OMAP4)
+#if defined(CONFIG_ARCH_OMAP3) || defined(CONFIG_ARCH_OMAP4) \
+ || defined(CONFIG_ARCH_OMAP5)
void __iomem *autoidle_reg;
void __iomem *idlest_reg;
u32 autoidle_mask;
#ifdef CONFIG_SOC_OMAP3PLUS could be used here too
ok..
Thanks,
Sricharan
--
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: [PATCH 02/13] ARM: OMAP5: Add minimal support for OMAP5430 SOC
* R Sricharan r.sricha...@ti.com [120503 00:30]: --- a/arch/arm/mach-omap2/Makefile +++ b/arch/arm/mach-omap2/Makefile @@ -16,6 +16,7 @@ secure-common = omap-smc.o omap-secure.o obj-$(CONFIG_ARCH_OMAP2) += $(omap-2-3-common) $(hwmod-common) obj-$(CONFIG_ARCH_OMAP3) += $(omap-2-3-common) $(hwmod-common) $(secure-common) obj-$(CONFIG_ARCH_OMAP4) += prm44xx.o $(hwmod-common) $(secure-common) +obj-$(CONFIG_ARCH_OMAP5) += prm44xx.o $(hwmod-common) $(secure-common) ifneq ($(CONFIG_SND_OMAP_SOC_MCBSP),) obj-y += mcbsp.o @@ -27,8 +28,10 @@ obj-$(CONFIG_TWL4030_CORE) += omap_twl.o obj-$(CONFIG_SMP)+= omap-smp.o omap-headsmp.o obj-$(CONFIG_HOTPLUG_CPU)+= omap-hotplug.o -obj-$(CONFIG_ARCH_OMAP4) += omap4-common.o omap-wakeupgen.o -obj-$(CONFIG_ARCH_OMAP4) += sleep44xx.o +omap-4-5-common = omap4-common.o omap-wakeupgen.o \ +sleep44xx.o +obj-$(CONFIG_ARCH_OMAP4) += $(omap-4-5-common) +obj-$(CONFIG_ARCH_OMAP5)+= $(omap-4-5-common) plus_sec := $(call as-instr,.arch_extension sec,+sec) AFLAGS_omap-headsmp.o:=-Wa,-march=armv7-a$(plus_sec) @@ -68,6 +71,7 @@ obj-$(CONFIG_ARCH_OMAP2)+= sleep24xx.o obj-$(CONFIG_ARCH_OMAP3) += pm34xx.o sleep34xx.o obj-$(CONFIG_ARCH_OMAP3) += cpuidle34xx.o obj-$(CONFIG_ARCH_OMAP4) += pm44xx.o omap-mpuss-lowpower.o +obj-$(CONFIG_ARCH_OMAP5) += omap-mpuss-lowpower.o obj-$(CONFIG_ARCH_OMAP4) += cpuidle44xx.o obj-$(CONFIG_PM_DEBUG) += pm-debug.o obj-$(CONFIG_OMAP_SMARTREFLEX) += sr_device.o smartreflex.o @@ -87,9 +91,11 @@ obj-y += prm_common.o obj-$(CONFIG_ARCH_OMAP2) += prcm.o cm2xxx_3xxx.o prm2xxx_3xxx.o obj-$(CONFIG_ARCH_OMAP3) += prcm.o cm2xxx_3xxx.o prm2xxx_3xxx.o obj-$(CONFIG_ARCH_OMAP3) += vc3xxx_data.o vp3xxx_data.o -obj-$(CONFIG_ARCH_OMAP4) += prcm.o cminst44xx.o cm44xx.o -obj-$(CONFIG_ARCH_OMAP4) += prcm_mpu44xx.o prminst44xx.o -obj-$(CONFIG_ARCH_OMAP4) += vc44xx_data.o vp44xx_data.o prm44xx.o +omap-prcm-4-5-common = prcm.o cminst44xx.o cm44xx.o \ +prcm_mpu44xx.o prminst44xx.o \ +vc44xx_data.o vp44xx_data.o +obj-$(CONFIG_ARCH_OMAP4) += $(omap-prcm-4-5-common) prm44xx.o +obj-$(CONFIG_ARCH_OMAP5)+= $(omap-prcm-4-5-common) # OMAP voltage domains voltagedomain-common := voltage.o vc.o vp.o @@ -99,6 +105,7 @@ obj-$(CONFIG_ARCH_OMAP3) += $(voltagedomain-common) obj-$(CONFIG_ARCH_OMAP3) += voltagedomains3xxx_data.o obj-$(CONFIG_ARCH_OMAP4) += $(voltagedomain-common) obj-$(CONFIG_ARCH_OMAP4) += voltagedomains44xx_data.o +obj-$(CONFIG_ARCH_OMAP5) += $(voltagedomain-common) # OMAP powerdomain framework powerdomain-common += powerdomain.o powerdomain-common.o @@ -113,6 +120,7 @@ obj-$(CONFIG_ARCH_OMAP3) += powerdomains2xxx_3xxx_data.o obj-$(CONFIG_ARCH_OMAP4) += $(powerdomain-common) obj-$(CONFIG_ARCH_OMAP4) += powerdomain44xx.o obj-$(CONFIG_ARCH_OMAP4) += powerdomains44xx_data.o +obj-$(CONFIG_ARCH_OMAP5)+= $(powerdomain-common) powerdomain44xx.o # PRCM clockdomain control obj-$(CONFIG_ARCH_OMAP2) += clockdomain.o @@ -124,9 +132,11 @@ obj-$(CONFIG_ARCH_OMAP3) += clockdomain.o obj-$(CONFIG_ARCH_OMAP3) += clockdomain2xxx_3xxx.o obj-$(CONFIG_ARCH_OMAP3) += clockdomains2xxx_3xxx_data.o obj-$(CONFIG_ARCH_OMAP3) += clockdomains3xxx_data.o -obj-$(CONFIG_ARCH_OMAP4) += clockdomain.o -obj-$(CONFIG_ARCH_OMAP4) += clockdomain44xx.o +omap-clock-4-5-common= clockdomain.o \ + clockdomain44xx.o +obj-$(CONFIG_ARCH_OMAP4) += $(omap-clock-4-5-common) obj-$(CONFIG_ARCH_OMAP4) += clockdomains44xx_data.o +obj-$(CONFIG_ARCH_OMAP5) += $(omap-clock-4-5-common) # Clock framework obj-$(CONFIG_ARCH_OMAP2) += $(clock-common) clock2xxx.o @@ -144,6 +154,8 @@ obj-$(CONFIG_ARCH_OMAP3) += dpll3xxx.o clock3xxx_data.o obj-$(CONFIG_ARCH_OMAP3) += clkt_iclk.o obj-$(CONFIG_ARCH_OMAP4) += $(clock-common) clock44xx_data.o obj-$(CONFIG_ARCH_OMAP4) += dpll3xxx.o dpll44xx.o +obj-$(CONFIG_ARCH_OMAP5) += $(clock-common) +obj-$(CONFIG_ARCH_OMAP5) += dpll3xxx.o dpll44xx.o # OMAP2 clock rate set data (old OPP data) obj-$(CONFIG_SOC_OMAP2420)
Re: [PATCH 02/13] ARM: OMAP5: Add minimal support for OMAP5430 SOC
* Tony Lindgren t...@atomide.com [120504 15:43]: --- a/arch/arm/mach-omap2/clock.c +++ b/arch/arm/mach-omap2/clock.c @@ -400,7 +400,8 @@ int omap2_clk_set_parent(struct clk *clk, struct clk *new_parent) /* OMAP3/4 non-CORE DPLL clkops */ -#if defined(CONFIG_ARCH_OMAP3) || defined(CONFIG_ARCH_OMAP4) +#if defined(CONFIG_ARCH_OMAP3) || defined(CONFIG_ARCH_OMAP4) || \ + defined(CONFIG_ARCH_OMAP5) How about we add CONFIG_SOC_OMAP3PLUS in the clean-up series? Then this becomes just: #ifdef CONFIG_SOC_OMAP3PLUS --- a/arch/arm/mach-omap2/cminst44xx.h +++ b/arch/arm/mach-omap2/cminst44xx.h @@ -19,7 +19,7 @@ extern void omap4_cminst_clkdm_force_wakeup(u8 part, s16 inst, u16 cdoffs); extern int omap4_cminst_wait_module_ready(u8 part, u16 inst, s16 cdoffs, u16 clkctrl_offs); -# ifdef CONFIG_ARCH_OMAP4 +#if defined(CONFIG_ARCH_OMAP4) || defined(CONFIG_ARCH_OMAP5) extern int omap4_cminst_wait_module_idle(u8 part, u16 inst, s16 cdoffs, u16 clkctrl_offs); And this would be: #ifdef CONFIG_SOC_OMAP4PLUS Something like this might do the trick (untested): --- a/arch/arm/mach-omap2/Kconfig +++ b/arch/arm/mach-omap2/Kconfig @@ -28,10 +28,14 @@ config ARCH_OMAP2 select MULTI_IRQ_HANDLER select PINCTRL +bool SOC_OMAP3PLUS + bool + config ARCH_OMAP3 bool TI OMAP3 depends on ARCH_OMAP2PLUS default y + select SOC_OMAP3PLUS select CPU_V7 select USB_ARCH_HAS_EHCI if USB_SUPPORT select ARCH_HAS_OPP @@ -40,10 +44,15 @@ config ARCH_OMAP3 select MULTI_IRQ_HANDLER select PINCTRL +bool SOC_OMAP4PLUS + bool + config ARCH_OMAP4 bool TI OMAP4 default y depends on ARCH_OMAP2PLUS + select SOC_OMAP3PLUS + select SOC_OMAP4PLUS select CACHE_L2X0 select CPU_V7 select ARM_GIC -- 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
