public inbox for linux-tegra@vger.kernel.org
 help / color / mirror / Atom feed
From: Arnd Bergmann <arnd-r2nGTMty4D4@public.gmane.org>
To: Jean-Christophe PLAGNIOL-VILLARD
	<plagnioj-sclMFOaUSTBWk0Htik3J/w@public.gmane.org>
Cc: devicetree-discuss-uLR06cmDAlY/bJ5BZ2RsiQ@public.gmane.org,
	Russell King - ARM Linux
	<linux-lFZ/pmaqli7XmaaqVzeoHQ@public.gmane.org>,
	linux-tegra-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
	linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r@public.gmane.org
Subject: Re: [PATCH] arm/dt: Add SoC detection macros
Date: Sun, 18 Sep 2011 11:28:04 +0200	[thread overview]
Message-ID: <7625276.j6vA9T0aOV@wuerfel> (raw)
In-Reply-To: <20110918004615.GC16141-RQcB7r2h9QmfDR2tN2SG5Ni2O/JbrIOy@public.gmane.org>

On Sunday 18 September 2011 02:46:15 Jean-Christophe PLAGNIOL-VILLARD wrote:
> On 22:56 Sat 17 Sep     , Arnd Bergmann wrote:
> > On Saturday 17 September 2011 20:19:07 Jean-Christophe PLAGNIOL-VILLARD wrote:
> > > 
> > > I agree about it I just mean that if you have the same board with 2 SoC which
> > > are pin to pin compatible detect the soc type will be usefull as the soc
> > > resource may not be the same
> > 
> > In that scenario, you would put all SOC specific data into one .dtsi
> > file and all board data into another .dtsi file and then create a
> > description for the combination using a trivial .dts file with two
> > include statements. This is all solved outside of the kernel already,
> > so there is no need for infrastructure in the kernel.
> except in this case you must have 2 machine id which can be avoided if you can
> detect the soc at kernel level

But when you move to device tree based probing, you don't use machine numbers
at all, so it doesn't matter.

Detecting the soc in the kernel is pointless, since you describe it in
the device tree anyway. Ideally, the kernel should not need to know about
the possible SoCs at all, it just needs to know the components on it.

While we first want to get to the point where the device tree only needs
to describe the off-chip devices, in the long run it's much better to
describe all of the hardware in the device tree, as we do with new platforms
(zynq, prima2, ...) already. I don't think we need to introduce
infrastructure now when we know that we want to get rid of it later.

	Arnd

  parent reply	other threads:[~2011-09-18  9:28 UTC|newest]

Thread overview: 11+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2011-09-09  8:02 [PATCH] arm/dt: Add SoC detection macros Allen Martin
     [not found] ` <1315555339-12685-1-git-send-email-amartin-DDmLM1+adcrQT0dZR+AlfA@public.gmane.org>
2011-09-09 16:45   ` Olof Johansson
2011-09-17 10:28   ` Russell King - ARM Linux
2011-09-17 10:34     ` Jean-Christophe PLAGNIOL-VILLARD
     [not found]       ` <20110917103457.GP28104-RQcB7r2h9QmfDR2tN2SG5Ni2O/JbrIOy@public.gmane.org>
2011-09-17 11:23         ` Russell King - ARM Linux
     [not found]           ` <20110917112321.GE16381-l+eeeJia6m9vn6HldHNs0ANdhmdF6hFW@public.gmane.org>
2011-09-17 18:19             ` Jean-Christophe PLAGNIOL-VILLARD
     [not found]               ` <20110917181907.GA16141-RQcB7r2h9QmfDR2tN2SG5Ni2O/JbrIOy@public.gmane.org>
2011-09-17 20:56                 ` Arnd Bergmann
2011-09-18  0:46                   ` Jean-Christophe PLAGNIOL-VILLARD
     [not found]                     ` <20110918004615.GC16141-RQcB7r2h9QmfDR2tN2SG5Ni2O/JbrIOy@public.gmane.org>
2011-09-18  9:28                       ` Arnd Bergmann [this message]
2011-09-19 17:26             ` Allen Martin
     [not found]               ` <3C7A7ACA8617D24290826EC008B5CD083E17B00988-lR+7xdUAJVNDw2glCA4ptUEOCMrvLtNR@public.gmane.org>
2011-09-19 20:08                 ` Olof Johansson

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=7625276.j6vA9T0aOV@wuerfel \
    --to=arnd-r2ngtmty4d4@public.gmane.org \
    --cc=devicetree-discuss-uLR06cmDAlY/bJ5BZ2RsiQ@public.gmane.org \
    --cc=linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r@public.gmane.org \
    --cc=linux-lFZ/pmaqli7XmaaqVzeoHQ@public.gmane.org \
    --cc=linux-tegra-u79uwXL29TY76Z2rM5mHXA@public.gmane.org \
    --cc=plagnioj-sclMFOaUSTBWk0Htik3J/w@public.gmane.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