All of lore.kernel.org
 help / color / mirror / Atom feed
From: robherring2@gmail.com (Rob Herring)
To: linux-arm-kernel@lists.infradead.org
Subject: [PATCH v2 0/9] ARM: multi-platform kconfig cleanup and mach-virt removal
Date: Wed, 12 Feb 2014 08:07:12 -0600	[thread overview]
Message-ID: <CAL_JsqJkCXSFJZzRBRTrKh16PoBjvF95uKJbZAic-pk3htf_jg@mail.gmail.com> (raw)
In-Reply-To: <20140212134655.GC29132@mudshark.cambridge.arm.com>

On Wed, Feb 12, 2014 at 7:46 AM, Will Deacon <will.deacon@arm.com> wrote:
> On Wed, Feb 12, 2014 at 01:26:41PM +0000, Arnd Bergmann wrote:
>> On Tuesday 11 February 2014, Rob Herring wrote:
>> > The previous version [1] was mainly a discussion about v6 vs. v6K.
>> > Several platforms have this wrong and incorrectly select v6 when the
>> > more optimal v6K option could be used. After more research, my memory
>> > about i.MX31 was wrong and it does need to remain v6.
>>
>> Just curious: do you have more information on this? Are all i.MX31 ARMv6
>> and all i.MX35 v6k as the current Kconfig claims,  or is it more
>> complicated?
>
> Slightly tangential, but the one to watch out for is 1136. Prior to r1 (i.e.
> r0pX), it is v6 but r1pX+ are v6k (without SMP).

Right. I originally was thinking that the MX31 1.x was r0pX and MX31
2.x was r1pX and that there are no 1.x chips around. However, after
checking the errata sheet, 1.x is r0p1 and 2.x is r0p4. It must have
been one of the other 1136 chips we did that moved to r1pX.

>> * integrator and realview apparently allow both CPU_V6 and CPU_V6K
>>   to be manually selected. Is that actually the correct behavior
>>   in that both kinds of core tiles exist?
>
> I have 1136 r0p1 on an integrator CP, so I suppose it could also take an
> 1136 r1pX without any trouble.

Presumably some of both exist which is why the config options are as they are?

Rob

  reply	other threads:[~2014-02-12 14:07 UTC|newest]

Thread overview: 37+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-02-11 21:11 [PATCH v2 0/9] ARM: multi-platform kconfig cleanup and mach-virt removal Rob Herring
2014-02-11 21:11 ` [PATCH v2 1/9] ARM: centralize common multi-platform kconfig options Rob Herring
2014-02-14 10:40   ` Linus Walleij
2014-02-14 14:02     ` Rob Herring
2014-02-24  9:41       ` Linus Walleij
2014-02-28 18:37   ` Kevin Hilman
2014-02-28 20:15     ` Arnd Bergmann
2014-02-28 20:22       ` Kevin Hilman
2014-02-28 20:33         ` Arnd Bergmann
2014-04-20 10:56           ` Daniel Willmann
2014-02-11 21:11 ` [PATCH 2/9] ARM: select HAVE_SMP for V7 multi-platform Rob Herring
2014-02-14 10:41   ` Linus Walleij
2014-02-11 21:11 ` [PATCH 3/9] ARM: select MIGHT_HAVE_CACHE_L2X0 " Rob Herring
2014-02-12 20:32   ` Stephen Warren
2014-02-13 13:10     ` Rob Herring
2014-02-11 21:11 ` [PATCH 4/9] ARM: Select V6K instead of V6 by default for multi-platform Rob Herring
2014-02-11 21:22   ` Arnd Bergmann
2014-02-11 21:26     ` Rob Herring
2014-02-11 21:27       ` Arnd Bergmann
2014-02-12  4:07   ` Shawn Guo
2014-02-11 21:11 ` [PATCH 5/9] ARM: bcm2835: enable V6K instead of plain V6 Rob Herring
2014-02-11 21:11 ` [PATCH 6/9] ARM: cns3xxx: " Rob Herring
2014-02-11 21:11 ` [PATCH 7/9] ARM: vt8500: " Rob Herring
2014-02-11 21:11 ` [PATCH 8/9] ARM: virt: make mach-virt just a kconfig option Rob Herring
2014-02-12 14:03   ` Marc Zyngier
2014-02-11 21:11 ` [PATCH 9/9] ARM: virt: select ARM_AMBA Rob Herring
2014-02-12 13:26 ` [PATCH v2 0/9] ARM: multi-platform kconfig cleanup and mach-virt removal Arnd Bergmann
2014-02-12 13:46   ` Will Deacon
2014-02-12 14:07     ` Rob Herring [this message]
2014-02-12 16:53       ` Arnd Bergmann
2014-02-12 17:11         ` Marc Zyngier
2014-02-12 17:16           ` Will Deacon
2014-02-12 18:07             ` Arnd Bergmann
2014-02-12 18:15               ` Will Deacon
2014-02-12 18:20                 ` Arnd Bergmann
2014-02-12 20:38 ` Stephen Warren
2014-02-13  2:30 ` Stephen Warren

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=CAL_JsqJkCXSFJZzRBRTrKh16PoBjvF95uKJbZAic-pk3htf_jg@mail.gmail.com \
    --to=robherring2@gmail.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 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.