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
next prev parent 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.