From: tony@atomide.com (Tony Lindgren)
To: linux-arm-kernel@lists.infradead.org
Subject: [PATCH] ARM: Keystone: Introduce Kconfig option to compile in typical Keystone features
Date: Wed, 8 Jun 2016 02:47:48 -0700 [thread overview]
Message-ID: <20160608094747.GG22406@atomide.com> (raw)
In-Reply-To: <10295246.2MDnqWQbb8@wuerfel>
Hi,
* Arnd Bergmann <arnd@arndb.de> [160607 01:11]:
> A lot of these options are typical for all ARMv7 machines: AEABI, I2C, NEON,
> PM, REGULATOR and VFP are things that we probably want to default to enabled
> whenever we build a MULTI_V7 kernel, some also for V5 or V6, we just
> need to come up with a good way to do that while (probably for most of
> them) still allowing them to be disabled with CONFIG_EXPERT. I would
> feel more comfortable with having an ARCH_MULTIPLATFORM_TYPICAL
> Kconfig symbol than with the ARCH_OMAP2PLUS_TYPICAL one that ends up
> turning things on unconditionally whenever you add ARCH_OMAP2PLUS
> to some other configuration.
We still need to be careful about not changing the Kconfig option
name for something like this as it will cause the custom .config files
to fail unless the default is y. But yeah I agree, it would be nice
to have some multiarch sane default selects, then also do the platform
specific selects as needed. Naturally this needs to be kept down to
minimum ideally limited to silent options.
So we could have ARCH_MULTIPLATFORM_TYPICAL, then have the old
ARCH_OMAP2PLUS_TYPICAL select that one. That should keep things
behaving just fine if the old .config had ARCH_OMAP2PLUS_TYPICAL.
> For I2C_OMAP, MENELAUS and TWL4030, we could just add a
> 'default ARCH_OMAP3 || ARCH_OMAP4' or whatever is appropriate for
> each of them. I assume we want to handle TWL6040 the same way, though
> we currently don't do that. MENELAUS seems to be only needed for
> omap2420-n8x0.
We could yeah. TWL4030 is omap2430 to omap3, I don't think we currently
have any omap3 based ones not using twl4030.. But there certainly
are tons of usable devices with the Motorola CPCAP PMIC instead.
Then REGULATOR_FIXED_VOLTAGE we can have platform select like Mark
seems to prefer. HIGHMEM too should be platform specific.
The original reason for ARCH_OMAP2PLUS_TYPICAL was that if omap2plus
is selected with that you actually get a bootable system.
Regards,
Tony
next prev parent reply other threads:[~2016-06-08 9:47 UTC|newest]
Thread overview: 14+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-06-01 21:31 [PATCH] ARM: Keystone: Introduce Kconfig option to compile in typical Keystone features Nishanth Menon
2016-06-01 22:31 ` Arnd Bergmann
2016-06-01 22:49 ` Nishanth Menon
2016-06-01 23:27 ` Santosh Shilimkar
2016-06-07 4:28 ` Tony Lindgren
2016-06-07 8:09 ` Arnd Bergmann
2016-06-07 12:04 ` Mark Brown
2016-06-08 9:47 ` Tony Lindgren [this message]
2016-06-08 16:04 ` Arnd Bergmann
2016-06-09 6:50 ` Tony Lindgren
2016-06-09 10:32 ` Mark Brown
2016-06-01 23:26 ` Santosh Shilimkar
2016-06-02 12:34 ` Nishanth Menon
2016-06-02 18:10 ` Santosh Shilimkar
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=20160608094747.GG22406@atomide.com \
--to=tony@atomide.com \
--cc=linux-arm-kernel@lists.infradead.org \
/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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).