From: dave.martin@linaro.org (Dave Martin)
To: linux-arm-kernel@lists.infradead.org
Subject: [PATCH v6 9/9] ARM: vexpress: Add Device Tree for V2P-CA15 core tile (TC1 variant)
Date: Mon, 30 Jan 2012 17:42:12 +0000 [thread overview]
Message-ID: <20120130174212.GH2248@linaro.org> (raw)
In-Reply-To: <1327513396.2355.28.camel@hornet.cambridge.arm.com>
On Wed, Jan 25, 2012 at 05:43:16PM +0000, Pawel Moll wrote:
> On Thu, 2012-01-19 at 17:00 +0000, David Vrabel wrote:
> > > Ok, /include/ "skeleton.dtsi" is gone then :-)
> >
> > The problem wasn't with including skeleton.dtsi. With
> > CONFIG_ARM_ATAG_DTB_COMPAT the zImage decompressor modifies the appended
> > DTB using information from the ATAGs (see atags_to_fdt()).
> >
> > If there's an ATAG giving the amount of RAM the DTB's "memory" node is
> > replaced with a new one. Since the vexpress DTBs don't have a "memory"
> > node it's added and the DTB ends up with two nodes describing memory.
>
> As it turned out it was just the "skeleton.dtsi" problem after all - I
> mean the fact that there where two device_type="memory" nodes in the
> tree.
>
> The decompressor's setprop()
> (arch/arm/boot/compressed/atags_to_fdt.c:12) uses libfdt's
> fdt_setprop(), which correctly ignores the "@00000000" component of the
> node name and sets the reg property as expected. So as long as there is
> exactly one "memory[@address]" node in the tree,
> CONFIG_ARM_ATAG_DTB_COMPAT is happy.
>
> I will remove the /include/ from the dts files for VE (see below) in the
> v3.3-rc1 based series.
>
> Thanks for spotting this!
>
> Pawe??
This carries a significant risk of unintended fragmentation and buggy
maintenance. This patch is a good example of the kind of change which
could easily go wrong. (I'm not saying that it is wrong -- just using
it as an example.)
Since we will end up with a significantly large number of device trees
for vexpress, I can foresee that we'll end up with a highly reduncant
set of .dts{,i} files (each of which is often rather internally redundant
too).
Does anyone have a view on whether it's acceptable to generate device
tree sources from another form, instead of having them verbatim in the
kernel tree? This could involve a preprocessor, or something more
heavyweight.
The dts /include/ mechanism solves this problem only for the simplest
of cases.
Cheers
---Dave
>
> diff --git a/arch/arm/boot/dts/vexpress-v2p-ca15-tc1.dts b/arch/arm/boot/dts/vexpress-v2p-ca15-tc1.dts
> index 02cada5..2a690f2 100644
> --- a/arch/arm/boot/dts/vexpress-v2p-ca15-tc1.dts
> +++ b/arch/arm/boot/dts/vexpress-v2p-ca15-tc1.dts
> @@ -9,13 +9,15 @@
>
> /dts-v1/;
>
> -/include/ "skeleton.dtsi"
> -
> / {
> model = "V2P-CA15";
> arm,hbi = <0x237>;
> compatible = "arm,vexpress,v2p-ca15,tc1", "arm,vexpress,v2p-ca15", "arm,vexpress";
> interrupt-parent = <&gic>;
> + #address-cells = <1>;
> + #size-cells = <1>;
> +
> + chosen { };
>
> aliases {
> serial0 = &v2m_serial0;
> diff --git a/arch/arm/boot/dts/vexpress-v2p-ca5s.dts b/arch/arm/boot/dts/vexpress-v2p-ca5s.dts
> index da26a13..d4c5322 100644
> --- a/arch/arm/boot/dts/vexpress-v2p-ca5s.dts
> +++ b/arch/arm/boot/dts/vexpress-v2p-ca5s.dts
> @@ -9,13 +9,15 @@
>
> /dts-v1/;
>
> -/include/ "skeleton.dtsi"
> -
> / {
> model = "V2P-CA5s";
> arm,hbi = <0x225>;
> compatible = "arm,vexpress,v2p-ca5s", "arm,vexpress";
> interrupt-parent = <&gic>;
> + #address-cells = <1>;
> + #size-cells = <1>;
> +
> + chosen { };
>
> aliases {
> serial0 = &v2m_serial0;
> diff --git a/arch/arm/boot/dts/vexpress-v2p-ca9.dts b/arch/arm/boot/dts/vexpress-v2p-ca9.dts
> index 84542e7..5d90ce5 100644
> --- a/arch/arm/boot/dts/vexpress-v2p-ca9.dts
> +++ b/arch/arm/boot/dts/vexpress-v2p-ca9.dts
> @@ -9,13 +9,15 @@
>
> /dts-v1/;
>
> -/include/ "skeleton.dtsi"
> -
> / {
> model = "V2P-CA9";
> arm,hbi = <0x191>;
> compatible = "arm,vexpress,v2p-ca9", "arm,vexpress";
> interrupt-parent = <&gic>;
> + #address-cells = <1>;
> + #size-cells = <1>;
> +
> + chosen { };
>
> aliases {
> serial0 = &v2m_serial0;
>
>
>
>
> _______________________________________________
> linux-arm-kernel mailing list
> linux-arm-kernel at lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
next prev parent reply other threads:[~2012-01-30 17:42 UTC|newest]
Thread overview: 38+ messages / expand[flat|nested] mbox.gz Atom feed top
2011-12-15 14:02 [PATCH v6 0/9] Versatile Express DT support Pawel Moll
2011-12-15 14:02 ` [PATCH v6 1/9] ARM: versatile: Add missing ENDPROC to headsmp.S Pawel Moll
2011-12-15 14:02 ` [PATCH v6 2/9] ARM: vexpress: Get rid of MMIO_P2V Pawel Moll
2011-12-15 14:02 ` [PATCH v6 3/9] ARM: versatile: Map local timers using Device Tree when possible Pawel Moll
2011-12-15 14:53 ` Rob Herring
2011-12-15 15:25 ` Pawel Moll
2011-12-15 17:25 ` Pawel Moll
2011-12-15 14:02 ` [PATCH v6 4/9] ARM: vexpress: Use FDT data in platform SMP calls Pawel Moll
2011-12-15 14:02 ` [PATCH v6 5/9] ARM: vexpress: Add Device Tree support Pawel Moll
2012-01-10 11:13 ` Jon Medhurst (Tixy)
2011-12-15 14:02 ` [PATCH v6 6/9] ARM: vexpress: Motherboard RS1 memory map support Pawel Moll
2012-01-04 16:35 ` David Vrabel
2012-01-19 13:21 ` Pawel Moll
2012-01-19 16:46 ` David Vrabel
2012-01-19 17:31 ` Pawel Moll
2012-01-27 14:02 ` Pawel Moll
2012-01-30 17:32 ` Dave Martin
2012-01-30 17:26 ` Dave Martin
2011-12-15 14:02 ` [PATCH v6 7/9] ARM: vexpress: Add Device Tree for V2P-CA5s core tile Pawel Moll
2011-12-15 14:02 ` [PATCH v6 8/9] ARM: vexpress: Add Device Tree for V2P-CA9 " Pawel Moll
2011-12-15 14:02 ` [PATCH v6 9/9] ARM: vexpress: Add Device Tree for V2P-CA15 core tile (TC1 variant) Pawel Moll
2012-01-10 14:21 ` David Vrabel
2012-01-19 13:27 ` Pawel Moll
2012-01-19 13:34 ` Rob Herring
2012-01-19 13:43 ` Pawel Moll
2012-01-19 14:01 ` Rob Herring
2012-01-19 14:51 ` Pawel Moll
2012-01-19 17:00 ` David Vrabel
2012-01-19 17:11 ` Russell King - ARM Linux
2012-01-19 17:27 ` Pawel Moll
2012-01-19 17:50 ` Russell King - ARM Linux
2012-01-19 17:59 ` Grant Likely
2012-01-19 18:09 ` Nicolas Pitre
2012-01-19 22:07 ` Grant Likely
2012-01-25 17:43 ` Pawel Moll
2012-01-30 17:42 ` Dave Martin [this message]
2012-01-30 21:31 ` Grant Likely
2012-01-31 11:50 ` Dave Martin
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=20120130174212.GH2248@linaro.org \
--to=dave.martin@linaro.org \
--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).