All of lore.kernel.org
 help / color / mirror / Atom feed
From: Will Deacon <will.deacon@arm.com>
To: Cyril Chemparathy <cyril@ti.com>
Cc: "linux-arm-kernel@lists.infradead.org" 
	<linux-arm-kernel@lists.infradead.org>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
	"nico@linaro.org" <nico@linaro.org>,
	Catalin Marinas <Catalin.Marinas@arm.com>
Subject: Re: [RFC 00/23] Introducing the TI Keystone platform
Date: Tue, 24 Jul 2012 10:08:41 +0100	[thread overview]
Message-ID: <20120724090841.GA16435@mudshark.cambridge.arm.com> (raw)
In-Reply-To: <1343092165-9470-1-git-send-email-cyril@ti.com>

Hi Cyril,

Thanks for this, certainly looks like an interesting platform!

Of course, in order to perform any sort of sensible review, I'll need some
silicon to test it on :)

On Tue, Jul 24, 2012 at 02:09:02AM +0100, Cyril Chemparathy wrote:
> TI's scalable KeyStone II architecture includes support for both TMS320C66x
> floating point DSPs and ARM Cortex-A15 clusters, for a mixture of up to 32
> cores per SoC.  The solution is optimized around a high performance chip
> interconnect and a rich set of on chip peripherals.  Please refer [1] for
> initial technical documentation on these devices.

How many A15s can you have on such a SoC? It wasn't clear whether it was 1x4
or 4x4 from the documentation.

> This patch series provides a basic Linux port for these devices, including
> support for SMP, and LPAE boot.  A majority of the patches in this series are
> related to LPAE functionality, imposed by the device architecture which has
> system memory mapped at an address above the 4G 32-bit addressable limit.

I assume you have *some* memory in the bottom 32-bits though, right? Even if
it's just a partial alias of a higher bank.

> This patch series is based on the v3.5 kernel with the smp_ops patch set
> applied on top.  This series is being posted to elicit early feedback, and so
> that some of these fixes may get incorporated early on into the kernel code.
> 
>   [1] - http://www.ti.com/product/tms320tci6636

This is marked as `TI confidential' but I guess that's an oversight [or will
you have to kill me?].

Will

WARNING: multiple messages have this Message-ID (diff)
From: will.deacon@arm.com (Will Deacon)
To: linux-arm-kernel@lists.infradead.org
Subject: [RFC 00/23] Introducing the TI Keystone platform
Date: Tue, 24 Jul 2012 10:08:41 +0100	[thread overview]
Message-ID: <20120724090841.GA16435@mudshark.cambridge.arm.com> (raw)
In-Reply-To: <1343092165-9470-1-git-send-email-cyril@ti.com>

Hi Cyril,

Thanks for this, certainly looks like an interesting platform!

Of course, in order to perform any sort of sensible review, I'll need some
silicon to test it on :)

On Tue, Jul 24, 2012 at 02:09:02AM +0100, Cyril Chemparathy wrote:
> TI's scalable KeyStone II architecture includes support for both TMS320C66x
> floating point DSPs and ARM Cortex-A15 clusters, for a mixture of up to 32
> cores per SoC.  The solution is optimized around a high performance chip
> interconnect and a rich set of on chip peripherals.  Please refer [1] for
> initial technical documentation on these devices.

How many A15s can you have on such a SoC? It wasn't clear whether it was 1x4
or 4x4 from the documentation.

> This patch series provides a basic Linux port for these devices, including
> support for SMP, and LPAE boot.  A majority of the patches in this series are
> related to LPAE functionality, imposed by the device architecture which has
> system memory mapped at an address above the 4G 32-bit addressable limit.

I assume you have *some* memory in the bottom 32-bits though, right? Even if
it's just a partial alias of a higher bank.

> This patch series is based on the v3.5 kernel with the smp_ops patch set
> applied on top.  This series is being posted to elicit early feedback, and so
> that some of these fixes may get incorporated early on into the kernel code.
> 
>   [1] - http://www.ti.com/product/tms320tci6636

This is marked as `TI confidential' but I guess that's an oversight [or will
you have to kill me?].

Will

  parent reply	other threads:[~2012-07-24  9:09 UTC|newest]

Thread overview: 88+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2012-07-24  1:09 [RFC 00/23] Introducing the TI Keystone platform Cyril Chemparathy
2012-07-24  1:09 ` Cyril Chemparathy
2012-07-24  1:09 ` [RFC 01/23] ARM: LPAE: disable phys-to-virt patching on PAE systems Cyril Chemparathy
2012-07-24  1:09   ` Cyril Chemparathy
2012-07-24  9:41   ` Catalin Marinas
2012-07-24  9:41     ` Catalin Marinas
2012-07-24 10:43     ` Cyril Chemparathy
2012-07-24 10:43       ` Cyril Chemparathy
2012-07-24  1:09 ` [RFC 02/23] ARM: LPAE: use signed arithmetic for mask definitions Cyril Chemparathy
2012-07-24  1:09   ` Cyril Chemparathy
2012-07-24 10:05   ` Catalin Marinas
2012-07-24 10:05     ` Catalin Marinas
2012-07-24 10:52     ` Cyril Chemparathy
2012-07-24 10:52       ` Cyril Chemparathy
2012-07-31 15:35     ` Cyril Chemparathy
2012-07-31 15:35       ` Cyril Chemparathy
2012-07-24  1:09 ` [RFC 03/23] ARM: LPAE: use phys_addr_t on virt <--> phys conversion Cyril Chemparathy
2012-07-24  1:10   ` Cyril Chemparathy
2012-07-24 10:37   ` Catalin Marinas
2012-07-24 10:37     ` Catalin Marinas
2012-07-24 10:55     ` Cyril Chemparathy
2012-07-24 10:55       ` Cyril Chemparathy
2012-07-24 11:02       ` Catalin Marinas
2012-07-24 11:02         ` Catalin Marinas
2012-07-24  1:09 ` [RFC 04/23] ARM: LPAE: use phys_addr_t in alloc_init_pud() Cyril Chemparathy
2012-07-24  1:10   ` Cyril Chemparathy
2012-07-24  1:09 ` [RFC 05/23] ARM: LPAE: use phys_addr_t in free_memmap() Cyril Chemparathy
2012-07-24  1:09   ` Cyril Chemparathy
2012-07-24  1:09 ` [RFC 06/23] ARM: LPAE: use phys_addr_t for initrd location and size Cyril Chemparathy
2012-07-24  1:33   ` Cyril Chemparathy
2012-07-24  1:09 ` [RFC 07/23] ARM: LPAE: use phys_addr_t for membank size Cyril Chemparathy
2012-07-24  1:10   ` Cyril Chemparathy
2012-07-24 10:04   ` Will Deacon
2012-07-24 10:04     ` Will Deacon
2012-07-24 10:46     ` Cyril Chemparathy
2012-07-24 10:46       ` Cyril Chemparathy
2012-07-24  1:09 ` [RFC 08/23] ARM: LPAE: use 64-bit pgd physical address in switch_mm() Cyril Chemparathy
2012-07-24  1:10   ` Cyril Chemparathy
2012-07-24  1:09 ` [RFC 09/23] ARM: LPAE: use 64-bit accessors for TTBR registers Cyril Chemparathy
2012-07-24  1:10   ` Cyril Chemparathy
2012-07-24  1:09 ` [RFC 10/23] ARM: mm: use physical addresses in highmem sanity checks Cyril Chemparathy
2012-07-24  1:10   ` Cyril Chemparathy
2012-07-24  1:09 ` [RFC 11/23] ARM: mm: cleanup checks for membank overlap with vmalloc area Cyril Chemparathy
2012-07-24  1:10   ` Cyril Chemparathy
2012-07-24  1:09 ` [RFC 12/23] ARM: mm: clean up membank size limit checks Cyril Chemparathy
2012-07-24  1:10   ` Cyril Chemparathy
2012-07-24  1:09 ` [RFC 13/23] ARM: LPAE: define ARCH_LOW_ADDRESS_LIMIT for bootmem Cyril Chemparathy
2012-07-24  1:10   ` Cyril Chemparathy
2012-07-24  1:09 ` [RFC 14/23] ARM: LPAE: factor out T1SZ and TTBR1 computations Cyril Chemparathy
2012-07-24  1:38   ` Cyril Chemparathy
2012-07-24  1:09 ` [RFC 15/23] ARM: LPAE: allow proc override of TTB setup Cyril Chemparathy
2012-07-24  1:10   ` Cyril Chemparathy
2012-07-24  1:09 ` [RFC 16/23] ARM: LPAE: accomodate >32-bit addresses for page table base Cyril Chemparathy
2012-07-24  1:10   ` Cyril Chemparathy
2012-07-24  1:09 ` [RFC 17/23] ARM: add machine desc hook for early memory/paging initialization Cyril Chemparathy
2012-07-24  1:10   ` Cyril Chemparathy
2012-07-24 14:32   ` Arnd Bergmann
2012-07-24 14:32     ` Arnd Bergmann
2012-07-24 14:47     ` Cyril Chemparathy
2012-07-24 14:47       ` Cyril Chemparathy
2012-07-24  1:09 ` [RFC 18/23] ARM: add virt_to_idmap for interconnect aliasing Cyril Chemparathy
2012-07-24  1:10   ` Cyril Chemparathy
2012-07-24  1:09 ` [RFC 19/23] drivers: cma: fix addressing on PAE machines Cyril Chemparathy
2012-07-24  1:38   ` Cyril Chemparathy
2012-07-24  1:09 ` [RFC 20/23] mm: bootmem: use phys_addr_t for physical addresses Cyril Chemparathy
2012-07-24  1:10   ` Cyril Chemparathy
2012-07-24  1:09 ` [RFC 21/23] ARM: keystone: introducing TI Keystone platform Cyril Chemparathy
2012-07-24  1:38   ` Cyril Chemparathy
2012-07-24 14:46   ` Arnd Bergmann
2012-07-24 14:46     ` Arnd Bergmann
2012-07-24 17:56     ` Cyril Chemparathy
2012-07-24 17:56       ` Cyril Chemparathy
2012-07-24 18:45       ` Arnd Bergmann
2012-07-24 18:45         ` Arnd Bergmann
2012-07-24  1:09 ` [RFC 22/23] ARM: keystone: enable SMP on Keystone machines Cyril Chemparathy
2012-07-24  1:10   ` Cyril Chemparathy
2012-07-24  1:09 ` [RFC 23/23] ARM: keystone: add switch over to high physical address range Cyril Chemparathy
2012-07-24  1:33   ` Cyril Chemparathy
2012-07-24  9:49   ` Catalin Marinas
2012-07-24  9:49     ` Catalin Marinas
2012-07-24 14:39   ` Arnd Bergmann
2012-07-24 14:39     ` Arnd Bergmann
2012-07-24 14:59     ` Cyril Chemparathy
2012-07-24 14:59       ` Cyril Chemparathy
2012-07-24  9:08 ` Will Deacon [this message]
2012-07-24  9:08   ` [RFC 00/23] Introducing the TI Keystone platform Will Deacon
2012-07-24 10:41   ` Cyril Chemparathy
2012-07-24 10:41     ` Cyril Chemparathy

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=20120724090841.GA16435@mudshark.cambridge.arm.com \
    --to=will.deacon@arm.com \
    --cc=Catalin.Marinas@arm.com \
    --cc=cyril@ti.com \
    --cc=linux-arm-kernel@lists.infradead.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=nico@linaro.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.