linux-arm-kernel.lists.infradead.org archive mirror
 help / color / mirror / Atom feed
From: rjw@sisk.pl (Rafael J. Wysocki)
To: linux-arm-kernel@lists.infradead.org
Subject: [PATCH 00/02] mach-shmobile: Emma Mobile EV2 - first shot
Date: Sat, 5 May 2012 21:08:02 +0200	[thread overview]
Message-ID: <201205052108.03001.rjw@sisk.pl> (raw)
In-Reply-To: <201205050722.45500.arnd@arndb.de>

On Saturday, May 05, 2012, Arnd Bergmann wrote:
> On Friday 04 May 2012, Rafael J. Wysocki wrote:
> > I'm not sure if I understand your point correctly, so please let me clarify.
> > 
> > Do you think it's better to have a separate mach-emma directory for the
> > new hardware because technically it is a different platform and the fact
> > that it was developed by the same manufacturer as the mach-shmobile hardware
> > is less important?
> 
> Yes, that was my point. Compare this to how we have omap and davinci for TI,
> orion and pxa for Marvell, or mxs and imx for Freescale. These are all
> for the most part independent developments that happened to end up being
> owned by the same company.
> 
> We try to group code based on technical similarities, not on who makes them.
> If you are able to share code between multiple completely independent socs
> you work on, the result shouldn't be to put them into a directory you "own",
> but to generalize the common parts so they can be shared with everyone else,
> too.

This works a slightly different way for the Renesas SoCs, though.  The
mach-shmobile code is (almost) entirely specific to the SoCs and boards and
everything else is already under drivers/ and elsewhere.  That's because
much of that code is shared between the ARM and SH architectures (since there
are SH CPU core in many of those systems along with the ARM CPU cores).
So we generalize the common parts by putting them out of arch/arm rather
than by putting them into a common place in there.

Now, if you insist on us having a separate mach- directory for every platform
(SoC), we can do that I think, but then we should start with splitting up the
existing mach-shmobile into a number of SoC-specific directories rather than
adding new mach- directories for random new parts, because that goes against
our development history to date, which is important too IMHO.

Thanks,
Rafael

  reply	other threads:[~2012-05-05 19:08 UTC|newest]

Thread overview: 20+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2012-05-03 14:46 [PATCH 00/02] mach-shmobile: Emma Mobile EV2 - first shot Magnus Damm
2012-05-03 14:46 ` [PATCH 01/02] mach-shmobile: Emma Mobile EV2 SoC base support Magnus Damm
2012-05-04 13:07   ` Arnd Bergmann
2012-05-04 19:47     ` Arnd Bergmann
2012-05-08 16:56     ` Magnus Damm
2012-05-08 19:35       ` Arnd Bergmann
2012-05-03 14:47 ` [PATCH 02/02] mach-shmobile: KZM9D board prototype support Magnus Damm
2012-05-04 13:14   ` Arnd Bergmann
2012-05-03 19:23 ` [PATCH 00/02] mach-shmobile: Emma Mobile EV2 - first shot Rafael J. Wysocki
2012-05-04 19:57 ` Arnd Bergmann
2012-05-04 21:16   ` Rafael J. Wysocki
2012-05-05  7:22     ` Arnd Bergmann
2012-05-05 19:08       ` Rafael J. Wysocki [this message]
2012-05-05 19:21         ` Arnd Bergmann
2012-05-05 19:30           ` Rafael J. Wysocki
2012-05-05 19:50             ` Arnd Bergmann
2012-05-06 14:23           ` Magnus Damm
2012-05-08 20:12             ` Arnd Bergmann
2012-05-09  7:57           ` Geert Uytterhoeven
2012-05-09  8:12             ` Magnus Damm

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=201205052108.03001.rjw@sisk.pl \
    --to=rjw@sisk.pl \
    --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).