All of lore.kernel.org
 help / color / mirror / Atom feed
From: Tony Lindgren <tony@atomide.com>
To: "Hiremath, Vaibhav" <hvaibhav@ti.com>
Cc: Russell King <linux@arm.linux.org.uk>,
	Paul Walmsley <paul@pwsan.com>,
	"Cousson, Benoit" <b-cousson@ti.com>,
	"linux-arm-kernel@lists.infradead.org"
	<linux-arm-kernel@lists.infradead.org>,
	"linux-omap@vger.kernel.org" <linux-omap@vger.kernel.org>
Subject: Re: Without MACH_ option Early printk (DEBUG_LL)
Date: Fri, 31 Aug 2012 09:11:22 -0700	[thread overview]
Message-ID: <20120831161122.GO1303@atomide.com> (raw)
In-Reply-To: <79CD15C6BA57404B839C016229A409A83EA9EB0F@DBDE01.ent.ti.com>

* Hiremath, Vaibhav <hvaibhav@ti.com> [120831 09:06]:
> On Fri, Aug 31, 2012 at 21:22:26, Tony Lindgren wrote:
> > * Vaibhav Hiremath <hvaibhav@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?
Or does that require that MACHINE_START is there as well?

Regards,

Tony

WARNING: multiple messages have this Message-ID (diff)
From: tony@atomide.com (Tony Lindgren)
To: linux-arm-kernel@lists.infradead.org
Subject: Without MACH_ option Early printk (DEBUG_LL)
Date: Fri, 31 Aug 2012 09:11:22 -0700	[thread overview]
Message-ID: <20120831161122.GO1303@atomide.com> (raw)
In-Reply-To: <79CD15C6BA57404B839C016229A409A83EA9EB0F@DBDE01.ent.ti.com>

* Hiremath, Vaibhav <hvaibhav@ti.com> [120831 09:06]:
> On Fri, Aug 31, 2012 at 21:22:26, Tony Lindgren wrote:
> > * Vaibhav Hiremath <hvaibhav@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?
Or does that require that MACHINE_START is there as well?

Regards,

Tony

  reply	other threads:[~2012-08-31 16:11 UTC|newest]

Thread overview: 26+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2012-08-31 14:54 Without MACH_ option Early printk (DEBUG_LL) Vaibhav Hiremath
2012-08-31 14:54 ` Vaibhav Hiremath
2012-08-31 15:52 ` Tony Lindgren
2012-08-31 15:52   ` Tony Lindgren
2012-08-31 16:06   ` Hiremath, Vaibhav
2012-08-31 16:06     ` Hiremath, Vaibhav
2012-08-31 16:11     ` Tony Lindgren [this message]
2012-08-31 16:11       ` Tony Lindgren
2012-08-31 16:37       ` Hiremath, Vaibhav
2012-08-31 16:37         ` Hiremath, Vaibhav
2012-08-31 16:47       ` Hiremath, Vaibhav
2012-08-31 16:47         ` Hiremath, Vaibhav
2012-08-31 17:06         ` Tony Lindgren
2012-08-31 17:06           ` Tony Lindgren
2012-08-31 17:13 ` Russell King - ARM Linux
2012-08-31 17:13   ` Russell King - ARM Linux
2012-08-31 17:23   ` Hiremath, Vaibhav
2012-08-31 17:23     ` Hiremath, Vaibhav
2012-08-31 18:23     ` Nicolas Pitre
2012-08-31 18:23       ` Nicolas Pitre
2012-09-03  4:27       ` Mohammed, Afzal
2012-09-03  4:27         ` Mohammed, Afzal
2012-09-04  2:04         ` Nicolas Pitre
2012-09-04  2:04           ` Nicolas Pitre
2012-09-04  4:27           ` Hiremath, Vaibhav
2012-09-04  4:27             ` Hiremath, Vaibhav

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20120831161122.GO1303@atomide.com \
    --to=tony@atomide.com \
    --cc=b-cousson@ti.com \
    --cc=hvaibhav@ti.com \
    --cc=linux-arm-kernel@lists.infradead.org \
    --cc=linux-omap@vger.kernel.org \
    --cc=linux@arm.linux.org.uk \
    --cc=paul@pwsan.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.