Thread (63 messages) flat view 63 messages, 9 authors, 2012-05-14
STALE5246d

[PATCH 02/13] ARM: OMAP5: Add minimal support for OMAP5430 SOC

From: tony@atomide.com (Tony Lindgren)
Date: 2012-05-09 16:00:42
Also in: linux-omap

* R, Sricharan [off-list ref] [120509 02:09]:
Tony,

[snip]
quoted
quoted
quoted
quoted
-#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
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help