[PATCH 0/7] MIPS: Move device-tree files to a common location

[PATCH 0/7] MIPS: Move device-tree files to a common location

[Andrew Bresticker]

To be consistent with other architectures and to avoid unnecessary
makefile duplication, move all MIPS device-trees to arch/mips/boot/dts
and build them with a common makefile.

Patch 1 sets up the makefiles for building the DTs in arch/mips/boot/dts
and introduces the config option BUILTIN_DTB for platforms that require
it.

Patch 2 introduces the 'dtbs' makefile target to allow building of just
the DT binaries.

Patches 3-7 move the DTs out of the platform directores.

I've build tested this on all affected platforms (Octeon, Lantiq, SEAD3,
Netlogic, and Ralink) as well as Malta.  For platforms where builtin DTBs
are optional (Netlogic and Ralink), I built with and without the builtin
DTBs.

Based on 3.17-rc1.

Andrew Bresticker (7):
  MIPS: Create common infrastructure for building built-in device-trees
  MIPS: Add support for building device-tree binaries
  MIPS: Octeon: Move device-trees to arch/mips/boot/dts/
  MIPS: Lantiq: Move device-trees to arch/mips/boot/dts/
  MIPS: sead3: Move device-trees to arch/mips/boot/dts/
  MIPS: Netlogic: Move device-trees to arch/mips/boot/dts/
  MIPS: ralink: Move device-trees to arch/mips/boot/dts/

 arch/mips/Kconfig                                    |  5 +++++
 arch/mips/Makefile                                   | 11 +++++++++++
 arch/mips/boot/.gitignore                            |  1 +
 arch/mips/boot/dts/Makefile                          | 20 ++++++++++++++++++++
 arch/mips/{lantiq => boot}/dts/danube.dtsi           |  0
 arch/mips/{lantiq => boot}/dts/easy50712.dts         |  0
 arch/mips/{ralink => boot}/dts/mt7620a.dtsi          |  0
 arch/mips/{ralink => boot}/dts/mt7620a_eval.dts      |  0
 .../mips/{cavium-octeon => boot/dts}/octeon_3xxx.dts |  0
 .../mips/{cavium-octeon => boot/dts}/octeon_68xx.dts |  0
 arch/mips/{ralink => boot}/dts/rt2880.dtsi           |  0
 arch/mips/{ralink => boot}/dts/rt2880_eval.dts       |  0
 arch/mips/{ralink => boot}/dts/rt3050.dtsi           |  0
 arch/mips/{ralink => boot}/dts/rt3052_eval.dts       |  0
 arch/mips/{ralink => boot}/dts/rt3883.dtsi           |  0
 arch/mips/{ralink => boot}/dts/rt3883_eval.dts       |  0
 arch/mips/{mti-sead3 => boot/dts}/sead3.dts          |  0
 arch/mips/{netlogic => boot}/dts/xlp_evp.dts         |  0
 arch/mips/{netlogic => boot}/dts/xlp_fvp.dts         |  0
 arch/mips/{netlogic => boot}/dts/xlp_gvp.dts         |  0
 arch/mips/{netlogic => boot}/dts/xlp_svp.dts         |  0
 arch/mips/cavium-octeon/.gitignore                   |  2 --
 arch/mips/cavium-octeon/Makefile                     | 10 ----------
 arch/mips/lantiq/Kconfig                             |  1 +
 arch/mips/lantiq/Makefile                            |  2 --
 arch/mips/lantiq/dts/Makefile                        |  1 -
 arch/mips/mti-sead3/Makefile                         |  4 ----
 arch/mips/netlogic/Kconfig                           |  4 ++++
 arch/mips/netlogic/Makefile                          |  1 -
 arch/mips/netlogic/dts/Makefile                      |  4 ----
 arch/mips/ralink/Kconfig                             |  4 ++++
 arch/mips/ralink/Makefile                            |  2 --
 arch/mips/ralink/dts/Makefile                        |  4 ----
 33 files changed, 46 insertions(+), 30 deletions(-)
 create mode 100644 arch/mips/boot/dts/Makefile
 rename arch/mips/{lantiq => boot}/dts/danube.dtsi (100%)
 rename arch/mips/{lantiq => boot}/dts/easy50712.dts (100%)
 rename arch/mips/{ralink => boot}/dts/mt7620a.dtsi (100%)
 rename arch/mips/{ralink => boot}/dts/mt7620a_eval.dts (100%)
 rename arch/mips/{cavium-octeon => boot/dts}/octeon_3xxx.dts (100%)
 rename arch/mips/{cavium-octeon => boot/dts}/octeon_68xx.dts (100%)
 rename arch/mips/{ralink => boot}/dts/rt2880.dtsi (100%)
 rename arch/mips/{ralink => boot}/dts/rt2880_eval.dts (100%)
 rename arch/mips/{ralink => boot}/dts/rt3050.dtsi (100%)
 rename arch/mips/{ralink => boot}/dts/rt3052_eval.dts (100%)
 rename arch/mips/{ralink => boot}/dts/rt3883.dtsi (100%)
 rename arch/mips/{ralink => boot}/dts/rt3883_eval.dts (100%)
 rename arch/mips/{mti-sead3 => boot/dts}/sead3.dts (100%)
 rename arch/mips/{netlogic => boot}/dts/xlp_evp.dts (100%)
 rename arch/mips/{netlogic => boot}/dts/xlp_fvp.dts (100%)
 rename arch/mips/{netlogic => boot}/dts/xlp_gvp.dts (100%)
 rename arch/mips/{netlogic => boot}/dts/xlp_svp.dts (100%)
 delete mode 100644 arch/mips/cavium-octeon/.gitignore
 delete mode 100644 arch/mips/lantiq/dts/Makefile
 delete mode 100644 arch/mips/netlogic/dts/Makefile
 delete mode 100644 arch/mips/ralink/dts/Makefile

-- 
2.1.0.rc2.206.gedb03e5

[PATCH 0/7] MIPS: Move device-tree files to a common location

[Andrew Bresticker]

To be consistent with other architectures and to avoid unnecessary
makefile duplication, move all MIPS device-trees to arch/mips/boot/dts
and build them with a common makefile.

Patch 1 sets up the makefiles for building the DTs in arch/mips/boot/dts
and introduces the config option BUILTIN_DTB for platforms that require
it.

Patch 2 introduces the 'dtbs' makefile target to allow building of just
the DT binaries.

Patches 3-7 move the DTs out of the platform directores.

I've build tested this on all affected platforms (Octeon, Lantiq, SEAD3,
Netlogic, and Ralink) as well as Malta.  For platforms where builtin DTBs
are optional (Netlogic and Ralink), I built with and without the builtin
DTBs.

Based on 3.17-rc1.

Andrew Bresticker (7):
  MIPS: Create common infrastructure for building built-in device-trees
  MIPS: Add support for building device-tree binaries
  MIPS: Octeon: Move device-trees to arch/mips/boot/dts/
  MIPS: Lantiq: Move device-trees to arch/mips/boot/dts/
  MIPS: sead3: Move device-trees to arch/mips/boot/dts/
  MIPS: Netlogic: Move device-trees to arch/mips/boot/dts/
  MIPS: ralink: Move device-trees to arch/mips/boot/dts/

 arch/mips/Kconfig                                    |  5 +++++
 arch/mips/Makefile                                   | 11 +++++++++++
 arch/mips/boot/.gitignore                            |  1 +
 arch/mips/boot/dts/Makefile                          | 20 ++++++++++++++++++++
 arch/mips/{lantiq => boot}/dts/danube.dtsi           |  0
 arch/mips/{lantiq => boot}/dts/easy50712.dts         |  0
 arch/mips/{ralink => boot}/dts/mt7620a.dtsi          |  0
 arch/mips/{ralink => boot}/dts/mt7620a_eval.dts      |  0
 .../mips/{cavium-octeon => boot/dts}/octeon_3xxx.dts |  0
 .../mips/{cavium-octeon => boot/dts}/octeon_68xx.dts |  0
 arch/mips/{ralink => boot}/dts/rt2880.dtsi           |  0
 arch/mips/{ralink => boot}/dts/rt2880_eval.dts       |  0
 arch/mips/{ralink => boot}/dts/rt3050.dtsi           |  0
 arch/mips/{ralink => boot}/dts/rt3052_eval.dts       |  0
 arch/mips/{ralink => boot}/dts/rt3883.dtsi           |  0
 arch/mips/{ralink => boot}/dts/rt3883_eval.dts       |  0
 arch/mips/{mti-sead3 => boot/dts}/sead3.dts          |  0
 arch/mips/{netlogic => boot}/dts/xlp_evp.dts         |  0
 arch/mips/{netlogic => boot}/dts/xlp_fvp.dts         |  0
 arch/mips/{netlogic => boot}/dts/xlp_gvp.dts         |  0
 arch/mips/{netlogic => boot}/dts/xlp_svp.dts         |  0
 arch/mips/cavium-octeon/.gitignore                   |  2 --
 arch/mips/cavium-octeon/Makefile                     | 10 ----------
 arch/mips/lantiq/Kconfig                             |  1 +
 arch/mips/lantiq/Makefile                            |  2 --
 arch/mips/lantiq/dts/Makefile                        |  1 -
 arch/mips/mti-sead3/Makefile                         |  4 ----
 arch/mips/netlogic/Kconfig                           |  4 ++++
 arch/mips/netlogic/Makefile                          |  1 -
 arch/mips/netlogic/dts/Makefile                      |  4 ----
 arch/mips/ralink/Kconfig                             |  4 ++++
 arch/mips/ralink/Makefile                            |  2 --
 arch/mips/ralink/dts/Makefile                        |  4 ----
 33 files changed, 46 insertions(+), 30 deletions(-)
 create mode 100644 arch/mips/boot/dts/Makefile
 rename arch/mips/{lantiq => boot}/dts/danube.dtsi (100%)
 rename arch/mips/{lantiq => boot}/dts/easy50712.dts (100%)
 rename arch/mips/{ralink => boot}/dts/mt7620a.dtsi (100%)
 rename arch/mips/{ralink => boot}/dts/mt7620a_eval.dts (100%)
 rename arch/mips/{cavium-octeon => boot/dts}/octeon_3xxx.dts (100%)
 rename arch/mips/{cavium-octeon => boot/dts}/octeon_68xx.dts (100%)
 rename arch/mips/{ralink => boot}/dts/rt2880.dtsi (100%)
 rename arch/mips/{ralink => boot}/dts/rt2880_eval.dts (100%)
 rename arch/mips/{ralink => boot}/dts/rt3050.dtsi (100%)
 rename arch/mips/{ralink => boot}/dts/rt3052_eval.dts (100%)
 rename arch/mips/{ralink => boot}/dts/rt3883.dtsi (100%)
 rename arch/mips/{ralink => boot}/dts/rt3883_eval.dts (100%)
 rename arch/mips/{mti-sead3 => boot/dts}/sead3.dts (100%)
 rename arch/mips/{netlogic => boot}/dts/xlp_evp.dts (100%)
 rename arch/mips/{netlogic => boot}/dts/xlp_fvp.dts (100%)
 rename arch/mips/{netlogic => boot}/dts/xlp_gvp.dts (100%)
 rename arch/mips/{netlogic => boot}/dts/xlp_svp.dts (100%)
 delete mode 100644 arch/mips/cavium-octeon/.gitignore
 delete mode 100644 arch/mips/lantiq/dts/Makefile
 delete mode 100644 arch/mips/netlogic/dts/Makefile
 delete mode 100644 arch/mips/ralink/dts/Makefile

-- 
2.1.0.rc2.206.gedb03e5

--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH 1/7] MIPS: Create common infrastructure for building built-in device-trees

[Andrew Bresticker]

In preparation for moving the device-trees to a common location,
introduce the config option BUILTIN_DTB, which can be selected by
platforms that use a device-tree built into the kernel image, and
create a Makefile to build the device-trees in arch/mips/boot/dts/.

Signed-off-by: Andrew Bresticker <abrestic@chromium.org>
---
 arch/mips/Kconfig           | 3 +++
 arch/mips/Makefile          | 6 ++++++
 arch/mips/boot/dts/Makefile | 3 +++
 3 files changed, 12 insertions(+)
 create mode 100644 arch/mips/boot/dts/Makefile

diff --git a/arch/mips/Kconfig b/arch/mips/Kconfig
index df51e78..19b8aac 100644
--- a/arch/mips/Kconfig
+++ b/arch/mips/Kconfig
@@ -2481,6 +2481,9 @@ config USE_OF
 	select OF_EARLY_FLATTREE
 	select IRQ_DOMAIN
 
+config BUILTIN_DTB
+	bool
+
 endmenu
 
 config LOCKDEP_SUPPORT
diff --git a/arch/mips/Makefile b/arch/mips/Makefile
index 9336509..72cdd6a 100644
--- a/arch/mips/Makefile
+++ b/arch/mips/Makefile
@@ -324,6 +324,12 @@ endif
 
 CLEAN_FILES += vmlinux.32 vmlinux.64
 
+# device-trees
+core-$(CONFIG_BUILTIN_DTB) += arch/mips/boot/dts/
+
+%.dtb %.dtb.S %.dtb.o: | scripts
+	$(Q)$(MAKE) $(build)=arch/mips/boot/dts arch/mips/boot/dts/$@
+
 archprepare:
 ifdef CONFIG_MIPS32_N32
 	@echo '  Checking missing-syscalls for N32'
diff --git a/arch/mips/boot/dts/Makefile b/arch/mips/boot/dts/Makefile
new file mode 100644
index 0000000..6bb41df
--- /dev/null
+++ b/arch/mips/boot/dts/Makefile
@@ -0,0 +1,3 @@
+obj-y		+= $(patsubst %.dtb, %.dtb.o, $(dtb-y))
+
+clean-files	+= *.dtb.S
-- 
2.1.0.rc2.206.gedb03e5

[PATCH 2/7] MIPS: Add support for building device-tree binaries

[Andrew Bresticker]

Add a 'dtbs' Makefile target that just builds the device-tree binaries
enabled by the configuration.

Signed-off-by: Andrew Bresticker <abrestic@chromium.org>
---
 arch/mips/Makefile          | 5 +++++
 arch/mips/boot/.gitignore   | 1 +
 arch/mips/boot/dts/Makefile | 7 ++++++-
 3 files changed, 12 insertions(+), 1 deletion(-)

diff --git a/arch/mips/Makefile b/arch/mips/Makefile
index 72cdd6a..26672e1 100644
--- a/arch/mips/Makefile
+++ b/arch/mips/Makefile
@@ -330,6 +330,10 @@ core-$(CONFIG_BUILTIN_DTB) += arch/mips/boot/dts/
 %.dtb %.dtb.S %.dtb.o: | scripts
 	$(Q)$(MAKE) $(build)=arch/mips/boot/dts arch/mips/boot/dts/$@
 
+PHONY += dtbs
+dtbs: scripts
+	$(Q)$(MAKE) $(build)=arch/mips/boot/dts dtbs
+
 archprepare:
 ifdef CONFIG_MIPS32_N32
 	@echo '  Checking missing-syscalls for N32'
@@ -364,6 +368,7 @@ define archhelp
 	echo '  vmlinuz.srec         - SREC zboot image'
 	echo '  uImage               - U-Boot image'
 	echo '  uImage.gz            - U-Boot image (gzip)'
+	echo '  dtbs                 - Device-tree blobs for enabled boards'
 	echo
 	echo '  These will be default as appropriate for a configured platform.'
 endef
diff --git a/arch/mips/boot/.gitignore b/arch/mips/boot/.gitignore
index a73d6e2..d3962cd 100644
--- a/arch/mips/boot/.gitignore
+++ b/arch/mips/boot/.gitignore
@@ -5,3 +5,4 @@ zImage
 zImage.tmp
 calc_vmlinuz_load_addr
 uImage
+*.dtb
diff --git a/arch/mips/boot/dts/Makefile b/arch/mips/boot/dts/Makefile
index 6bb41df..9b3da1f 100644
--- a/arch/mips/boot/dts/Makefile
+++ b/arch/mips/boot/dts/Makefile
@@ -1,3 +1,8 @@
 obj-y		+= $(patsubst %.dtb, %.dtb.o, $(dtb-y))
 
-clean-files	+= *.dtb.S
+targets		+= dtbs
+targets		+= $(dtb-y)
+
+dtbs: $(addprefix $(obj)/, $(dtb-y))
+
+clean-files	+= *.dtb *.dtb.S
-- 
2.1.0.rc2.206.gedb03e5

[PATCH 2/7] MIPS: Add support for building device-tree binaries

[Andrew Bresticker]

Add a 'dtbs' Makefile target that just builds the device-tree binaries
enabled by the configuration.

Signed-off-by: Andrew Bresticker <abrestic-F7+t8E8rja9g9hUCZPvPmw@public.gmane.org>
---
 arch/mips/Makefile          | 5 +++++
 arch/mips/boot/.gitignore   | 1 +
 arch/mips/boot/dts/Makefile | 7 ++++++-
 3 files changed, 12 insertions(+), 1 deletion(-)

diff --git a/arch/mips/Makefile b/arch/mips/Makefile
index 72cdd6a..26672e1 100644
--- a/arch/mips/Makefile
+++ b/arch/mips/Makefile
@@ -330,6 +330,10 @@ core-$(CONFIG_BUILTIN_DTB) += arch/mips/boot/dts/
 %.dtb %.dtb.S %.dtb.o: | scripts
 	$(Q)$(MAKE) $(build)=arch/mips/boot/dts arch/mips/boot/dts/$@
 
+PHONY += dtbs
+dtbs: scripts
+	$(Q)$(MAKE) $(build)=arch/mips/boot/dts dtbs
+
 archprepare:
 ifdef CONFIG_MIPS32_N32
 	@echo '  Checking missing-syscalls for N32'
@@ -364,6 +368,7 @@ define archhelp
 	echo '  vmlinuz.srec         - SREC zboot image'
 	echo '  uImage               - U-Boot image'
 	echo '  uImage.gz            - U-Boot image (gzip)'
+	echo '  dtbs                 - Device-tree blobs for enabled boards'
 	echo
 	echo '  These will be default as appropriate for a configured platform.'
 endef
diff --git a/arch/mips/boot/.gitignore b/arch/mips/boot/.gitignore
index a73d6e2..d3962cd 100644
--- a/arch/mips/boot/.gitignore
+++ b/arch/mips/boot/.gitignore
@@ -5,3 +5,4 @@ zImage
 zImage.tmp
 calc_vmlinuz_load_addr
 uImage
+*.dtb
diff --git a/arch/mips/boot/dts/Makefile b/arch/mips/boot/dts/Makefile
index 6bb41df..9b3da1f 100644
--- a/arch/mips/boot/dts/Makefile
+++ b/arch/mips/boot/dts/Makefile
@@ -1,3 +1,8 @@
 obj-y		+= $(patsubst %.dtb, %.dtb.o, $(dtb-y))
 
-clean-files	+= *.dtb.S
+targets		+= dtbs
+targets		+= $(dtb-y)
+
+dtbs: $(addprefix $(obj)/, $(dtb-y))
+
+clean-files	+= *.dtb *.dtb.S
-- 
2.1.0.rc2.206.gedb03e5

--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH 3/7] MIPS: Octeon: Move device-trees to arch/mips/boot/dts/

[Andrew Bresticker]

Move the Octeon device-trees to arch/mips/boot/dts/ and update the
Makefiles accordingly.  Since Octeon requires the device-tree to be
built into the kernel, select BUILTIN_DTB as well.

Signed-off-by: Andrew Bresticker <abrestic@chromium.org>
---
 arch/mips/Kconfig                                     |  1 +
 arch/mips/boot/dts/Makefile                           |  2 ++
 arch/mips/{cavium-octeon => boot/dts}/octeon_3xxx.dts |  0
 arch/mips/{cavium-octeon => boot/dts}/octeon_68xx.dts |  0
 arch/mips/cavium-octeon/.gitignore                    |  2 --
 arch/mips/cavium-octeon/Makefile                      | 10 ----------
 6 files changed, 3 insertions(+), 12 deletions(-)
 rename arch/mips/{cavium-octeon => boot/dts}/octeon_3xxx.dts (100%)
 rename arch/mips/{cavium-octeon => boot/dts}/octeon_68xx.dts (100%)
 delete mode 100644 arch/mips/cavium-octeon/.gitignore

diff --git a/arch/mips/Kconfig b/arch/mips/Kconfig
index 19b8aac..dbfcf35 100644
--- a/arch/mips/Kconfig
+++ b/arch/mips/Kconfig
@@ -741,6 +741,7 @@ config CAVIUM_OCTEON_SOC
 	select ARCH_SPARSEMEM_ENABLE
 	select SYS_SUPPORTS_SMP
 	select NR_CPUS_DEFAULT_16
+	select BUILTIN_DTB
 	help
 	  This option supports all of the Octeon reference boards from Cavium
 	  Networks. It builds a kernel that dynamically determines the Octeon
diff --git a/arch/mips/boot/dts/Makefile b/arch/mips/boot/dts/Makefile
index 9b3da1f..51acad6 100644
--- a/arch/mips/boot/dts/Makefile
+++ b/arch/mips/boot/dts/Makefile
@@ -1,3 +1,5 @@
+dtb-$(CONFIG_CAVIUM_OCTEON_SOC)		+= octeon_3xxx.dtb octeon_68xx.dtb
+
 obj-y		+= $(patsubst %.dtb, %.dtb.o, $(dtb-y))
 
 targets		+= dtbs
diff --git a/arch/mips/cavium-octeon/octeon_3xxx.dts b/arch/mips/boot/dts/octeon_3xxx.dts
similarity index 100%
rename from arch/mips/cavium-octeon/octeon_3xxx.dts
rename to arch/mips/boot/dts/octeon_3xxx.dts
diff --git a/arch/mips/cavium-octeon/octeon_68xx.dts b/arch/mips/boot/dts/octeon_68xx.dts
similarity index 100%
rename from arch/mips/cavium-octeon/octeon_68xx.dts
rename to arch/mips/boot/dts/octeon_68xx.dts
diff --git a/arch/mips/cavium-octeon/.gitignore b/arch/mips/cavium-octeon/.gitignore
deleted file mode 100644
index 39c9686..0000000
--- a/arch/mips/cavium-octeon/.gitignore
+++ /dev/null
@@ -1,2 +0,0 @@
-*.dtb.S
-*.dtb
diff --git a/arch/mips/cavium-octeon/Makefile b/arch/mips/cavium-octeon/Makefile
index 4e95204..42f5f1a 100644
--- a/arch/mips/cavium-octeon/Makefile
+++ b/arch/mips/cavium-octeon/Makefile
@@ -20,13 +20,3 @@ obj-y += executive/
 obj-$(CONFIG_MTD)		      += flash_setup.o
 obj-$(CONFIG_SMP)		      += smp.o
 obj-$(CONFIG_OCTEON_ILM)	      += oct_ilm.o
-
-DTS_FILES = octeon_3xxx.dts octeon_68xx.dts
-DTB_FILES = $(patsubst %.dts, %.dtb, $(DTS_FILES))
-
-obj-y += $(patsubst %.dts, %.dtb.o, $(DTS_FILES))
-
-# Let's keep the .dtb files around in case we want to look at them.
-.SECONDARY:  $(addprefix $(obj)/, $(DTB_FILES))
-
-clean-files += $(DTB_FILES) $(patsubst %.dtb, %.dtb.S, $(DTB_FILES))
-- 
2.1.0.rc2.206.gedb03e5

[PATCH 4/7] MIPS: Lantiq: Move device-trees to arch/mips/boot/dts/

[Andrew Bresticker]

Move the Lantiq device-trees to arch/mips/boot/dts/ and update the
Makefiles accordingly.  There is currently only a single Lantiq
device-tree (EASY50712), and it's required to be built into the kernel,
so select BUILTIN_DTB for it.

Signed-off-by: Andrew Bresticker <abrestic@chromium.org>
---
 arch/mips/boot/dts/Makefile                  | 1 +
 arch/mips/{lantiq => boot}/dts/danube.dtsi   | 0
 arch/mips/{lantiq => boot}/dts/easy50712.dts | 0
 arch/mips/lantiq/Kconfig                     | 1 +
 arch/mips/lantiq/Makefile                    | 2 --
 arch/mips/lantiq/dts/Makefile                | 1 -
 6 files changed, 2 insertions(+), 3 deletions(-)
 rename arch/mips/{lantiq => boot}/dts/danube.dtsi (100%)
 rename arch/mips/{lantiq => boot}/dts/easy50712.dts (100%)
 delete mode 100644 arch/mips/lantiq/dts/Makefile

diff --git a/arch/mips/boot/dts/Makefile b/arch/mips/boot/dts/Makefile
index 51acad6..4f265ec 100644
--- a/arch/mips/boot/dts/Makefile
+++ b/arch/mips/boot/dts/Makefile
@@ -1,4 +1,5 @@
 dtb-$(CONFIG_CAVIUM_OCTEON_SOC)		+= octeon_3xxx.dtb octeon_68xx.dtb
+dtb-$(CONFIG_DT_EASY50712)		+= easy50712.dtb
 
 obj-y		+= $(patsubst %.dtb, %.dtb.o, $(dtb-y))
 
diff --git a/arch/mips/lantiq/dts/danube.dtsi b/arch/mips/boot/dts/danube.dtsi
similarity index 100%
rename from arch/mips/lantiq/dts/danube.dtsi
rename to arch/mips/boot/dts/danube.dtsi
diff --git a/arch/mips/lantiq/dts/easy50712.dts b/arch/mips/boot/dts/easy50712.dts
similarity index 100%
rename from arch/mips/lantiq/dts/easy50712.dts
rename to arch/mips/boot/dts/easy50712.dts
diff --git a/arch/mips/lantiq/Kconfig b/arch/mips/lantiq/Kconfig
index c002191..e10d333 100644
--- a/arch/mips/lantiq/Kconfig
+++ b/arch/mips/lantiq/Kconfig
@@ -30,6 +30,7 @@ choice
 config DT_EASY50712
 	bool "Easy50712"
 	depends on SOC_XWAY
+	select BUILTIN_DTB
 endchoice
 
 config PCI_LANTIQ
diff --git a/arch/mips/lantiq/Makefile b/arch/mips/lantiq/Makefile
index d6bdc57..690257a 100644
--- a/arch/mips/lantiq/Makefile
+++ b/arch/mips/lantiq/Makefile
@@ -6,8 +6,6 @@
 
 obj-y := irq.o clk.o prom.o
 
-obj-y += dts/
-
 obj-$(CONFIG_EARLY_PRINTK) += early_printk.o
 
 obj-$(CONFIG_SOC_TYPE_XWAY) += xway/
diff --git a/arch/mips/lantiq/dts/Makefile b/arch/mips/lantiq/dts/Makefile
deleted file mode 100644
index 6fa72dd..0000000
--- a/arch/mips/lantiq/dts/Makefile
+++ /dev/null
@@ -1 +0,0 @@
-obj-$(CONFIG_DT_EASY50712) := easy50712.dtb.o
-- 
2.1.0.rc2.206.gedb03e5

[PATCH 4/7] MIPS: Lantiq: Move device-trees to arch/mips/boot/dts/

[Andrew Bresticker]

Move the Lantiq device-trees to arch/mips/boot/dts/ and update the
Makefiles accordingly.  There is currently only a single Lantiq
device-tree (EASY50712), and it's required to be built into the kernel,
so select BUILTIN_DTB for it.

Signed-off-by: Andrew Bresticker <abrestic-F7+t8E8rja9g9hUCZPvPmw@public.gmane.org>
---
 arch/mips/boot/dts/Makefile                  | 1 +
 arch/mips/{lantiq => boot}/dts/danube.dtsi   | 0
 arch/mips/{lantiq => boot}/dts/easy50712.dts | 0
 arch/mips/lantiq/Kconfig                     | 1 +
 arch/mips/lantiq/Makefile                    | 2 --
 arch/mips/lantiq/dts/Makefile                | 1 -
 6 files changed, 2 insertions(+), 3 deletions(-)
 rename arch/mips/{lantiq => boot}/dts/danube.dtsi (100%)
 rename arch/mips/{lantiq => boot}/dts/easy50712.dts (100%)
 delete mode 100644 arch/mips/lantiq/dts/Makefile

diff --git a/arch/mips/boot/dts/Makefile b/arch/mips/boot/dts/Makefile
index 51acad6..4f265ec 100644
--- a/arch/mips/boot/dts/Makefile
+++ b/arch/mips/boot/dts/Makefile
@@ -1,4 +1,5 @@
 dtb-$(CONFIG_CAVIUM_OCTEON_SOC)		+= octeon_3xxx.dtb octeon_68xx.dtb
+dtb-$(CONFIG_DT_EASY50712)		+= easy50712.dtb
 
 obj-y		+= $(patsubst %.dtb, %.dtb.o, $(dtb-y))
 
diff --git a/arch/mips/lantiq/dts/danube.dtsi b/arch/mips/boot/dts/danube.dtsi
similarity index 100%
rename from arch/mips/lantiq/dts/danube.dtsi
rename to arch/mips/boot/dts/danube.dtsi
diff --git a/arch/mips/lantiq/dts/easy50712.dts b/arch/mips/boot/dts/easy50712.dts
similarity index 100%
rename from arch/mips/lantiq/dts/easy50712.dts
rename to arch/mips/boot/dts/easy50712.dts
diff --git a/arch/mips/lantiq/Kconfig b/arch/mips/lantiq/Kconfig
index c002191..e10d333 100644
--- a/arch/mips/lantiq/Kconfig
+++ b/arch/mips/lantiq/Kconfig
@@ -30,6 +30,7 @@ choice
 config DT_EASY50712
 	bool "Easy50712"
 	depends on SOC_XWAY
+	select BUILTIN_DTB
 endchoice
 
 config PCI_LANTIQ
diff --git a/arch/mips/lantiq/Makefile b/arch/mips/lantiq/Makefile
index d6bdc57..690257a 100644
--- a/arch/mips/lantiq/Makefile
+++ b/arch/mips/lantiq/Makefile
@@ -6,8 +6,6 @@
 
 obj-y := irq.o clk.o prom.o
 
-obj-y += dts/
-
 obj-$(CONFIG_EARLY_PRINTK) += early_printk.o
 
 obj-$(CONFIG_SOC_TYPE_XWAY) += xway/
diff --git a/arch/mips/lantiq/dts/Makefile b/arch/mips/lantiq/dts/Makefile
deleted file mode 100644
index 6fa72dd..0000000
--- a/arch/mips/lantiq/dts/Makefile
+++ /dev/null
@@ -1 +0,0 @@
-obj-$(CONFIG_DT_EASY50712) := easy50712.dtb.o
-- 
2.1.0.rc2.206.gedb03e5

--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH 5/7] MIPS: sead3: Move device-trees to arch/mips/boot/dts/

[Andrew Bresticker]

Move the SEAD-3 device-tree to arch/mips/boot/dts/ and update the
Makefiles accordingly.  Since SEAD-3 requires the device-tree to be
built into the kernel, select BUILTIN_DTB when building for SEAD-3.

Signed-off-by: Andrew Bresticker <abrestic@chromium.org>
---
 arch/mips/Kconfig                           | 1 +
 arch/mips/boot/dts/Makefile                 | 1 +
 arch/mips/{mti-sead3 => boot/dts}/sead3.dts | 0
 arch/mips/mti-sead3/Makefile                | 4 ----
 4 files changed, 2 insertions(+), 4 deletions(-)
 rename arch/mips/{mti-sead3 => boot/dts}/sead3.dts (100%)

diff --git a/arch/mips/Kconfig b/arch/mips/Kconfig
index dbfcf35..a72c7c9 100644
--- a/arch/mips/Kconfig
+++ b/arch/mips/Kconfig
@@ -353,6 +353,7 @@ config MIPS_SEAD3
 	bool "MIPS SEAD3 board"
 	select BOOT_ELF32
 	select BOOT_RAW
+	select BUILTIN_DTB
 	select CEVT_R4K
 	select CSRC_R4K
 	select CSRC_GIC
diff --git a/arch/mips/boot/dts/Makefile b/arch/mips/boot/dts/Makefile
index 4f265ec..8df3d3e 100644
--- a/arch/mips/boot/dts/Makefile
+++ b/arch/mips/boot/dts/Makefile
@@ -1,5 +1,6 @@
 dtb-$(CONFIG_CAVIUM_OCTEON_SOC)		+= octeon_3xxx.dtb octeon_68xx.dtb
 dtb-$(CONFIG_DT_EASY50712)		+= easy50712.dtb
+dtb-$(CONFIG_MIPS_SEAD3)		+= sead3.dtb
 
 obj-y		+= $(patsubst %.dtb, %.dtb.o, $(dtb-y))
 
diff --git a/arch/mips/mti-sead3/sead3.dts b/arch/mips/boot/dts/sead3.dts
similarity index 100%
rename from arch/mips/mti-sead3/sead3.dts
rename to arch/mips/boot/dts/sead3.dts
diff --git a/arch/mips/mti-sead3/Makefile b/arch/mips/mti-sead3/Makefile
index 071786f..febf433 100644
--- a/arch/mips/mti-sead3/Makefile
+++ b/arch/mips/mti-sead3/Makefile
@@ -19,9 +19,5 @@ obj-y				+= sead3-i2c-dev.o sead3-i2c.o \
 
 obj-$(CONFIG_EARLY_PRINTK)	+= sead3-console.o
 obj-$(CONFIG_USB_EHCI_HCD)	+= sead3-ehci.o
-obj-$(CONFIG_OF)		+= sead3.dtb.o
 
 CFLAGS_sead3-setup.o = -I$(src)/../../../scripts/dtc/libfdt
-
-$(obj)/%.dtb: $(obj)/%.dts
-	$(call if_changed,dtc)
-- 
2.1.0.rc2.206.gedb03e5

[PATCH 6/7] MIPS: Netlogic: Move device-trees to arch/mips/boot/dts/

[Andrew Bresticker]

Move the Netlogic XLP device-trees to arch/mips/boot/dts/ and update the
Makefiles accordingly.  A built-in device-tree is optional, so select
BUILTIN_DTB when it is requested.

Signed-off-by: Andrew Bresticker <abrestic@chromium.org>
---
 arch/mips/boot/dts/Makefile                  | 4 ++++
 arch/mips/{netlogic => boot}/dts/xlp_evp.dts | 0
 arch/mips/{netlogic => boot}/dts/xlp_fvp.dts | 0
 arch/mips/{netlogic => boot}/dts/xlp_gvp.dts | 0
 arch/mips/{netlogic => boot}/dts/xlp_svp.dts | 0
 arch/mips/netlogic/Kconfig                   | 4 ++++
 arch/mips/netlogic/Makefile                  | 1 -
 arch/mips/netlogic/dts/Makefile              | 4 ----
 8 files changed, 8 insertions(+), 5 deletions(-)
 rename arch/mips/{netlogic => boot}/dts/xlp_evp.dts (100%)
 rename arch/mips/{netlogic => boot}/dts/xlp_fvp.dts (100%)
 rename arch/mips/{netlogic => boot}/dts/xlp_gvp.dts (100%)
 rename arch/mips/{netlogic => boot}/dts/xlp_svp.dts (100%)
 delete mode 100644 arch/mips/netlogic/dts/Makefile

diff --git a/arch/mips/boot/dts/Makefile b/arch/mips/boot/dts/Makefile
index 8df3d3e..1638a38 100644
--- a/arch/mips/boot/dts/Makefile
+++ b/arch/mips/boot/dts/Makefile
@@ -1,5 +1,9 @@
 dtb-$(CONFIG_CAVIUM_OCTEON_SOC)		+= octeon_3xxx.dtb octeon_68xx.dtb
 dtb-$(CONFIG_DT_EASY50712)		+= easy50712.dtb
+dtb-$(CONFIG_DT_XLP_EVP)		+= xlp_evp.dtb
+dtb-$(CONFIG_DT_XLP_SVP)		+= xlp_svp.dtb
+dtb-$(CONFIG_DT_XLP_FVP)		+= xlp_fvp.dtb
+dtb-$(CONFIG_DT_XLP_GVP)		+= xlp_gvp.dtb
 dtb-$(CONFIG_MIPS_SEAD3)		+= sead3.dtb
 
 obj-y		+= $(patsubst %.dtb, %.dtb.o, $(dtb-y))
diff --git a/arch/mips/netlogic/dts/xlp_evp.dts b/arch/mips/boot/dts/xlp_evp.dts
similarity index 100%
rename from arch/mips/netlogic/dts/xlp_evp.dts
rename to arch/mips/boot/dts/xlp_evp.dts
diff --git a/arch/mips/netlogic/dts/xlp_fvp.dts b/arch/mips/boot/dts/xlp_fvp.dts
similarity index 100%
rename from arch/mips/netlogic/dts/xlp_fvp.dts
rename to arch/mips/boot/dts/xlp_fvp.dts
diff --git a/arch/mips/netlogic/dts/xlp_gvp.dts b/arch/mips/boot/dts/xlp_gvp.dts
similarity index 100%
rename from arch/mips/netlogic/dts/xlp_gvp.dts
rename to arch/mips/boot/dts/xlp_gvp.dts
diff --git a/arch/mips/netlogic/dts/xlp_svp.dts b/arch/mips/boot/dts/xlp_svp.dts
similarity index 100%
rename from arch/mips/netlogic/dts/xlp_svp.dts
rename to arch/mips/boot/dts/xlp_svp.dts
diff --git a/arch/mips/netlogic/Kconfig b/arch/mips/netlogic/Kconfig
index 4eb683a..0823321 100644
--- a/arch/mips/netlogic/Kconfig
+++ b/arch/mips/netlogic/Kconfig
@@ -4,6 +4,7 @@ if NLM_XLP_BOARD
 config DT_XLP_EVP
 	bool "Built-in device tree for XLP EVP boards"
 	default y
+	select BUILTIN_DTB
 	help
 	  Add an FDT blob for XLP EVP boards into the kernel.
 	  This DTB will be used if the firmware does not pass in a DTB
@@ -13,6 +14,7 @@ config DT_XLP_EVP
 config DT_XLP_SVP
 	bool "Built-in device tree for XLP SVP boards"
 	default y
+	select BUILTIN_DTB
 	help
 	  Add an FDT blob for XLP VP boards into the kernel.
 	  This DTB will be used if the firmware does not pass in a DTB
@@ -22,6 +24,7 @@ config DT_XLP_SVP
 config DT_XLP_FVP
 	bool "Built-in device tree for XLP FVP boards"
 	default y
+	select BUILTIN_DTB
 	help
 	  Add an FDT blob for XLP FVP board into the kernel.
 	  This DTB will be used if the firmware does not pass in a DTB
@@ -31,6 +34,7 @@ config DT_XLP_FVP
 config DT_XLP_GVP
 	bool "Built-in device tree for XLP GVP boards"
 	default y
+	select BUILTIN_DTB
 	help
 	  Add an FDT blob for XLP GVP board into the kernel.
 	  This DTB will be used if the firmware does not pass in a DTB
diff --git a/arch/mips/netlogic/Makefile b/arch/mips/netlogic/Makefile
index 7602d13..36d169b 100644
--- a/arch/mips/netlogic/Makefile
+++ b/arch/mips/netlogic/Makefile
@@ -1,4 +1,3 @@
 obj-$(CONFIG_NLM_COMMON)	+=	common/
 obj-$(CONFIG_CPU_XLR)		+=	xlr/
 obj-$(CONFIG_CPU_XLP)		+=	xlp/
-obj-$(CONFIG_CPU_XLP)		+=	dts/
diff --git a/arch/mips/netlogic/dts/Makefile b/arch/mips/netlogic/dts/Makefile
deleted file mode 100644
index 25c8e87..0000000
--- a/arch/mips/netlogic/dts/Makefile
+++ /dev/null
@@ -1,4 +0,0 @@
-obj-$(CONFIG_DT_XLP_EVP) := xlp_evp.dtb.o
-obj-$(CONFIG_DT_XLP_SVP) += xlp_svp.dtb.o
-obj-$(CONFIG_DT_XLP_FVP) += xlp_fvp.dtb.o
-obj-$(CONFIG_DT_XLP_GVP) += xlp_gvp.dtb.o
-- 
2.1.0.rc2.206.gedb03e5

[PATCH 7/7] MIPS: ralink: Move device-trees to arch/mips/boot/dts/

[Andrew Bresticker]

Move the Ralink device-trees to arch/mips/boot/dts/ and update the
Makefiles accordingly.  A built-in device-tree is optional, so select
BUILTIN_DTB when it is requested.

Signed-off-by: Andrew Bresticker <abrestic@chromium.org>
---
 arch/mips/boot/dts/Makefile                     | 4 ++++
 arch/mips/{ralink => boot}/dts/mt7620a.dtsi     | 0
 arch/mips/{ralink => boot}/dts/mt7620a_eval.dts | 0
 arch/mips/{ralink => boot}/dts/rt2880.dtsi      | 0
 arch/mips/{ralink => boot}/dts/rt2880_eval.dts  | 0
 arch/mips/{ralink => boot}/dts/rt3050.dtsi      | 0
 arch/mips/{ralink => boot}/dts/rt3052_eval.dts  | 0
 arch/mips/{ralink => boot}/dts/rt3883.dtsi      | 0
 arch/mips/{ralink => boot}/dts/rt3883_eval.dts  | 0
 arch/mips/ralink/Kconfig                        | 4 ++++
 arch/mips/ralink/Makefile                       | 2 --
 arch/mips/ralink/dts/Makefile                   | 4 ----
 12 files changed, 8 insertions(+), 6 deletions(-)
 rename arch/mips/{ralink => boot}/dts/mt7620a.dtsi (100%)
 rename arch/mips/{ralink => boot}/dts/mt7620a_eval.dts (100%)
 rename arch/mips/{ralink => boot}/dts/rt2880.dtsi (100%)
 rename arch/mips/{ralink => boot}/dts/rt2880_eval.dts (100%)
 rename arch/mips/{ralink => boot}/dts/rt3050.dtsi (100%)
 rename arch/mips/{ralink => boot}/dts/rt3052_eval.dts (100%)
 rename arch/mips/{ralink => boot}/dts/rt3883.dtsi (100%)
 rename arch/mips/{ralink => boot}/dts/rt3883_eval.dts (100%)
 delete mode 100644 arch/mips/ralink/dts/Makefile

diff --git a/arch/mips/boot/dts/Makefile b/arch/mips/boot/dts/Makefile
index 1638a38..ca9c90e 100644
--- a/arch/mips/boot/dts/Makefile
+++ b/arch/mips/boot/dts/Makefile
@@ -4,6 +4,10 @@ dtb-$(CONFIG_DT_XLP_EVP)		+= xlp_evp.dtb
 dtb-$(CONFIG_DT_XLP_SVP)		+= xlp_svp.dtb
 dtb-$(CONFIG_DT_XLP_FVP)		+= xlp_fvp.dtb
 dtb-$(CONFIG_DT_XLP_GVP)		+= xlp_gvp.dtb
+dtb-$(CONFIG_DTB_RT2880_EVAL)		+= rt2880_eval.dtb
+dtb-$(CONFIG_DTB_RT305X_EVAL)		+= rt3052_eval.dtb
+dtb-$(CONFIG_DTB_RT3883_EVAL)		+= rt3883_eval.dtb
+dtb-$(CONFIG_DTB_MT7620A_EVAL)		+= mt7620a_eval.dtb
 dtb-$(CONFIG_MIPS_SEAD3)		+= sead3.dtb
 
 obj-y		+= $(patsubst %.dtb, %.dtb.o, $(dtb-y))
diff --git a/arch/mips/ralink/dts/mt7620a.dtsi b/arch/mips/boot/dts/mt7620a.dtsi
similarity index 100%
rename from arch/mips/ralink/dts/mt7620a.dtsi
rename to arch/mips/boot/dts/mt7620a.dtsi
diff --git a/arch/mips/ralink/dts/mt7620a_eval.dts b/arch/mips/boot/dts/mt7620a_eval.dts
similarity index 100%
rename from arch/mips/ralink/dts/mt7620a_eval.dts
rename to arch/mips/boot/dts/mt7620a_eval.dts
diff --git a/arch/mips/ralink/dts/rt2880.dtsi b/arch/mips/boot/dts/rt2880.dtsi
similarity index 100%
rename from arch/mips/ralink/dts/rt2880.dtsi
rename to arch/mips/boot/dts/rt2880.dtsi
diff --git a/arch/mips/ralink/dts/rt2880_eval.dts b/arch/mips/boot/dts/rt2880_eval.dts
similarity index 100%
rename from arch/mips/ralink/dts/rt2880_eval.dts
rename to arch/mips/boot/dts/rt2880_eval.dts
diff --git a/arch/mips/ralink/dts/rt3050.dtsi b/arch/mips/boot/dts/rt3050.dtsi
similarity index 100%
rename from arch/mips/ralink/dts/rt3050.dtsi
rename to arch/mips/boot/dts/rt3050.dtsi
diff --git a/arch/mips/ralink/dts/rt3052_eval.dts b/arch/mips/boot/dts/rt3052_eval.dts
similarity index 100%
rename from arch/mips/ralink/dts/rt3052_eval.dts
rename to arch/mips/boot/dts/rt3052_eval.dts
diff --git a/arch/mips/ralink/dts/rt3883.dtsi b/arch/mips/boot/dts/rt3883.dtsi
similarity index 100%
rename from arch/mips/ralink/dts/rt3883.dtsi
rename to arch/mips/boot/dts/rt3883.dtsi
diff --git a/arch/mips/ralink/dts/rt3883_eval.dts b/arch/mips/boot/dts/rt3883_eval.dts
similarity index 100%
rename from arch/mips/ralink/dts/rt3883_eval.dts
rename to arch/mips/boot/dts/rt3883_eval.dts
diff --git a/arch/mips/ralink/Kconfig b/arch/mips/ralink/Kconfig
index 4a29665..77e8a96 100644
--- a/arch/mips/ralink/Kconfig
+++ b/arch/mips/ralink/Kconfig
@@ -42,18 +42,22 @@ choice
 	config DTB_RT2880_EVAL
 		bool "RT2880 eval kit"
 		depends on SOC_RT288X
+		select BUILTIN_DTB
 
 	config DTB_RT305X_EVAL
 		bool "RT305x eval kit"
 		depends on SOC_RT305X
+		select BUILTIN_DTB
 
 	config DTB_RT3883_EVAL
 		bool "RT3883 eval kit"
 		depends on SOC_RT3883
+		select BUILTIN_DTB
 
 	config DTB_MT7620A_EVAL
 		bool "MT7620A eval kit"
 		depends on SOC_MT7620
+		select BUILTIN_DTB
 
 endchoice
 
diff --git a/arch/mips/ralink/Makefile b/arch/mips/ralink/Makefile
index 98ae349..2c09c8a 100644
--- a/arch/mips/ralink/Makefile
+++ b/arch/mips/ralink/Makefile
@@ -16,5 +16,3 @@ obj-$(CONFIG_SOC_RT3883) += rt3883.o
 obj-$(CONFIG_SOC_MT7620) += mt7620.o
 
 obj-$(CONFIG_EARLY_PRINTK) += early_printk.o
-
-obj-y += dts/
diff --git a/arch/mips/ralink/dts/Makefile b/arch/mips/ralink/dts/Makefile
deleted file mode 100644
index 18194fa..0000000
--- a/arch/mips/ralink/dts/Makefile
+++ /dev/null
@@ -1,4 +0,0 @@
-obj-$(CONFIG_DTB_RT2880_EVAL) := rt2880_eval.dtb.o
-obj-$(CONFIG_DTB_RT305X_EVAL) := rt3052_eval.dtb.o
-obj-$(CONFIG_DTB_RT3883_EVAL) := rt3883_eval.dtb.o
-obj-$(CONFIG_DTB_MT7620A_EVAL) := mt7620a_eval.dtb.o
-- 
2.1.0.rc2.206.gedb03e5

Re: [PATCH 0/7] MIPS: Move device-tree files to a common location

[Florian Fainelli]

[-- Attachment #1: Type: text/plain, Size: 5270 bytes --]

On Aug 21, 2014 3:05 PM, "Andrew Bresticker" <abrestic@chromium.org> wrote:
>
> To be consistent with other architectures and to avoid unnecessary
> makefile duplication, move all MIPS device-trees to arch/mips/boot/dts
> and build them with a common makefile.

I recall reading that the ARM organization for DTS files was a bit
unfortunate and should have been something like:

arch/arm/boot/dts/<vendor>/

Is this something we should do for the MIPS and update the other
architectures to follow that scheme?

>
> Patch 1 sets up the makefiles for building the DTs in arch/mips/boot/dts
> and introduces the config option BUILTIN_DTB for platforms that require
> it.
>
> Patch 2 introduces the 'dtbs' makefile target to allow building of just
> the DT binaries.
>
> Patches 3-7 move the DTs out of the platform directores.
>
> I've build tested this on all affected platforms (Octeon, Lantiq, SEAD3,
> Netlogic, and Ralink) as well as Malta.  For platforms where builtin DTBs
> are optional (Netlogic and Ralink), I built with and without the builtin
> DTBs.
>
> Based on 3.17-rc1.
>
> Andrew Bresticker (7):
>   MIPS: Create common infrastructure for building built-in device-trees
>   MIPS: Add support for building device-tree binaries
>   MIPS: Octeon: Move device-trees to arch/mips/boot/dts/
>   MIPS: Lantiq: Move device-trees to arch/mips/boot/dts/
>   MIPS: sead3: Move device-trees to arch/mips/boot/dts/
>   MIPS: Netlogic: Move device-trees to arch/mips/boot/dts/
>   MIPS: ralink: Move device-trees to arch/mips/boot/dts/
>
>  arch/mips/Kconfig                                    |  5 +++++
>  arch/mips/Makefile                                   | 11 +++++++++++
>  arch/mips/boot/.gitignore                            |  1 +
>  arch/mips/boot/dts/Makefile                          | 20
++++++++++++++++++++
>  arch/mips/{lantiq => boot}/dts/danube.dtsi           |  0
>  arch/mips/{lantiq => boot}/dts/easy50712.dts         |  0
>  arch/mips/{ralink => boot}/dts/mt7620a.dtsi          |  0
>  arch/mips/{ralink => boot}/dts/mt7620a_eval.dts      |  0
>  .../mips/{cavium-octeon => boot/dts}/octeon_3xxx.dts |  0
>  .../mips/{cavium-octeon => boot/dts}/octeon_68xx.dts |  0
>  arch/mips/{ralink => boot}/dts/rt2880.dtsi           |  0
>  arch/mips/{ralink => boot}/dts/rt2880_eval.dts       |  0
>  arch/mips/{ralink => boot}/dts/rt3050.dtsi           |  0
>  arch/mips/{ralink => boot}/dts/rt3052_eval.dts       |  0
>  arch/mips/{ralink => boot}/dts/rt3883.dtsi           |  0
>  arch/mips/{ralink => boot}/dts/rt3883_eval.dts       |  0
>  arch/mips/{mti-sead3 => boot/dts}/sead3.dts          |  0
>  arch/mips/{netlogic => boot}/dts/xlp_evp.dts         |  0
>  arch/mips/{netlogic => boot}/dts/xlp_fvp.dts         |  0
>  arch/mips/{netlogic => boot}/dts/xlp_gvp.dts         |  0
>  arch/mips/{netlogic => boot}/dts/xlp_svp.dts         |  0
>  arch/mips/cavium-octeon/.gitignore                   |  2 --
>  arch/mips/cavium-octeon/Makefile                     | 10 ----------
>  arch/mips/lantiq/Kconfig                             |  1 +
>  arch/mips/lantiq/Makefile                            |  2 --
>  arch/mips/lantiq/dts/Makefile                        |  1 -
>  arch/mips/mti-sead3/Makefile                         |  4 ----
>  arch/mips/netlogic/Kconfig                           |  4 ++++
>  arch/mips/netlogic/Makefile                          |  1 -
>  arch/mips/netlogic/dts/Makefile                      |  4 ----
>  arch/mips/ralink/Kconfig                             |  4 ++++
>  arch/mips/ralink/Makefile                            |  2 --
>  arch/mips/ralink/dts/Makefile                        |  4 ----
>  33 files changed, 46 insertions(+), 30 deletions(-)
>  create mode 100644 arch/mips/boot/dts/Makefile
>  rename arch/mips/{lantiq => boot}/dts/danube.dtsi (100%)
>  rename arch/mips/{lantiq => boot}/dts/easy50712.dts (100%)
>  rename arch/mips/{ralink => boot}/dts/mt7620a.dtsi (100%)
>  rename arch/mips/{ralink => boot}/dts/mt7620a_eval.dts (100%)
>  rename arch/mips/{cavium-octeon => boot/dts}/octeon_3xxx.dts (100%)
>  rename arch/mips/{cavium-octeon => boot/dts}/octeon_68xx.dts (100%)
>  rename arch/mips/{ralink => boot}/dts/rt2880.dtsi (100%)
>  rename arch/mips/{ralink => boot}/dts/rt2880_eval.dts (100%)
>  rename arch/mips/{ralink => boot}/dts/rt3050.dtsi (100%)
>  rename arch/mips/{ralink => boot}/dts/rt3052_eval.dts (100%)
>  rename arch/mips/{ralink => boot}/dts/rt3883.dtsi (100%)
>  rename arch/mips/{ralink => boot}/dts/rt3883_eval.dts (100%)
>  rename arch/mips/{mti-sead3 => boot/dts}/sead3.dts (100%)
>  rename arch/mips/{netlogic => boot}/dts/xlp_evp.dts (100%)
>  rename arch/mips/{netlogic => boot}/dts/xlp_fvp.dts (100%)
>  rename arch/mips/{netlogic => boot}/dts/xlp_gvp.dts (100%)
>  rename arch/mips/{netlogic => boot}/dts/xlp_svp.dts (100%)
>  delete mode 100644 arch/mips/cavium-octeon/.gitignore
>  delete mode 100644 arch/mips/lantiq/dts/Makefile
>  delete mode 100644 arch/mips/netlogic/dts/Makefile
>  delete mode 100644 arch/mips/ralink/dts/Makefile
>
> --
> 2.1.0.rc2.206.gedb03e5
>
> --
> To unsubscribe from this list: send the line "unsubscribe devicetree" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html

[-- Attachment #2: Type: text/html, Size: 6863 bytes --]

Re: [PATCH 0/7] MIPS: Move device-tree files to a common location

[David Daney]

On 08/22/2014 01:42 PM, Florian Fainelli wrote:
> On Aug 21, 2014 3:05 PM, "Andrew Bresticker" <abrestic@chromium.org
> <mailto:abrestic@chromium.org>> wrote:
>  >
>  > To be consistent with other architectures and to avoid unnecessary
>  > makefile duplication, move all MIPS device-trees to arch/mips/boot/dts
>  > and build them with a common makefile.
>
> I recall reading that the ARM organization for DTS files was a bit
> unfortunate and should have been something like:
>
> arch/arm/boot/dts/<vendor>/
>
> Is this something we should do for the MIPS and update the other
> architectures to follow that scheme?

If we choose not to intermingle .dts files from all the vendors in a 
single directory, why do anything at all?  Currently the .dts files for 
a vendor are nicely segregated with the rest of the vendors code under a 
single directory.

Personally I think things are fine as they are.  Any common code 
remaining in the Makefiles could be moved to the scripts directory for a 
smaller change.


>
>  >
>  > Patch 1 sets up the makefiles for building the DTs in arch/mips/boot/dts
>  > and introduces the config option BUILTIN_DTB for platforms that require
>  > it.
>  >
>  > Patch 2 introduces the 'dtbs' makefile target to allow building of just
>  > the DT binaries.
>  >
>  > Patches 3-7 move the DTs out of the platform directores.
>  >
>  > I've build tested this on all affected platforms (Octeon, Lantiq, SEAD3,
>  > Netlogic, and Ralink) as well as Malta.  For platforms where builtin DTBs
>  > are optional (Netlogic and Ralink), I built with and without the builtin
>  > DTBs.
>  >
>  > Based on 3.17-rc1.
>  >
>  > Andrew Bresticker (7):
>  >   MIPS: Create common infrastructure for building built-in device-trees
>  >   MIPS: Add support for building device-tree binaries
>  >   MIPS: Octeon: Move device-trees to arch/mips/boot/dts/
>  >   MIPS: Lantiq: Move device-trees to arch/mips/boot/dts/
>  >   MIPS: sead3: Move device-trees to arch/mips/boot/dts/
>  >   MIPS: Netlogic: Move device-trees to arch/mips/boot/dts/
>  >   MIPS: ralink: Move device-trees to arch/mips/boot/dts/
>  >
>  >  arch/mips/Kconfig                                    |  5 +++++
>  >  arch/mips/Makefile                                   | 11 +++++++++++
>  >  arch/mips/boot/.gitignore                            |  1 +
>  >  arch/mips/boot/dts/Makefile                          | 20
> ++++++++++++++++++++
>  >  arch/mips/{lantiq => boot}/dts/danube.dtsi           |  0
>  >  arch/mips/{lantiq => boot}/dts/easy50712.dts         |  0
>  >  arch/mips/{ralink => boot}/dts/mt7620a.dtsi          |  0
>  >  arch/mips/{ralink => boot}/dts/mt7620a_eval.dts      |  0
>  >  .../mips/{cavium-octeon => boot/dts}/octeon_3xxx.dts |  0
>  >  .../mips/{cavium-octeon => boot/dts}/octeon_68xx.dts |  0
>  >  arch/mips/{ralink => boot}/dts/rt2880.dtsi           |  0
>  >  arch/mips/{ralink => boot}/dts/rt2880_eval.dts       |  0
>  >  arch/mips/{ralink => boot}/dts/rt3050.dtsi           |  0
>  >  arch/mips/{ralink => boot}/dts/rt3052_eval.dts       |  0
>  >  arch/mips/{ralink => boot}/dts/rt3883.dtsi           |  0
>  >  arch/mips/{ralink => boot}/dts/rt3883_eval.dts       |  0
>  >  arch/mips/{mti-sead3 => boot/dts}/sead3.dts          |  0
>  >  arch/mips/{netlogic => boot}/dts/xlp_evp.dts         |  0
>  >  arch/mips/{netlogic => boot}/dts/xlp_fvp.dts         |  0
>  >  arch/mips/{netlogic => boot}/dts/xlp_gvp.dts         |  0
>  >  arch/mips/{netlogic => boot}/dts/xlp_svp.dts         |  0
>  >  arch/mips/cavium-octeon/.gitignore                   |  2 --
>  >  arch/mips/cavium-octeon/Makefile                     | 10 ----------
>  >  arch/mips/lantiq/Kconfig                             |  1 +
>  >  arch/mips/lantiq/Makefile                            |  2 --
>  >  arch/mips/lantiq/dts/Makefile                        |  1 -
>  >  arch/mips/mti-sead3/Makefile                         |  4 ----
>  >  arch/mips/netlogic/Kconfig                           |  4 ++++
>  >  arch/mips/netlogic/Makefile                          |  1 -
>  >  arch/mips/netlogic/dts/Makefile                      |  4 ----
>  >  arch/mips/ralink/Kconfig                             |  4 ++++
>  >  arch/mips/ralink/Makefile                            |  2 --
>  >  arch/mips/ralink/dts/Makefile                        |  4 ----
>  >  33 files changed, 46 insertions(+), 30 deletions(-)
>  >  create mode 100644 arch/mips/boot/dts/Makefile
>  >  rename arch/mips/{lantiq => boot}/dts/danube.dtsi (100%)
>  >  rename arch/mips/{lantiq => boot}/dts/easy50712.dts (100%)
>  >  rename arch/mips/{ralink => boot}/dts/mt7620a.dtsi (100%)
>  >  rename arch/mips/{ralink => boot}/dts/mt7620a_eval.dts (100%)
>  >  rename arch/mips/{cavium-octeon => boot/dts}/octeon_3xxx.dts (100%)
>  >  rename arch/mips/{cavium-octeon => boot/dts}/octeon_68xx.dts (100%)
>  >  rename arch/mips/{ralink => boot}/dts/rt2880.dtsi (100%)
>  >  rename arch/mips/{ralink => boot}/dts/rt2880_eval.dts (100%)
>  >  rename arch/mips/{ralink => boot}/dts/rt3050.dtsi (100%)
>  >  rename arch/mips/{ralink => boot}/dts/rt3052_eval.dts (100%)
>  >  rename arch/mips/{ralink => boot}/dts/rt3883.dtsi (100%)
>  >  rename arch/mips/{ralink => boot}/dts/rt3883_eval.dts (100%)
>  >  rename arch/mips/{mti-sead3 => boot/dts}/sead3.dts (100%)
>  >  rename arch/mips/{netlogic => boot}/dts/xlp_evp.dts (100%)
>  >  rename arch/mips/{netlogic => boot}/dts/xlp_fvp.dts (100%)
>  >  rename arch/mips/{netlogic => boot}/dts/xlp_gvp.dts (100%)
>  >  rename arch/mips/{netlogic => boot}/dts/xlp_svp.dts (100%)
>  >  delete mode 100644 arch/mips/cavium-octeon/.gitignore
>  >  delete mode 100644 arch/mips/lantiq/dts/Makefile
>  >  delete mode 100644 arch/mips/netlogic/dts/Makefile
>  >  delete mode 100644 arch/mips/ralink/dts/Makefile
>  >
>  > --
>  > 2.1.0.rc2.206.gedb03e5
>  >
>  > --
>  > To unsubscribe from this list: send the line "unsubscribe devicetree" in
>  > the body of a message to majordomo@vger.kernel.org
> <mailto:majordomo@vger.kernel.org>
>  > More majordomo info at http://vger.kernel.org/majordomo-info.html
>

Re: [PATCH 0/7] MIPS: Move device-tree files to a common location

[Andrew Bresticker]

On Fri, Aug 22, 2014 at 1:42 PM, Florian Fainelli <f.fainelli@gmail.com> wrote:
>
> On Aug 21, 2014 3:05 PM, "Andrew Bresticker" <abrestic@chromium.org> wrote:
> >
> > To be consistent with other architectures and to avoid unnecessary
> > makefile duplication, move all MIPS device-trees to arch/mips/boot/dts
> > and build them with a common makefile.
>
> I recall reading that the ARM organization for DTS files was a bit unfortunate
> and should have been something like:
>
> arch/arm/boot/dts/<vendor>/
>
> Is this something we should do for the MIPS and update the other architectures
> to follow that scheme?

I recall reading that as well and that it would be adopted for ARM64,
but that hasn't seemed to have happened.  Perhaps Olof (CC'ed) will no
more.

Re: [PATCH 0/7] MIPS: Move device-tree files to a common location

[Andrew Bresticker]

On Fri, Aug 22, 2014 at 1:57 PM, David Daney <ddaney.cavm@gmail.com> wrote:
> On 08/22/2014 01:42 PM, Florian Fainelli wrote:
>>
>> On Aug 21, 2014 3:05 PM, "Andrew Bresticker" <abrestic@chromium.org
>> <mailto:abrestic@chromium.org>> wrote:
>>  >
>>  > To be consistent with other architectures and to avoid unnecessary
>>  > makefile duplication, move all MIPS device-trees to arch/mips/boot/dts
>>  > and build them with a common makefile.
>>
>> I recall reading that the ARM organization for DTS files was a bit
>> unfortunate and should have been something like:
>>
>> arch/arm/boot/dts/<vendor>/
>>
>> Is this something we should do for the MIPS and update the other
>> architectures to follow that scheme?
>
>
> If we choose not to intermingle .dts files from all the vendors in a single
> directory, why do anything at all?  Currently the .dts files for a vendor
> are nicely segregated with the rest of the vendors code under a single
> directory.
>
> Personally I think things are fine as they are.  Any common code remaining
> in the Makefiles could be moved to the scripts directory for a smaller
> change.

Assuming we don't move them to a common location just to segregate
them again, it makes MIPS consistent with every other architecture
(not just ARM!) using DT.  It also makes it easier to introduce common
changes later on, like the 'dtbs' or 'dtbs_install' make targets.

Re: [PATCH 0/7] MIPS: Move device-tree files to a common location

[Jonas Gorski]

On Sat, Aug 23, 2014 at 12:10 AM, Andrew Bresticker
<abrestic@chromium.org> wrote:
> On Fri, Aug 22, 2014 at 1:57 PM, David Daney <ddaney.cavm@gmail.com> wrote:
>> On 08/22/2014 01:42 PM, Florian Fainelli wrote:
>>>
>>> On Aug 21, 2014 3:05 PM, "Andrew Bresticker" <abrestic@chromium.org
>>> <mailto:abrestic@chromium.org>> wrote:
>>>  >
>>>  > To be consistent with other architectures and to avoid unnecessary
>>>  > makefile duplication, move all MIPS device-trees to arch/mips/boot/dts
>>>  > and build them with a common makefile.
>>>
>>> I recall reading that the ARM organization for DTS files was a bit
>>> unfortunate and should have been something like:
>>>
>>> arch/arm/boot/dts/<vendor>/
>>>
>>> Is this something we should do for the MIPS and update the other
>>> architectures to follow that scheme?
>>
>>
>> If we choose not to intermingle .dts files from all the vendors in a single
>> directory, why do anything at all?  Currently the .dts files for a vendor
>> are nicely segregated with the rest of the vendors code under a single
>> directory.
>>
>> Personally I think things are fine as they are.  Any common code remaining
>> in the Makefiles could be moved to the scripts directory for a smaller
>> change.
>
> Assuming we don't move them to a common location just to segregate
> them again, it makes MIPS consistent with every other architecture
> (not just ARM!) using DT.  It also makes it easier to introduce common
> changes later on, like the 'dtbs' or 'dtbs_install' make targets.

I think having dts files under a predictable location is a good idea,
especially if it allows common code/targets as "dtbs".

Maybe a totally insane idea, but how this for having the cake and eating it too:

arch/mips/boot/dts/*.dts => dts files to be built along side the kernel as .dtbs

arch/mips/<mach>/*.dts => dts files built into the kernel

(the ../*.dts isn't meant as they should be in the top directory, just
somewhere in that sub tree)

Because I can see a use case where you want both. For example octeon
uses generic device tree boards to use as a basis if the bootloader
did not provide one/is too old, but maybe also provide dts files for
known boards, which shouldn't be included in the kernel binary itself.

And I would like to do a similar thing when I want to convert bcm63xx
to device tree, i.e. have dts files for supported boards, but also
include a "standard"/"fall-back" dts for each of the supported SoCs to
load if there is no dtb passed and the old board registration code is
used.


Jonas

Re: [PATCH 0/7] MIPS: Move device-tree files to a common location

[Andrew Bresticker]

On Fri, Aug 22, 2014 at 4:16 PM, Jonas Gorski <jogo@openwrt.org> wrote:
> On Sat, Aug 23, 2014 at 12:10 AM, Andrew Bresticker
> <abrestic@chromium.org> wrote:
>> On Fri, Aug 22, 2014 at 1:57 PM, David Daney <ddaney.cavm@gmail.com> wrote:
>>> On 08/22/2014 01:42 PM, Florian Fainelli wrote:
>>>>
>>>> On Aug 21, 2014 3:05 PM, "Andrew Bresticker" <abrestic@chromium.org
>>>> <mailto:abrestic@chromium.org>> wrote:
>>>>  >
>>>>  > To be consistent with other architectures and to avoid unnecessary
>>>>  > makefile duplication, move all MIPS device-trees to arch/mips/boot/dts
>>>>  > and build them with a common makefile.
>>>>
>>>> I recall reading that the ARM organization for DTS files was a bit
>>>> unfortunate and should have been something like:
>>>>
>>>> arch/arm/boot/dts/<vendor>/
>>>>
>>>> Is this something we should do for the MIPS and update the other
>>>> architectures to follow that scheme?
>>>
>>>
>>> If we choose not to intermingle .dts files from all the vendors in a single
>>> directory, why do anything at all?  Currently the .dts files for a vendor
>>> are nicely segregated with the rest of the vendors code under a single
>>> directory.
>>>
>>> Personally I think things are fine as they are.  Any common code remaining
>>> in the Makefiles could be moved to the scripts directory for a smaller
>>> change.
>>
>> Assuming we don't move them to a common location just to segregate
>> them again, it makes MIPS consistent with every other architecture
>> (not just ARM!) using DT.  It also makes it easier to introduce common
>> changes later on, like the 'dtbs' or 'dtbs_install' make targets.
>
> I think having dts files under a predictable location is a good idea,
> especially if it allows common code/targets as "dtbs".
>
> Maybe a totally insane idea, but how this for having the cake and eating it too:
>
> arch/mips/boot/dts/*.dts => dts files to be built along side the kernel as .dtbs
>
> arch/mips/<mach>/*.dts => dts files built into the kernel
>
> (the ../*.dts isn't meant as they should be in the top directory, just
> somewhere in that sub tree)
>
> Because I can see a use case where you want both. For example octeon
> uses generic device tree boards to use as a basis if the bootloader
> did not provide one/is too old, but maybe also provide dts files for
> known boards, which shouldn't be included in the kernel binary itself.

I'm not sure I like having DTs in both the common and per-platform
directories, but this is a use case I've been think about as well.
What I'm thinking is: have "make dtbs" build all applicable DTBs for
the selected platform and, based on other config options, build some
subset of those DTBs in the kernel.  For example: if CONFIG_RALINK,
"make dtbs" builds all the {mt,rt}*_eval.dtb's and, when building the
kernel, one of those dtbs may be built into the kernel based on which
CONFIG_DTB_RT* option is selected (if any).  I'm not sure yet what the
cleanest way to do that is though.

Re: [PATCH 0/7] MIPS: Move device-tree files to a common location

[Andrew Bresticker]

On Fri, Aug 22, 2014 at 4:16 PM, Jonas Gorski <jogo-p3rKhJxN3npAfugRpC6u6w@public.gmane.org> wrote:
> On Sat, Aug 23, 2014 at 12:10 AM, Andrew Bresticker
> <abrestic-F7+t8E8rja9g9hUCZPvPmw@public.gmane.org> wrote:
>> On Fri, Aug 22, 2014 at 1:57 PM, David Daney <ddaney.cavm-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote:
>>> On 08/22/2014 01:42 PM, Florian Fainelli wrote:
>>>>
>>>> On Aug 21, 2014 3:05 PM, "Andrew Bresticker" <abrestic-F7+t8E8rja9g9hUCZPvPmw@public.gmane.org
>>>> <mailto:abrestic-F7+t8E8rja9g9hUCZPvPmw@public.gmane.org>> wrote:
>>>>  >
>>>>  > To be consistent with other architectures and to avoid unnecessary
>>>>  > makefile duplication, move all MIPS device-trees to arch/mips/boot/dts
>>>>  > and build them with a common makefile.
>>>>
>>>> I recall reading that the ARM organization for DTS files was a bit
>>>> unfortunate and should have been something like:
>>>>
>>>> arch/arm/boot/dts/<vendor>/
>>>>
>>>> Is this something we should do for the MIPS and update the other
>>>> architectures to follow that scheme?
>>>
>>>
>>> If we choose not to intermingle .dts files from all the vendors in a single
>>> directory, why do anything at all?  Currently the .dts files for a vendor
>>> are nicely segregated with the rest of the vendors code under a single
>>> directory.
>>>
>>> Personally I think things are fine as they are.  Any common code remaining
>>> in the Makefiles could be moved to the scripts directory for a smaller
>>> change.
>>
>> Assuming we don't move them to a common location just to segregate
>> them again, it makes MIPS consistent with every other architecture
>> (not just ARM!) using DT.  It also makes it easier to introduce common
>> changes later on, like the 'dtbs' or 'dtbs_install' make targets.
>
> I think having dts files under a predictable location is a good idea,
> especially if it allows common code/targets as "dtbs".
>
> Maybe a totally insane idea, but how this for having the cake and eating it too:
>
> arch/mips/boot/dts/*.dts => dts files to be built along side the kernel as .dtbs
>
> arch/mips/<mach>/*.dts => dts files built into the kernel
>
> (the ../*.dts isn't meant as they should be in the top directory, just
> somewhere in that sub tree)
>
> Because I can see a use case where you want both. For example octeon
> uses generic device tree boards to use as a basis if the bootloader
> did not provide one/is too old, but maybe also provide dts files for
> known boards, which shouldn't be included in the kernel binary itself.

I'm not sure I like having DTs in both the common and per-platform
directories, but this is a use case I've been think about as well.
What I'm thinking is: have "make dtbs" build all applicable DTBs for
the selected platform and, based on other config options, build some
subset of those DTBs in the kernel.  For example: if CONFIG_RALINK,
"make dtbs" builds all the {mt,rt}*_eval.dtb's and, when building the
kernel, one of those dtbs may be built into the kernel based on which
CONFIG_DTB_RT* option is selected (if any).  I'm not sure yet what the
cleanest way to do that is though.
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH 0/7] MIPS: Move device-tree files to a common location

[Olof Johansson]

On Fri, Aug 22, 2014 at 02:10:23PM -0700, Andrew Bresticker wrote:
> On Fri, Aug 22, 2014 at 1:42 PM, Florian Fainelli <f.fainelli@gmail.com> wrote:
> >
> > On Aug 21, 2014 3:05 PM, "Andrew Bresticker" <abrestic@chromium.org> wrote:
> > >
> > > To be consistent with other architectures and to avoid unnecessary
> > > makefile duplication, move all MIPS device-trees to arch/mips/boot/dts
> > > and build them with a common makefile.
> >
> > I recall reading that the ARM organization for DTS files was a bit unfortunate
> > and should have been something like:
> >
> > arch/arm/boot/dts/<vendor>/
> >
> > Is this something we should do for the MIPS and update the other architectures
> > to follow that scheme?
> 
> I recall reading that as well and that it would be adopted for ARM64,
> but that hasn't seemed to have happened.  Perhaps Olof (CC'ed) will no
> more.

Yeah, I highly recommend having a directory per vendor. We didn't on ARM,
and the amount of files in that directory is becoming pretty
insane. Moving to a subdirectory structure later gets messy which is
why we've been holding off on it.


-Olof

Re: [PATCH 0/7] MIPS: Move device-tree files to a common location

[Arnd Bergmann]

On Saturday 23 August 2014, Olof Johansson wrote:
> On Fri, Aug 22, 2014 at 02:10:23PM -0700, Andrew Bresticker wrote:
> > On Fri, Aug 22, 2014 at 1:42 PM, Florian Fainelli <f.fainelli@gmail.com> wrote:
> > >
> > > On Aug 21, 2014 3:05 PM, "Andrew Bresticker" <abrestic@chromium.org> wrote:
> > > >
> > > > To be consistent with other architectures and to avoid unnecessary
> > > > makefile duplication, move all MIPS device-trees to arch/mips/boot/dts
> > > > and build them with a common makefile.
> > >
> > > I recall reading that the ARM organization for DTS files was a bit unfortunate
> > > and should have been something like:
> > >
> > > arch/arm/boot/dts/<vendor>/
> > >
> > > Is this something we should do for the MIPS and update the other architectures
> > > to follow that scheme?
> > 
> > I recall reading that as well and that it would be adopted for ARM64,
> > but that hasn't seemed to have happened.  Perhaps Olof (CC'ed) will no
> > more.
> 
> Yeah, I highly recommend having a directory per vendor. We didn't on ARM,
> and the amount of files in that directory is becoming pretty
> insane. Moving to a subdirectory structure later gets messy which is
> why we've been holding off on it.

Another argument is that we plan to actually move all the dts files out of
the kernel into a separate project in the future. We really don't want to
have the churn of moving all the files now when they get deleted in one
of the next merge windows.

I don't know if we talked about whether that move should be done for
all architectures at the same time. If that is the plan, I think it
would be best to not move the MIPS files at all but also wait until
they can get removed from the kernel tree.

	Arnd

Re: [PATCH 0/7] MIPS: Move device-tree files to a common location

[Jonas Gorski]

On Sat, Aug 23, 2014 at 3:56 PM, Arnd Bergmann <arnd@arndb.de> wrote:
> Another argument is that we plan to actually move all the dts files out of
> the kernel into a separate project in the future. We really don't want to
> have the churn of moving all the files now when they get deleted in one
> of the next merge windows.
>
> I don't know if we talked about whether that move should be done for
> all architectures at the same time. If that is the plan, I think it
> would be best to not move the MIPS files at all but also wait until
> they can get removed from the kernel tree.

I wonder how this is supposed to work with dtbs that are currently
expected to be built into the kernel?


Jonas

Re: [PATCH 0/7] MIPS: Move device-tree files to a common location

[Jonas Gorski]

On Sat, Aug 23, 2014 at 3:56 PM, Arnd Bergmann <arnd-r2nGTMty4D4@public.gmane.org> wrote:
> Another argument is that we plan to actually move all the dts files out of
> the kernel into a separate project in the future. We really don't want to
> have the churn of moving all the files now when they get deleted in one
> of the next merge windows.
>
> I don't know if we talked about whether that move should be done for
> all architectures at the same time. If that is the plan, I think it
> would be best to not move the MIPS files at all but also wait until
> they can get removed from the kernel tree.

I wonder how this is supposed to work with dtbs that are currently
expected to be built into the kernel?


Jonas
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH 0/7] MIPS: Move device-tree files to a common location

[Arnd Bergmann]

On Saturday 23 August 2014 16:48:52 Jonas Gorski wrote:
> On Sat, Aug 23, 2014 at 3:56 PM, Arnd Bergmann <arnd@arndb.de> wrote:
> > Another argument is that we plan to actually move all the dts files out of
> > the kernel into a separate project in the future. We really don't want to
> > have the churn of moving all the files now when they get deleted in one
> > of the next merge windows.
> >
> > I don't know if we talked about whether that move should be done for
> > all architectures at the same time. If that is the plan, I think it
> > would be best to not move the MIPS files at all but also wait until
> > they can get removed from the kernel tree.
> 
> I wonder how this is supposed to work with dtbs that are currently
> expected to be built into the kernel?

Most architectures use appended dtb blobs to work around legacy boot
loaders that are lacking native dtb support. For these, combining the
kernel and dtb is part of the installation or system image creation
process, not part of the kernel build.

For the architectures that currently link the dtb into the kernel,
(arc, metag, openrisc, xtensa), I suppose the best way is to move
to use the same method as the other architectures. This also solves
the problem of building a kernel that runs on multiple machines.

	Arnd

Re: [PATCH 0/7] MIPS: Move device-tree files to a common location

[Arnd Bergmann]

On Saturday 23 August 2014 16:48:52 Jonas Gorski wrote:
> On Sat, Aug 23, 2014 at 3:56 PM, Arnd Bergmann <arnd-r2nGTMty4D4@public.gmane.org> wrote:
> > Another argument is that we plan to actually move all the dts files out of
> > the kernel into a separate project in the future. We really don't want to
> > have the churn of moving all the files now when they get deleted in one
> > of the next merge windows.
> >
> > I don't know if we talked about whether that move should be done for
> > all architectures at the same time. If that is the plan, I think it
> > would be best to not move the MIPS files at all but also wait until
> > they can get removed from the kernel tree.
> 
> I wonder how this is supposed to work with dtbs that are currently
> expected to be built into the kernel?

Most architectures use appended dtb blobs to work around legacy boot
loaders that are lacking native dtb support. For these, combining the
kernel and dtb is part of the installation or system image creation
process, not part of the kernel build.

For the architectures that currently link the dtb into the kernel,
(arc, metag, openrisc, xtensa), I suppose the best way is to move
to use the same method as the other architectures. This also solves
the problem of building a kernel that runs on multiple machines.

	Arnd
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH 0/7] MIPS: Move device-tree files to a common location

[Olof Johansson]

On Sat, Aug 23, 2014 at 03:56:42PM +0200, Arnd Bergmann wrote:
> On Saturday 23 August 2014, Olof Johansson wrote:
> > On Fri, Aug 22, 2014 at 02:10:23PM -0700, Andrew Bresticker wrote:
> > > On Fri, Aug 22, 2014 at 1:42 PM, Florian Fainelli <f.fainelli@gmail.com> wrote:
> > > >
> > > > On Aug 21, 2014 3:05 PM, "Andrew Bresticker" <abrestic@chromium.org> wrote:
> > > > >
> > > > > To be consistent with other architectures and to avoid unnecessary
> > > > > makefile duplication, move all MIPS device-trees to arch/mips/boot/dts
> > > > > and build them with a common makefile.
> > > >
> > > > I recall reading that the ARM organization for DTS files was a bit unfortunate
> > > > and should have been something like:
> > > >
> > > > arch/arm/boot/dts/<vendor>/
> > > >
> > > > Is this something we should do for the MIPS and update the other architectures
> > > > to follow that scheme?
> > > 
> > > I recall reading that as well and that it would be adopted for ARM64,
> > > but that hasn't seemed to have happened.  Perhaps Olof (CC'ed) will no
> > > more.
> > 
> > Yeah, I highly recommend having a directory per vendor. We didn't on ARM,
> > and the amount of files in that directory is becoming pretty
> > insane. Moving to a subdirectory structure later gets messy which is
> > why we've been holding off on it.
> 
> Another argument is that we plan to actually move all the dts files out of
> the kernel into a separate project in the future. We really don't want to
> have the churn of moving all the files now when they get deleted in one
> of the next merge windows.

To be honest, I don't see that happening within the forseeable
future. Some of us maintainers like talking about this, but everyone who
actually develops have nightmares about this scenario. Nobody knows how
it'll be done without causing some real serious impact on productivity.

> I don't know if we talked about whether that move should be done for
> all architectures at the same time. If that is the plan, I think it
> would be best to not move the MIPS files at all but also wait until
> they can get removed from the kernel tree.

If MIPS can restructure now before things start growing, then I'd really
recommend that they do so and not hold off waiting on some event that
might never happen. :)


-Olof

Re: [PATCH 0/7] MIPS: Move device-tree files to a common location

[Geert Uytterhoeven]

On Sat, Aug 23, 2014 at 8:31 AM, Olof Johansson <olof@lixom.net> wrote:
>> > arch/arm/boot/dts/<vendor>/
>> >
>> > Is this something we should do for the MIPS and update the other architectures
>> > to follow that scheme?
>>
>> I recall reading that as well and that it would be adopted for ARM64,
>> but that hasn't seemed to have happened.  Perhaps Olof (CC'ed) will no
>> more.
>
> Yeah, I highly recommend having a directory per vendor. We didn't on ARM,
> and the amount of files in that directory is becoming pretty
> insane. Moving to a subdirectory structure later gets messy which is
> why we've been holding off on it.

It would mean we can change our scripts to operate on "interesting"
DTS files from

     do-something-with $(git grep -l $vendor, -- arch/arm/boot/dts)

to

    do-something-with arch/arm/boot/dts/$vendor/*

which is easier to type...

Gr{oetje,eeting}s,

                        Geert

--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
                                -- Linus Torvalds

Re: [PATCH 0/7] MIPS: Move device-tree files to a common location

[Rob Herring]

On Sat, Aug 23, 2014 at 11:14 AM, Olof Johansson <olof@lixom.net> wrote:
> On Sat, Aug 23, 2014 at 03:56:42PM +0200, Arnd Bergmann wrote:
>> On Saturday 23 August 2014, Olof Johansson wrote:
>> > On Fri, Aug 22, 2014 at 02:10:23PM -0700, Andrew Bresticker wrote:
>> > > On Fri, Aug 22, 2014 at 1:42 PM, Florian Fainelli <f.fainelli@gmail.com> wrote:
>> > > >
>> > > > On Aug 21, 2014 3:05 PM, "Andrew Bresticker" <abrestic@chromium.org> wrote:
>> > > > >
>> > > > > To be consistent with other architectures and to avoid unnecessary
>> > > > > makefile duplication, move all MIPS device-trees to arch/mips/boot/dts
>> > > > > and build them with a common makefile.
>> > > >
>> > > > I recall reading that the ARM organization for DTS files was a bit unfortunate
>> > > > and should have been something like:
>> > > >
>> > > > arch/arm/boot/dts/<vendor>/
>> > > >
>> > > > Is this something we should do for the MIPS and update the other architectures
>> > > > to follow that scheme?
>> > >
>> > > I recall reading that as well and that it would be adopted for ARM64,
>> > > but that hasn't seemed to have happened.  Perhaps Olof (CC'ed) will no
>> > > more.
>> >
>> > Yeah, I highly recommend having a directory per vendor. We didn't on ARM,
>> > and the amount of files in that directory is becoming pretty
>> > insane. Moving to a subdirectory structure later gets messy which is
>> > why we've been holding off on it.
>>
>> Another argument is that we plan to actually move all the dts files out of
>> the kernel into a separate project in the future. We really don't want to
>> have the churn of moving all the files now when they get deleted in one
>> of the next merge windows.
>
> To be honest, I don't see that happening within the forseeable
> future. Some of us maintainers like talking about this, but everyone who
> actually develops have nightmares about this scenario. Nobody knows how
> it'll be done without causing some real serious impact on productivity.
>
>> I don't know if we talked about whether that move should be done for
>> all architectures at the same time. If that is the plan, I think it
>> would be best to not move the MIPS files at all but also wait until
>> they can get removed from the kernel tree.
>
> If MIPS can restructure now before things start growing, then I'd really
> recommend that they do so and not hold off waiting on some event that
> might never happen. :)

Yes, I agree on both points.

Rob

Re: [PATCH 0/7] MIPS: Move device-tree files to a common location

[Rob Herring]

On Sat, Aug 23, 2014 at 11:14 AM, Olof Johansson <olof-nZhT3qVonbNeoWH0uzbU5w@public.gmane.org> wrote:
> On Sat, Aug 23, 2014 at 03:56:42PM +0200, Arnd Bergmann wrote:
>> On Saturday 23 August 2014, Olof Johansson wrote:
>> > On Fri, Aug 22, 2014 at 02:10:23PM -0700, Andrew Bresticker wrote:
>> > > On Fri, Aug 22, 2014 at 1:42 PM, Florian Fainelli <f.fainelli-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote:
>> > > >
>> > > > On Aug 21, 2014 3:05 PM, "Andrew Bresticker" <abrestic-F7+t8E8rja9g9hUCZPvPmw@public.gmane.org> wrote:
>> > > > >
>> > > > > To be consistent with other architectures and to avoid unnecessary
>> > > > > makefile duplication, move all MIPS device-trees to arch/mips/boot/dts
>> > > > > and build them with a common makefile.
>> > > >
>> > > > I recall reading that the ARM organization for DTS files was a bit unfortunate
>> > > > and should have been something like:
>> > > >
>> > > > arch/arm/boot/dts/<vendor>/
>> > > >
>> > > > Is this something we should do for the MIPS and update the other architectures
>> > > > to follow that scheme?
>> > >
>> > > I recall reading that as well and that it would be adopted for ARM64,
>> > > but that hasn't seemed to have happened.  Perhaps Olof (CC'ed) will no
>> > > more.
>> >
>> > Yeah, I highly recommend having a directory per vendor. We didn't on ARM,
>> > and the amount of files in that directory is becoming pretty
>> > insane. Moving to a subdirectory structure later gets messy which is
>> > why we've been holding off on it.
>>
>> Another argument is that we plan to actually move all the dts files out of
>> the kernel into a separate project in the future. We really don't want to
>> have the churn of moving all the files now when they get deleted in one
>> of the next merge windows.
>
> To be honest, I don't see that happening within the forseeable
> future. Some of us maintainers like talking about this, but everyone who
> actually develops have nightmares about this scenario. Nobody knows how
> it'll be done without causing some real serious impact on productivity.
>
>> I don't know if we talked about whether that move should be done for
>> all architectures at the same time. If that is the plan, I think it
>> would be best to not move the MIPS files at all but also wait until
>> they can get removed from the kernel tree.
>
> If MIPS can restructure now before things start growing, then I'd really
> recommend that they do so and not hold off waiting on some event that
> might never happen. :)

Yes, I agree on both points.

Rob
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH 0/7] MIPS: Move device-tree files to a common location

[Arnd Bergmann]

On Sunday 24 August 2014 18:43:35 Rob Herring wrote:
> On Sat, Aug 23, 2014 at 11:14 AM, Olof Johansson <olof@lixom.net> wrote:
> > On Sat, Aug 23, 2014 at 03:56:42PM +0200, Arnd Bergmann wrote:
> >>
> >> Another argument is that we plan to actually move all the dts files out of
> >> the kernel into a separate project in the future. We really don't want to
> >> have the churn of moving all the files now when they get deleted in one
> >> of the next merge windows.
> >
> > To be honest, I don't see that happening within the forseeable
> > future. Some of us maintainers like talking about this, but everyone who
> > actually develops have nightmares about this scenario. Nobody knows how
> > it'll be done without causing some real serious impact on productivity.
> >
> >> I don't know if we talked about whether that move should be done for
> >> all architectures at the same time. If that is the plan, I think it
> >> would be best to not move the MIPS files at all but also wait until
> >> they can get removed from the kernel tree.
> >
> > If MIPS can restructure now before things start growing, then I'd really
> > recommend that they do so and not hold off waiting on some event that
> > might never happen. 
> 
> Yes, I agree on both points.
> 

Ok, fair enough.

	Arnd

Re: [PATCH 0/7] MIPS: Move device-tree files to a common location

[Ralf Baechle]

There have been no forcing arguments for or against acceptance of this
patch series but given that many other architectures organize their
DTS files in an arch/<ARCH>/boot/dts/ directory I think MIPS should
follow that example.

  Ralf

Re: [PATCH 0/7] MIPS: Move device-tree files to a common location

[Jonas Gorski]

On Sat, Aug 23, 2014 at 9:50 PM, Geert Uytterhoeven
<geert@linux-m68k.org> wrote:
> On Sat, Aug 23, 2014 at 8:31 AM, Olof Johansson <olof@lixom.net> wrote:
>>> > arch/arm/boot/dts/<vendor>/
>>> >
>>> > Is this something we should do for the MIPS and update the other architectures
>>> > to follow that scheme?
>>>
>>> I recall reading that as well and that it would be adopted for ARM64,
>>> but that hasn't seemed to have happened.  Perhaps Olof (CC'ed) will no
>>> more.
>>
>> Yeah, I highly recommend having a directory per vendor. We didn't on ARM,
>> and the amount of files in that directory is becoming pretty
>> insane. Moving to a subdirectory structure later gets messy which is
>> why we've been holding off on it.
>
> It would mean we can change our scripts to operate on "interesting"
> DTS files from
>
>      do-something-with $(git grep -l $vendor, -- arch/arm/boot/dts)
>
> to
>
>     do-something-with arch/arm/boot/dts/$vendor/*
>
> which is easier to type...

Btw, do you mean chip-vendor or device-vendor with vendor?
Device-vendor could get a bit messy on the source part as the router
manufacturers tend to switch them quite often. E.g. d-link used arm,
mips and ubi32 chips from marvell, ubicom, broadcom, atheros, realtek
and ralink for their dir-615 router, happily switching back and forth.
There are 14 known different hardware revisions of it where the chip
differed from the previous one.



Jonas

Re: [PATCH 0/7] MIPS: Move device-tree files to a common location

[Jonas Gorski]

On Sat, Aug 23, 2014 at 9:50 PM, Geert Uytterhoeven
<geert-Td1EMuHUCqxL1ZNQvxDV9g@public.gmane.org> wrote:
> On Sat, Aug 23, 2014 at 8:31 AM, Olof Johansson <olof-nZhT3qVonbNeoWH0uzbU5w@public.gmane.org> wrote:
>>> > arch/arm/boot/dts/<vendor>/
>>> >
>>> > Is this something we should do for the MIPS and update the other architectures
>>> > to follow that scheme?
>>>
>>> I recall reading that as well and that it would be adopted for ARM64,
>>> but that hasn't seemed to have happened.  Perhaps Olof (CC'ed) will no
>>> more.
>>
>> Yeah, I highly recommend having a directory per vendor. We didn't on ARM,
>> and the amount of files in that directory is becoming pretty
>> insane. Moving to a subdirectory structure later gets messy which is
>> why we've been holding off on it.
>
> It would mean we can change our scripts to operate on "interesting"
> DTS files from
>
>      do-something-with $(git grep -l $vendor, -- arch/arm/boot/dts)
>
> to
>
>     do-something-with arch/arm/boot/dts/$vendor/*
>
> which is easier to type...

Btw, do you mean chip-vendor or device-vendor with vendor?
Device-vendor could get a bit messy on the source part as the router
manufacturers tend to switch them quite often. E.g. d-link used arm,
mips and ubi32 chips from marvell, ubicom, broadcom, atheros, realtek
and ralink for their dir-615 router, happily switching back and forth.
There are 14 known different hardware revisions of it where the chip
differed from the previous one.



Jonas
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH 0/7] MIPS: Move device-tree files to a common location

[Geert Uytterhoeven]

On Mon, Aug 25, 2014 at 5:17 PM, Jonas Gorski <jogo@openwrt.org> wrote:
> On Sat, Aug 23, 2014 at 9:50 PM, Geert Uytterhoeven
> <geert@linux-m68k.org> wrote:
>> On Sat, Aug 23, 2014 at 8:31 AM, Olof Johansson <olof@lixom.net> wrote:
>>>> > arch/arm/boot/dts/<vendor>/
>>>> >
>>>> > Is this something we should do for the MIPS and update the other architectures
>>>> > to follow that scheme?
>>>>
>>>> I recall reading that as well and that it would be adopted for ARM64,
>>>> but that hasn't seemed to have happened.  Perhaps Olof (CC'ed) will no
>>>> more.
>>>
>>> Yeah, I highly recommend having a directory per vendor. We didn't on ARM,
>>> and the amount of files in that directory is becoming pretty
>>> insane. Moving to a subdirectory structure later gets messy which is
>>> why we've been holding off on it.
>>
>> It would mean we can change our scripts to operate on "interesting"
>> DTS files from
>>
>>      do-something-with $(git grep -l $vendor, -- arch/arm/boot/dts)
>>
>> to
>>
>>     do-something-with arch/arm/boot/dts/$vendor/*
>>
>> which is easier to type...
>
> Btw, do you mean chip-vendor or device-vendor with vendor?
> Device-vendor could get a bit messy on the source part as the router
> manufacturers tend to switch them quite often. E.g. d-link used arm,
> mips and ubi32 chips from marvell, ubicom, broadcom, atheros, realtek
> and ralink for their dir-615 router, happily switching back and forth.
> There are 14 known different hardware revisions of it where the chip
> differed from the previous one.

That's indeed a good question, as you'll be having a *.dts for a device,
including a *.dtsi for an SoC.

Gr{oetje,eeting}s,

                        Geert

--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
                                -- Linus Torvalds

Re: [PATCH 0/7] MIPS: Move device-tree files to a common location

[Geert Uytterhoeven]

On Mon, Aug 25, 2014 at 5:17 PM, Jonas Gorski <jogo-p3rKhJxN3npAfugRpC6u6w@public.gmane.org> wrote:
> On Sat, Aug 23, 2014 at 9:50 PM, Geert Uytterhoeven
> <geert-Td1EMuHUCqxL1ZNQvxDV9g@public.gmane.org> wrote:
>> On Sat, Aug 23, 2014 at 8:31 AM, Olof Johansson <olof-nZhT3qVonbNeoWH0uzbU5w@public.gmane.org> wrote:
>>>> > arch/arm/boot/dts/<vendor>/
>>>> >
>>>> > Is this something we should do for the MIPS and update the other architectures
>>>> > to follow that scheme?
>>>>
>>>> I recall reading that as well and that it would be adopted for ARM64,
>>>> but that hasn't seemed to have happened.  Perhaps Olof (CC'ed) will no
>>>> more.
>>>
>>> Yeah, I highly recommend having a directory per vendor. We didn't on ARM,
>>> and the amount of files in that directory is becoming pretty
>>> insane. Moving to a subdirectory structure later gets messy which is
>>> why we've been holding off on it.
>>
>> It would mean we can change our scripts to operate on "interesting"
>> DTS files from
>>
>>      do-something-with $(git grep -l $vendor, -- arch/arm/boot/dts)
>>
>> to
>>
>>     do-something-with arch/arm/boot/dts/$vendor/*
>>
>> which is easier to type...
>
> Btw, do you mean chip-vendor or device-vendor with vendor?
> Device-vendor could get a bit messy on the source part as the router
> manufacturers tend to switch them quite often. E.g. d-link used arm,
> mips and ubi32 chips from marvell, ubicom, broadcom, atheros, realtek
> and ralink for their dir-615 router, happily switching back and forth.
> There are 14 known different hardware revisions of it where the chip
> differed from the previous one.

That's indeed a good question, as you'll be having a *.dts for a device,
including a *.dtsi for an SoC.

Gr{oetje,eeting}s,

                        Geert

--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert-Td1EMuHUCqxL1ZNQvxDV9g@public.gmane.org

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
                                -- Linus Torvalds
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH 0/7] MIPS: Move device-tree files to a common location

[Andrew Bresticker]

On Mon, Aug 25, 2014 at 8:17 AM, Jonas Gorski <jogo@openwrt.org> wrote:
> On Sat, Aug 23, 2014 at 9:50 PM, Geert Uytterhoeven
> <geert@linux-m68k.org> wrote:
>> On Sat, Aug 23, 2014 at 8:31 AM, Olof Johansson <olof@lixom.net> wrote:
>>>> > arch/arm/boot/dts/<vendor>/
>>>> >
>>>> > Is this something we should do for the MIPS and update the other architectures
>>>> > to follow that scheme?
>>>>
>>>> I recall reading that as well and that it would be adopted for ARM64,
>>>> but that hasn't seemed to have happened.  Perhaps Olof (CC'ed) will no
>>>> more.
>>>
>>> Yeah, I highly recommend having a directory per vendor. We didn't on ARM,
>>> and the amount of files in that directory is becoming pretty
>>> insane. Moving to a subdirectory structure later gets messy which is
>>> why we've been holding off on it.
>>
>> It would mean we can change our scripts to operate on "interesting"
>> DTS files from
>>
>>      do-something-with $(git grep -l $vendor, -- arch/arm/boot/dts)
>>
>> to
>>
>>     do-something-with arch/arm/boot/dts/$vendor/*
>>
>> which is easier to type...
>
> Btw, do you mean chip-vendor or device-vendor with vendor?
> Device-vendor could get a bit messy on the source part as the router
> manufacturers tend to switch them quite often. E.g. d-link used arm,
> mips and ubi32 chips from marvell, ubicom, broadcom, atheros, realtek
> and ralink for their dir-615 router, happily switching back and forth.
> There are 14 known different hardware revisions of it where the chip
> differed from the previous one.

I'm going to assume it means chip/SoC vendor.  That would result in
the following structure (I think):

Octeon -> cavium/
Lantiq -> lantiq/
Netlogic -> netlogic/ (or should this now be brcm/?)
SEAD-3 -> mti/
Ralink -> ralink/

Re: [PATCH 0/7] MIPS: Move device-tree files to a common location

[David Daney]

On 08/27/2014 11:30 AM, Andrew Bresticker wrote:
> On Mon, Aug 25, 2014 at 8:17 AM, Jonas Gorski <jogo@openwrt.org> wrote:
>> On Sat, Aug 23, 2014 at 9:50 PM, Geert Uytterhoeven
>> <geert@linux-m68k.org> wrote:
>>> On Sat, Aug 23, 2014 at 8:31 AM, Olof Johansson <olof@lixom.net> wrote:
>>>>>> arch/arm/boot/dts/<vendor>/
>>>>>>
>>>>>> Is this something we should do for the MIPS and update the other architectures
>>>>>> to follow that scheme?
>>>>>
>>>>> I recall reading that as well and that it would be adopted for ARM64,
>>>>> but that hasn't seemed to have happened.  Perhaps Olof (CC'ed) will no
>>>>> more.
>>>>
>>>> Yeah, I highly recommend having a directory per vendor. We didn't on ARM,
>>>> and the amount of files in that directory is becoming pretty
>>>> insane. Moving to a subdirectory structure later gets messy which is
>>>> why we've been holding off on it.
>>>
>>> It would mean we can change our scripts to operate on "interesting"
>>> DTS files from
>>>
>>>       do-something-with $(git grep -l $vendor, -- arch/arm/boot/dts)
>>>
>>> to
>>>
>>>      do-something-with arch/arm/boot/dts/$vendor/*
>>>
>>> which is easier to type...
>>
>> Btw, do you mean chip-vendor or device-vendor with vendor?
>> Device-vendor could get a bit messy on the source part as the router
>> manufacturers tend to switch them quite often. E.g. d-link used arm,
>> mips and ubi32 chips from marvell, ubicom, broadcom, atheros, realtek
>> and ralink for their dir-615 router, happily switching back and forth.
>> There are 14 known different hardware revisions of it where the chip
>> differed from the previous one.
>
> I'm going to assume it means chip/SoC vendor.  That would result in
> the following structure (I think):
>
> Octeon -> cavium/

To match the state of the art naming we have in other MIPS related 
directories, it should probably be "cavium-octeon/" (See 
arch/mips/cavium-octeon, and arch/mips/include/asm/mach-cavium-octeon)

David Daney

Re: [PATCH 0/7] MIPS: Move device-tree files to a common location

[David Daney]

On 08/27/2014 11:30 AM, Andrew Bresticker wrote:
> On Mon, Aug 25, 2014 at 8:17 AM, Jonas Gorski <jogo-p3rKhJxN3npAfugRpC6u6w@public.gmane.org> wrote:
>> On Sat, Aug 23, 2014 at 9:50 PM, Geert Uytterhoeven
>> <geert-Td1EMuHUCqxL1ZNQvxDV9g@public.gmane.org> wrote:
>>> On Sat, Aug 23, 2014 at 8:31 AM, Olof Johansson <olof-nZhT3qVonbNeoWH0uzbU5w@public.gmane.org> wrote:
>>>>>> arch/arm/boot/dts/<vendor>/
>>>>>>
>>>>>> Is this something we should do for the MIPS and update the other architectures
>>>>>> to follow that scheme?
>>>>>
>>>>> I recall reading that as well and that it would be adopted for ARM64,
>>>>> but that hasn't seemed to have happened.  Perhaps Olof (CC'ed) will no
>>>>> more.
>>>>
>>>> Yeah, I highly recommend having a directory per vendor. We didn't on ARM,
>>>> and the amount of files in that directory is becoming pretty
>>>> insane. Moving to a subdirectory structure later gets messy which is
>>>> why we've been holding off on it.
>>>
>>> It would mean we can change our scripts to operate on "interesting"
>>> DTS files from
>>>
>>>       do-something-with $(git grep -l $vendor, -- arch/arm/boot/dts)
>>>
>>> to
>>>
>>>      do-something-with arch/arm/boot/dts/$vendor/*
>>>
>>> which is easier to type...
>>
>> Btw, do you mean chip-vendor or device-vendor with vendor?
>> Device-vendor could get a bit messy on the source part as the router
>> manufacturers tend to switch them quite often. E.g. d-link used arm,
>> mips and ubi32 chips from marvell, ubicom, broadcom, atheros, realtek
>> and ralink for their dir-615 router, happily switching back and forth.
>> There are 14 known different hardware revisions of it where the chip
>> differed from the previous one.
>
> I'm going to assume it means chip/SoC vendor.  That would result in
> the following structure (I think):
>
> Octeon -> cavium/

To match the state of the art naming we have in other MIPS related 
directories, it should probably be "cavium-octeon/" (See 
arch/mips/cavium-octeon, and arch/mips/include/asm/mach-cavium-octeon)

David Daney
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH 0/7] MIPS: Move device-tree files to a common location

[Rob Herring]

On Mon, Aug 25, 2014 at 10:17 AM, Jonas Gorski <jogo@openwrt.org> wrote:
> On Sat, Aug 23, 2014 at 9:50 PM, Geert Uytterhoeven
> <geert@linux-m68k.org> wrote:
>> On Sat, Aug 23, 2014 at 8:31 AM, Olof Johansson <olof@lixom.net> wrote:
>>>> > arch/arm/boot/dts/<vendor>/
>>>> >
>>>> > Is this something we should do for the MIPS and update the other architectures
>>>> > to follow that scheme?
>>>>
>>>> I recall reading that as well and that it would be adopted for ARM64,
>>>> but that hasn't seemed to have happened.  Perhaps Olof (CC'ed) will no
>>>> more.
>>>
>>> Yeah, I highly recommend having a directory per vendor. We didn't on ARM,
>>> and the amount of files in that directory is becoming pretty
>>> insane. Moving to a subdirectory structure later gets messy which is
>>> why we've been holding off on it.
>>
>> It would mean we can change our scripts to operate on "interesting"
>> DTS files from
>>
>>      do-something-with $(git grep -l $vendor, -- arch/arm/boot/dts)
>>
>> to
>>
>>     do-something-with arch/arm/boot/dts/$vendor/*
>>
>> which is easier to type...
>
> Btw, do you mean chip-vendor or device-vendor with vendor?
> Device-vendor could get a bit messy on the source part as the router
> manufacturers tend to switch them quite often. E.g. d-link used arm,
> mips and ubi32 chips from marvell, ubicom, broadcom, atheros, realtek
> and ralink for their dir-615 router, happily switching back and forth.
> There are 14 known different hardware revisions of it where the chip
> differed from the previous one.

There's probably no hard and fast rule that works perfectly for
everything. Since the chip/soc generally defines most of the platform,
I would say follow the chip vendor. A few "../other-vendor/" includes
would be okay, but they should be the exception. 3rd party boards with
common daughter cards come to mind here.

Rob

Re: [PATCH 0/7] MIPS: Move device-tree files to a common location

[Rob Herring]

On Mon, Aug 25, 2014 at 10:17 AM, Jonas Gorski <jogo@openwrt.org> wrote:
> On Sat, Aug 23, 2014 at 9:50 PM, Geert Uytterhoeven
> <geert@linux-m68k.org> wrote:
>> On Sat, Aug 23, 2014 at 8:31 AM, Olof Johansson <olof@lixom.net> wrote:
>>>> > arch/arm/boot/dts/<vendor>/
>>>> >
>>>> > Is this something we should do for the MIPS and update the other architectures
>>>> > to follow that scheme?
>>>>
>>>> I recall reading that as well and that it would be adopted for ARM64,
>>>> but that hasn't seemed to have happened.  Perhaps Olof (CC'ed) will no
>>>> more.
>>>
>>> Yeah, I highly recommend having a directory per vendor. We didn't on ARM,
>>> and the amount of files in that directory is becoming pretty
>>> insane. Moving to a subdirectory structure later gets messy which is
>>> why we've been holding off on it.
>>
>> It would mean we can change our scripts to operate on "interesting"
>> DTS files from
>>
>>      do-something-with $(git grep -l $vendor, -- arch/arm/boot/dts)
>>
>> to
>>
>>     do-something-with arch/arm/boot/dts/$vendor/*
>>
>> which is easier to type...
>
> Btw, do you mean chip-vendor or device-vendor with vendor?
> Device-vendor could get a bit messy on the source part as the router
> manufacturers tend to switch them quite often. E.g. d-link used arm,
> mips and ubi32 chips from marvell, ubicom, broadcom, atheros, realtek
> and ralink for their dir-615 router, happily switching back and forth.
> There are 14 known different hardware revisions of it where the chip
> differed from the previous one.

There's probably no hard and fast rule that works perfectly for
everything. Since the chip/soc generally defines most of the platform,
I would say follow the chip vendor. A few "../other-vendor/" includes
would be okay, but they should be the exception. 3rd party boards with
common daughter cards come to mind here.

Rob