public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: Paul Mundt <lethal@linux-sh.org>
To: Linus Walleij <linus.ml.walleij@gmail.com>
Cc: Pavel Machek <pavel@ucw.cz>, Magnus Damm <magnus.damm@gmail.com>,
	linux@arm.linux.org.uk, eric.y.miao@gmail.com, tony@atomide.com,
	linux-kernel@vger.kernel.org, khilman@deeprootsystems.com,
	ben-linux@fluff.org, linux-arm-kernel@lists.infradead.org
Subject: Re: [PATCH 01/06] ARM: SuperH Mobile ARM, sh7367 and G3EVM support
Date: Tue, 2 Feb 2010 09:12:17 +0900	[thread overview]
Message-ID: <20100202001217.GC13428@linux-sh.org> (raw)
In-Reply-To: <63386a3d1002010819r63aae9edn2f5bc7e7f08a5fdf@mail.gmail.com>

On Mon, Feb 01, 2010 at 05:19:21PM +0100, Linus Walleij wrote:
> 2010/2/1 Paul Mundt <lethal@linux-sh.org>:
> 
> > SH-Mobile (G series, in this case) is a line of SH/ARM multi-cores. They
> > contain both SH and ARM MPUs and are built up almost entirely on SH IP
> > blocks.
> 
> Jaysis, that's one odd bird. There must be some upside to designing
> things like this, is there some paper or conference presentation on the idea
> behind this thing somewhere out there? I just get very curious!
> 
Most of it comes down to customer requirements, where the application
stack is primarily running on a single MPU and the other is primarily
used as a co-processor. In the Japanese cellular market (what this series
was designed for) many people have a lot of existing ITRON code tied to
one architecture or the other that they don't wish to part with, are
unable to port, etc. a lot of that ends up being multimedia bits, but
people have done other things with it, too. We've also done SH/M32R
multi-cores in the past for similar reasons, although those had a limited
production run.

The multiple kernels on multiple CPUs thing is pretty standard for the
Japanese market at least, we face similar issues on SH SMP where we have
a need for lightweight CPU and memory hotplug/unplug in order to offline
different CPUs temporarily for one-shot ITRON/uITRON applications (which
gets to be tricky if that CPUs memory is an active NUMA node that we've
already spread allocations to), this is something quite common in
automotive at least.

The real problem with ITRON is that many of the existing applications
do fairly questionable things with register accesses, which can cause
troubles for things like dynamic clock gating and the like. On the other
hand, it only runs in a single address space, so simply paravirtualizing
the parts we care about should be lightweight enough. Outside of the
Japanese market, ITRON and its variants are much more of an unknown, so
providing Linux for both cores is becoming gradually more important. The
previous generations all contained an integrated cellular baseband which
largely restricted it to the domestic market, although this has been
changing over the last couple of years with multi-band FOMA becoming more
commonplace. In any event, things like AP4 are more intended for general
use and decouple the baseband completely.

The domestic market will likely gradually transition over to Linux on
both cores, but it will take some time, and even then we'll likely never
be rid of ITRON completely (and especially not uITRON). These CPUs have
been in the majority of Japanese cell phones for almost a decade, with a
lot of the underlying code changing very little. The ARM MPU itself is a
new addition on the side that was only added a couple of years ago, but
we still have to wait and see if people are able to make effective use of
both.

As far as public information, there's very little in either english or
japanese. I couldn't really point you at anything specific that you
couldn't find with google. In any event, now that these sorts of things
are no longer restricted to the Japanese domestic market we'll hopefully
be able to employ a greater degree of transparency.

  reply	other threads:[~2010-02-02  0:12 UTC|newest]

Thread overview: 16+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2010-01-28 12:40 [PATCH 00/06] ARM: Initial SuperH Mobile ARM support Magnus Damm
2010-01-28 12:40 ` [PATCH 01/06] ARM: SuperH Mobile ARM, sh7367 and G3EVM support Magnus Damm
2010-01-28 22:08   ` Russell King - ARM Linux
2010-01-29 11:26     ` Magnus Damm
2010-02-01 14:10   ` Pavel Machek
2010-02-01 14:26     ` Paul Mundt
2010-02-01 16:19       ` Linus Walleij
2010-02-02  0:12         ` Paul Mundt [this message]
2010-01-28 12:40 ` [PATCH 02/06] ARM: Add sh7377 and G4EVM support Magnus Damm
2010-01-28 12:41 ` [PATCH 03/06] ARM: Add sh7372 and AP4EVB support Magnus Damm
2010-01-28 22:19   ` Russell King - ARM Linux
2010-01-28 12:41 ` [PATCH 04/06] sh: Build drivers/sh for SuperH Mobile ARM Magnus Damm
2010-01-28 12:41 ` [PATCH 05/06] sh: Let INTC set IRQF_VALID on ARM platforms Magnus Damm
2010-01-29  2:50   ` Paul Mundt
2010-01-28 12:41 ` [PATCH 06/06] sh-sci: Preliminary SuperH Mobile ARM support Magnus Damm
2010-01-29  2:52   ` Paul Mundt

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=20100202001217.GC13428@linux-sh.org \
    --to=lethal@linux-sh.org \
    --cc=ben-linux@fluff.org \
    --cc=eric.y.miao@gmail.com \
    --cc=khilman@deeprootsystems.com \
    --cc=linus.ml.walleij@gmail.com \
    --cc=linux-arm-kernel@lists.infradead.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux@arm.linux.org.uk \
    --cc=magnus.damm@gmail.com \
    --cc=pavel@ucw.cz \
    --cc=tony@atomide.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox