Without MACH_ option Early printk (DEBUG_LL)

Hiremath, Vaibhav hvaibhav at ti.com
Fri Aug 31 12:47:12 EDT 2012


On Fri, Aug 31, 2012 at 22:07:37, Hiremath, Vaibhav wrote:
> On Fri, Aug 31, 2012 at 21:41:22, Tony Lindgren wrote:
> > * Hiremath, Vaibhav <hvaibhav at ti.com> [120831 09:06]:
> > > On Fri, Aug 31, 2012 at 21:22:26, Tony Lindgren wrote:
> > > > * Vaibhav Hiremath <hvaibhav at ti.com> [120831 07:55]:
> > > > > Hi Russell & Tony,
> > > > > 
> > > > > AM335X EVM (based on AM33XX device) only supports DT boot mode and
> > > > > doesn't have CONFIG_MACH_AM335XEVM option defined. Some time back during
> > > > > baseport submission we had aligned that, we won't create separate EVM
> > > > > options, killing the board file all-together.
> > > > > 
> > > > > Having said that, the early printk option (DEBUG_LL) is broken, the
> > > > > auto-generated file "./include/generated/mach-types.h" still refers to
> > > > > CONFIG_MACH_AM335XEVM option,
> > > > 
> > > > The way we're heading is that the DEBUG_LL options will only work for
> > > > one hardcoded machine where you need to select the uart type and address
> > > > in Kconfig. Or just patch it in.
> > > >  
> > > > > #ifdef CONFIG_MACH_AM335XEVM
> > > > > # ifdef machine_arch_type
> > > > > #  undef machine_arch_type
> > > > > #  define machine_arch_type     __machine_arch_type
> > > > > # else
> > > > > #  define machine_arch_type     MACH_TYPE_AM335XEVM
> > > > > # endif
> > > > > # define machine_is_am335xevm() (machine_arch_type == MACH_TYPE_AM335XEVM)
> > > > > #else
> > > > > # define machine_is_am335xevm() (0)
> > > > > #endif
> > > > > 
> > > > > 
> > > > > So I am thinking of changing the config_xxx option to SOC_AM33XX or
> > > > > ARCH_OMAP2PLUS, something like below,
> > > > > 
> > > > > am335xevm        SOC_AM33XX          AM335XEVM         3589
> > > > > 
> > > > > OR
> > > > > 
> > > > > am335xevm        ARCH_OMAP2PLUS      AM335XEVM         3589
> > > > > 
> > > > > 
> > > > > Can you comment on this? Based on that I will submit the patch.
> > > > 
> > > > I think that would at minimum break things for autogenerated
> > > > mach-types.h where if only some other non-am335xevm machine is
> > > > selected (like omap-generic) things don't get optimized out any
> > > > longer as they currently do.
> > > > 
> > > 
> > > Agreed. In that case the first option should work here, right?
> > 
> > It gets messy if we start mixing mach and soc defines there..
> > 
> > How about just add a hidden Kconfig option to mach-omap2/Kconfig 
> > that always selects MACH_TYPE_AM335XEVM if SOC_AM33XX is set?
> 
> Great, this is what I had in my mind but since it is hidden option I thought 
> may not be right thing to do.
> I was just thinking in the direction that, it should be logical and fine if 
> SOC_AM33XX is used for all AM33xx based machines, isn't it?
> 
> Anyway, I think we are on same page here, I will add it and submit the patch 
> ASAP.
> 
> > Or does that require that MACHINE_START is there as well?
> > 
> 
> I do not think so, they are not related to each other, this option is 
> required only during decompression.
> I have tested it on BeagleBone and it is working.
> 

Can you please review below patch? If you think its ok, I will send the 
patch -


diff --git a/arch/arm/mach-omap2/Kconfig b/arch/arm/mach-omap2/Kconfig
index fccbdf0..eccafb4 100644
--- a/arch/arm/mach-omap2/Kconfig
+++ b/arch/arm/mach-omap2/Kconfig
@@ -104,6 +104,9 @@ config SOC_AM33XX
        select CPU_V7
        select ARM_CPU_SUSPEND if PM
        select MULTI_IRQ_HANDLER
+       select MACH_AM335XEVM
+       select MACH_AM335XIAEVM
+       select MACH_TAM335X

 config OMAP_PACKAGE_ZAF
        bool
@@ -140,6 +143,15 @@ config MACH_OMAP_GENERIC
          Support for generic TI OMAP2+ boards using Flattened Device Tree.
          More information at Documentation/devicetree

+config MACH_AM335XEVM
+       bool
+
+config MACH_AM335XIAEVM
+       bool
+
+config MACH_TAM335X
+       bool
+
 config MACH_OMAP2_TUSB6010
        bool
        depends on ARCH_OMAP2 && SOC_OMAP2420

Thanks,
Vaibhav



More information about the linux-arm-kernel mailing list