linux-arm-kernel.lists.infradead.org archive mirror
 help / color / mirror / Atom feed
From: thomas.petazzoni@free-electrons.com (Thomas Petazzoni)
To: linux-arm-kernel@lists.infradead.org
Subject: Device Tree, abstraction of the SoC or the board?
Date: Fri, 15 Jun 2012 20:13:59 +0200	[thread overview]
Message-ID: <20120615201359.4ce9df82@skate> (raw)
In-Reply-To: <20120615100734.GJ26034@lunn.ch>

Le Fri, 15 Jun 2012 12:07:34 +0200,
Andrew Lunn <andrew@lunn.ch> a ?crit :

> So, it looks like the Marvell ASIC engineers moved it for the latest
> SoCs. Could you add a child property of marvell,system-controller
> which indicates where within the system controller the reset
> subcontroller is? Since the two registers are always next to each
> other, we just need one address.

I must say I'm a bit confused in my understanding of what category of
information should be encoded in the Device Tree.

Do we want to encode all the register offsets, bit locations and so on
in the Device Tree? I.e, is the Device Tree suppose to allow porting to
a new SoC without any code modification? Or only to a new board with no
code modification?

For example http://article.gmane.org/gmane.linux.linaro.devel/10554
seems to suggest that the Device Tree will only be used to encode
board-level informations, but not SoC level informations. In that
specific e-mail, the case of the internal SoC clocks are mentioned, and
the OMAP maintainers seem to agree that all the internal SoC clocks
should be listed in C code rather than inside the Device Tree.

On the other hand, the current suggestion of encoding register offsets
inside the Device Tree seems to indicate that we want to encode
SoC-level details inside the Device Tree, which to me (but I might have
gotten everything wrong) contradicts the statement of the OMAP
maintainers mentioned previously.

I'm kind of puzzled by where's the limit between what should be encoded
in the Device Tree and what should remain C code, and I have the
feeling (hopefully incorrect one) that the different sub-architectures
maintainers do not have the same vision on this.

Could anyone show me the direction of the light? :-)

Thomas
-- 
Thomas Petazzoni, Free Electrons
Kernel, drivers, real-time and embedded Linux
development, consulting, training and support.
http://free-electrons.com

  reply	other threads:[~2012-06-15 18:13 UTC|newest]

Thread overview: 24+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2012-06-15  7:44 [PATCH v3] arm: Add basic support for new Marvell Armada 370 and Armada XP SoC Gregory Clement
2012-06-15  7:44 ` [PATCH v3 1/9] clocksource: time-armada-370-xp: Marvell Armada 370/XP SoC timer driver Gregory Clement
2012-06-15  9:09   ` Arnd Bergmann
2012-06-15  9:14     ` Gregory CLEMENT
2012-06-15 10:45   ` Andrew Lunn
2012-06-15 11:38     ` Gregory CLEMENT
2012-06-15 11:54       ` Andrew Lunn
2012-06-15 13:14         ` Nicolas Pitre
2012-06-15  7:44 ` [PATCH v3 2/9] arm: mach-mvebu: add header Gregory Clement
2012-06-15  7:44 ` [PATCH v3 3/9] arm: mach-mvebu: add source files Gregory Clement
2012-06-15  9:12   ` Arnd Bergmann
2012-06-15 10:07   ` Andrew Lunn
2012-06-15 18:13     ` Thomas Petazzoni [this message]
2012-06-15 20:19       ` Device Tree, abstraction of the SoC or the board? Arnd Bergmann
2012-06-15  7:44 ` [PATCH v3 4/9] arm: mach-mvebu: add support for Armada 370 and Armada XP with DT Gregory Clement
2012-06-15  7:44 ` [PATCH v3 5/9] arm: mach-mvebu: add documentation for new device tree bindings Gregory Clement
2012-06-15  9:14   ` Arnd Bergmann
2012-06-15  7:44 ` [PATCH v3 6/9] arm: mach-mvebu: add defconfig Gregory Clement
2012-06-15  7:44 ` [PATCH v3 7/9] arm: mach-mvebu: add compilation/configuration change Gregory Clement
2012-06-15  7:56   ` Andrew Lunn
2012-06-15  8:32     ` Gregory CLEMENT
2012-06-15  9:07     ` Arnd Bergmann
2012-06-15  7:44 ` [PATCH v3 8/9] arm: mach-mvebu: add entry to MAINTAINERS Gregory Clement
2012-06-15  7:44 ` [PATCH v3 9/9] ARM: mvebu: MPIC: read number of interrupts from control register Gregory Clement

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=20120615201359.4ce9df82@skate \
    --to=thomas.petazzoni@free-electrons.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 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).