All of lore.kernel.org
 help / color / mirror / Atom feed
* [RFC 00/13] ARM: dts: DT overlay support infra + some data
@ 2018-04-17  9:10 Tero Kristo
  2018-04-17  9:10 ` [RFC 01/13] ARM: dts: allow building .dtb files under platform subdirs Tero Kristo
                   ` (13 more replies)
  0 siblings, 14 replies; 52+ messages in thread
From: Tero Kristo @ 2018-04-17  9:10 UTC (permalink / raw)
  To: devicetree, robh+dt, frowand.list, mark.rutland; +Cc: wmills, tony, trini, rmk

Hi,

This series is an attempt to start discussion on the DT overlay build time
support. Basically, one can build DT overlays directly from kernel tree,
and also build FIT images that contain the kernel + devicetree blobs
required for specific configuration that can be booted directly with
u-boot. No runtime support for overlay switching is touched by this
series.

What this series does, is to:

1) add subdir support under arch/arm/boot/dts
2) provide DT overlay build support to kernel tree
3) provide FIT image build support to kernel tree
4) provide a number of DT overlay + FIT image files for some TI SoCs
   to show the reasons why we are doing this, this is only a subset
   of our boards that we would want to use overlays with

Main reason for TI to use DT overlays right now is the rather large
amount of different displays we have around, which can be used with
different boards. With the current approach one needs to write a
separate .dts file for each board + display config, but with overlays,
one can just create a single overlay that would apply to different boards.
There are some other cases like the shown dra71-evm case in this series,
where the gpmc vs. display support is mutually exclusive, as they are
sharing certain pieces of the HW.

The main controversy with this series is most likely where the DT overlay
files should be stored at. Should they still reside with the kernel
tree or someplace else? Also, the FIT image support is probably
controversial, should it be part of the kernel build system like shown
here, or should it be separate? The zImage dependency is pretty annoying
so maybe it should be done somewhere else.

Any comments welcome as this is just an RFC for now, but basically we
would really want a solution to this problem.

-Tero


--
Texas Instruments Finland Oy, Porkkalankatu 22, 00180 Helsinki. Y-tunnus/Business ID: 0615521-4. Kotipaikka/Domicile: Helsinki

^ permalink raw reply	[flat|nested] 52+ messages in thread

* [RFC 01/13] ARM: dts: allow building .dtb files under platform subdirs
  2018-04-17  9:10 [RFC 00/13] ARM: dts: DT overlay support infra + some data Tero Kristo
@ 2018-04-17  9:10 ` Tero Kristo
  2018-04-19  0:02   ` Rob Herring
  2018-04-17  9:10 ` [RFC 02/13] ARM: dts: add support for building DT overlays Tero Kristo
                   ` (12 subsequent siblings)
  13 siblings, 1 reply; 52+ messages in thread
From: Tero Kristo @ 2018-04-17  9:10 UTC (permalink / raw)
  To: devicetree, robh+dt, frowand.list, mark.rutland; +Cc: wmills, tony, trini, rmk

Add support to base ARM makefile for building .dtb files under platform
specific subdirs (e.g. arch/arm/boot/dts/ti for TI SoCs.)

Signed-off-by: Tero Kristo <t-kristo@ti.com>
---
 arch/arm/Makefile | 4 +++-
 1 file changed, 3 insertions(+), 1 deletion(-)

diff --git a/arch/arm/Makefile b/arch/arm/Makefile
index e4e537f..f6c90bc 100644
--- a/arch/arm/Makefile
+++ b/arch/arm/Makefile
@@ -343,8 +343,10 @@ $(BOOT_TARGETS): vmlinux
 $(INSTALL_TARGETS):
 	$(Q)$(MAKE) $(build)=$(boot) MACHINE=$(MACHINE) $@
 
+%.dtb: dtbdir=$(patsubst %/,%,$(patsubst %./,%,$(boot)/dts/$(dir $@)))
+
 %.dtb: | scripts
-	$(Q)$(MAKE) $(build)=$(boot)/dts MACHINE=$(MACHINE) $(boot)/dts/$@
+	$(Q)$(MAKE) $(build)=$(dtbdir) MACHINE=$(MACHINE) $(boot)/dts/$@
 
 PHONY += dtbs dtbs_install
 
-- 
1.9.1

--
Texas Instruments Finland Oy, Porkkalankatu 22, 00180 Helsinki. Y-tunnus/Business ID: 0615521-4. Kotipaikka/Domicile: Helsinki

^ permalink raw reply	[flat|nested] 52+ messages in thread

* [RFC 02/13] ARM: dts: add support for building DT overlays
  2018-04-17  9:10 [RFC 00/13] ARM: dts: DT overlay support infra + some data Tero Kristo
  2018-04-17  9:10 ` [RFC 01/13] ARM: dts: allow building .dtb files under platform subdirs Tero Kristo
@ 2018-04-17  9:10 ` Tero Kristo
  2018-04-17  9:10 ` [RFC 03/13] ARM: dts: add subdir for TI SoC DT files Tero Kristo
                   ` (11 subsequent siblings)
  13 siblings, 0 replies; 52+ messages in thread
From: Tero Kristo @ 2018-04-17  9:10 UTC (permalink / raw)
  To: devicetree, robh+dt, frowand.list, mark.rutland; +Cc: wmills, tony, trini, rmk

Add support for building DT overlay files from the kernel DT source tree.
These can be built either from the base DT source directory, or platform
specific subdir under the base directory.

Signed-off-by: Tero Kristo <t-kristo@ti.com>
---
 arch/arm/Makefile | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/arch/arm/Makefile b/arch/arm/Makefile
index f6c90bc..ca09509 100644
--- a/arch/arm/Makefile
+++ b/arch/arm/Makefile
@@ -343,9 +343,9 @@ $(BOOT_TARGETS): vmlinux
 $(INSTALL_TARGETS):
 	$(Q)$(MAKE) $(build)=$(boot) MACHINE=$(MACHINE) $@
 
-%.dtb: dtbdir=$(patsubst %/,%,$(patsubst %./,%,$(boot)/dts/$(dir $@)))
+%.dtb %.dtbo: dtbdir=$(patsubst %/,%,$(patsubst %./,%,$(boot)/dts/$(dir $@)))
 
-%.dtb: | scripts
+%.dtb %.dtbo: | scripts
 	$(Q)$(MAKE) $(build)=$(dtbdir) MACHINE=$(MACHINE) $(boot)/dts/$@
 
 PHONY += dtbs dtbs_install
-- 
1.9.1

--
Texas Instruments Finland Oy, Porkkalankatu 22, 00180 Helsinki. Y-tunnus/Business ID: 0615521-4. Kotipaikka/Domicile: Helsinki

^ permalink raw reply	[flat|nested] 52+ messages in thread

* [RFC 03/13] ARM: dts: add subdir for TI SoC DT files
  2018-04-17  9:10 [RFC 00/13] ARM: dts: DT overlay support infra + some data Tero Kristo
  2018-04-17  9:10 ` [RFC 01/13] ARM: dts: allow building .dtb files under platform subdirs Tero Kristo
  2018-04-17  9:10 ` [RFC 02/13] ARM: dts: add support for building DT overlays Tero Kristo
@ 2018-04-17  9:10 ` Tero Kristo
  2018-04-17  9:10 ` [RFC 04/13] kbuild: add support for building %.dtbo targets Tero Kristo
                   ` (10 subsequent siblings)
  13 siblings, 0 replies; 52+ messages in thread
From: Tero Kristo @ 2018-04-17  9:10 UTC (permalink / raw)
  To: devicetree, robh+dt, frowand.list, mark.rutland; +Cc: wmills, tony, trini, rmk

Add subdir for TI SoC DT files under the main DT source directory.
Initially, this directory will only be used for DT overlay build purposes.

Signed-off-by: Tero Kristo <t-kristo@ti.com>
---
 arch/arm/boot/dts/Makefile    | 4 ++++
 arch/arm/boot/dts/ti/Makefile | 1 +
 2 files changed, 5 insertions(+)
 create mode 100644 arch/arm/boot/dts/ti/Makefile

diff --git a/arch/arm/boot/dts/Makefile b/arch/arm/boot/dts/Makefile
index 7e24249..02f28fc 100644
--- a/arch/arm/boot/dts/Makefile
+++ b/arch/arm/boot/dts/Makefile
@@ -729,6 +729,7 @@ dtb-$(CONFIG_SOC_DRA7XX) += \
 	dra72-evm-revc.dtb \
 	dra71-evm.dtb \
 	dra76-evm.dtb
+dts-dirs-$(CONFIG_SOC_DRA7XX) += ti
 dtb-$(CONFIG_ARCH_ORION5X) += \
 	orion5x-kuroboxpro.dtb \
 	orion5x-lacie-d2-network.dtb \
@@ -1163,3 +1164,6 @@ dtb-$(CONFIG_ARCH_ASPEED) += \
 	aspeed-bmc-opp-witherspoon.dtb \
 	aspeed-bmc-opp-zaius.dtb \
 	aspeed-bmc-quanta-q71l.dtb
+
+subdir-y	+= $(dts-dirs-y)
+subdir-		+= $(dts-dirs-)
diff --git a/arch/arm/boot/dts/ti/Makefile b/arch/arm/boot/dts/ti/Makefile
new file mode 100644
index 0000000..b26328b
--- /dev/null
+++ b/arch/arm/boot/dts/ti/Makefile
@@ -0,0 +1 @@
+clean-files	+= *.dtbo
-- 
1.9.1

--
Texas Instruments Finland Oy, Porkkalankatu 22, 00180 Helsinki. Y-tunnus/Business ID: 0615521-4. Kotipaikka/Domicile: Helsinki

^ permalink raw reply	[flat|nested] 52+ messages in thread

* [RFC 04/13] kbuild: add support for building %.dtbo targets
  2018-04-17  9:10 [RFC 00/13] ARM: dts: DT overlay support infra + some data Tero Kristo
                   ` (2 preceding siblings ...)
  2018-04-17  9:10 ` [RFC 03/13] ARM: dts: add subdir for TI SoC DT files Tero Kristo
@ 2018-04-17  9:10 ` Tero Kristo
  2018-04-18 14:16   ` Geert Uytterhoeven
  2018-04-17  9:10 ` [RFC 05/13] ARM: dts: ti: add support for building .dtb files containing symbols Tero Kristo
                   ` (9 subsequent siblings)
  13 siblings, 1 reply; 52+ messages in thread
From: Tero Kristo @ 2018-04-17  9:10 UTC (permalink / raw)
  To: devicetree, robh+dt, frowand.list, mark.rutland; +Cc: wmills, tony, trini, rmk

Add support for building DT overlay targets.

Signed-off-by: Tero Kristo <t-kristo@ti.com>
---
 scripts/Makefile.lib | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/scripts/Makefile.lib b/scripts/Makefile.lib
index 07d0740..95f7a17 100644
--- a/scripts/Makefile.lib
+++ b/scripts/Makefile.lib
@@ -290,6 +290,9 @@ cmd_dtc = mkdir -p $(dir ${dtc-tmp}) ; \
 $(obj)/%.dtb: $(src)/%.dts $(DTC) FORCE
 	$(call if_changed_dep,dtc)
 
+$(obj)/%.dtbo: $(src)/%.dtso $(DTC) FORCE
+	$(call if_changed_dep,dtc)
+
 dtc-tmp = $(subst $(comma),_,$(dot-target).dts.tmp)
 
 # Bzip2
-- 
1.9.1

--
Texas Instruments Finland Oy, Porkkalankatu 22, 00180 Helsinki. Y-tunnus/Business ID: 0615521-4. Kotipaikka/Domicile: Helsinki

^ permalink raw reply	[flat|nested] 52+ messages in thread

* [RFC 05/13] ARM: dts: ti: add support for building .dtb files containing symbols
  2018-04-17  9:10 [RFC 00/13] ARM: dts: DT overlay support infra + some data Tero Kristo
                   ` (3 preceding siblings ...)
  2018-04-17  9:10 ` [RFC 04/13] kbuild: add support for building %.dtbo targets Tero Kristo
@ 2018-04-17  9:10 ` Tero Kristo
  2018-04-18 14:20   ` Geert Uytterhoeven
  2018-04-17  9:10 ` [RFC 06/13] ARM: dts: am57xx-evm: add AM57xx-evm DT overlay Tero Kristo
                   ` (8 subsequent siblings)
  13 siblings, 1 reply; 52+ messages in thread
From: Tero Kristo @ 2018-04-17  9:10 UTC (permalink / raw)
  To: devicetree, robh+dt, frowand.list, mark.rutland; +Cc: wmills, tony, trini, rmk

Symbols in the DTB files are needed so that overlays can be applied
properly. Add support for building TI SoC specific .dtb files, the
source is fetched from parent directory.

Signed-off-by: Tero Kristo <t-kristo@ti.com>
---
 arch/arm/boot/dts/ti/Makefile | 5 +++++
 1 file changed, 5 insertions(+)

diff --git a/arch/arm/boot/dts/ti/Makefile b/arch/arm/boot/dts/ti/Makefile
index b26328b..7d2d411 100644
--- a/arch/arm/boot/dts/ti/Makefile
+++ b/arch/arm/boot/dts/ti/Makefile
@@ -1 +1,6 @@
+DTC_FLAGS += -@ -Wno-reg_format -Wno-avoid_default_addr_size
+
+$(obj)/%.dtb: $(src)/../%.dts FORCE
+	$(call if_changed_dep,dtc)
+
 clean-files	+= *.dtbo
-- 
1.9.1

--
Texas Instruments Finland Oy, Porkkalankatu 22, 00180 Helsinki. Y-tunnus/Business ID: 0615521-4. Kotipaikka/Domicile: Helsinki

^ permalink raw reply	[flat|nested] 52+ messages in thread

* [RFC 06/13] ARM: dts: am57xx-evm: add AM57xx-evm DT overlay
  2018-04-17  9:10 [RFC 00/13] ARM: dts: DT overlay support infra + some data Tero Kristo
                   ` (4 preceding siblings ...)
  2018-04-17  9:10 ` [RFC 05/13] ARM: dts: ti: add support for building .dtb files containing symbols Tero Kristo
@ 2018-04-17  9:10 ` Tero Kristo
  2018-04-18 14:36   ` Geert Uytterhoeven
  2018-04-19  0:19   ` Rob Herring
  2018-04-17  9:10 ` [RFC 07/13] ARM: dts: ti: add camera overlays Tero Kristo
                   ` (7 subsequent siblings)
  13 siblings, 2 replies; 52+ messages in thread
From: Tero Kristo @ 2018-04-17  9:10 UTC (permalink / raw)
  To: devicetree, robh+dt, frowand.list, mark.rutland; +Cc: wmills, tony, trini, rmk

The AM57xx-evm is an overlay on top of beagle-x15 board. This contains
a display extension macro, and a few extra peripherals. Two versions
of the evm are supported, the base evm and the latest rev A3 evm. A
common overlay file is used for both boards.

Signed-off-by: Tero Kristo <t-kristo@ti.com>
---
 arch/arm/boot/dts/ti/am57xx-evm-common.dtso | 175 ++++++++++++++++++++++++++++
 arch/arm/boot/dts/ti/am57xx-evm-reva3.dtso  |  11 ++
 arch/arm/boot/dts/ti/am57xx-evm.dtso        |  11 ++
 3 files changed, 197 insertions(+)
 create mode 100644 arch/arm/boot/dts/ti/am57xx-evm-common.dtso
 create mode 100644 arch/arm/boot/dts/ti/am57xx-evm-reva3.dtso
 create mode 100644 arch/arm/boot/dts/ti/am57xx-evm.dtso

diff --git a/arch/arm/boot/dts/ti/am57xx-evm-common.dtso b/arch/arm/boot/dts/ti/am57xx-evm-common.dtso
new file mode 100644
index 0000000..68c3937
--- /dev/null
+++ b/arch/arm/boot/dts/ti/am57xx-evm-common.dtso
@@ -0,0 +1,175 @@
+/dts-v1/;
+/plugin/;
+#include <dt-bindings/interrupt-controller/irq.h>
+#include <dt-bindings/gpio/gpio.h>
+#include <dt-bindings/input/input.h>
+
+/ {
+  fragment@101 {
+	target-path = "/";
+
+	__overlay__ {
+		compatible = "ti,am5728-evm", "ti,am572x-beagle-x15", "ti,am5728", "ti,dra742", "ti,dra74", "ti,dra7";
+		model = "TI AM5728 EVM";
+
+		aliases {
+			display0 = "/display";
+			display1 = "/connector";
+		};
+
+		gpio_keys {
+			compatible = "gpio-keys";
+			#address-cells = <1>;
+			#size-cells = <0>;
+			autorepeat;
+
+			USER1 {
+				gpios = <&gpio2 23 GPIO_ACTIVE_LOW>;
+				label = "Up";
+				linux,code = <KEY_UP>;
+			};
+
+			USER2 {
+				gpios = <&gpio2 25 GPIO_ACTIVE_LOW>;
+				label = "Down";
+				linux,code = <KEY_DOWN>;
+			};
+
+			USER3 {
+				gpios = <&gpio2 28 GPIO_ACTIVE_LOW>;
+				label = "Left";
+				linux,code = <KEY_LEFT>;
+			};
+
+			USER4 {
+				gpios = <&gpio2 24 GPIO_ACTIVE_LOW>;
+				label = "Right";
+				linux,code = <KEY_RIGHT>;
+			};
+
+			USER5 {
+				gpios = <&gpio2 20 GPIO_ACTIVE_LOW>;
+				label = "Home";
+				linux,code = <KEY_HOME>;
+			};
+		};
+
+		lcd0: display {
+			compatible = "osddisplays,osd070t1718-19ts", "panel-dpi";
+			backlight = <&lcd_bl>;
+			enable-gpios = <&gpio2 5 GPIO_ACTIVE_HIGH>;
+			label = "lcd";
+
+			panel-timing {
+				clock-frequency = <33000000>;
+				de-active = <1>;
+				hactive = <800>;
+				hback-porch = <16>;
+				hfront-porch = <210>;
+				hsync-active = <0>;
+				hsync-len = <30>;
+				pixelclk-active = <1>;
+				vactive = <480>;
+				vback-porch = <10>;
+				vfront-porch = <22>;
+				vsync-active = <0>;
+				vsync-len = <13>;
+			};
+
+			port {
+				lcd_in: endpoint {
+					remote-endpoint = <&dpi_out>;
+				};
+			};
+		};
+
+		lcd_bl: backlight {
+			compatible = "pwm-backlight";
+			brightness-levels = <0 243 245 247 249 251 252 253 255>;
+			default-brightness-level = <8>;
+			pwms = <&ehrpwm1 0 50000 0>;
+		};
+
+		com_3v6: fixedregulator-com_3v6 {
+			compatible = "regulator-fixed";
+			regulator-name = "com_3v6";
+			regulator-min-microvolt = <3600000>;
+			regulator-max-microvolt = <3600000>;
+			vin-supply = <&evm_5v0>;
+			regulator-always-on;
+			regulator-boot-on;
+		};
+
+		vmmcwl_fixed: fixedregulator-mmcwl {
+			compatible = "regulator-fixed";
+			regulator-name = "vmmcwl_fixed";
+			regulator-min-microvolt = <1800000>;
+			regulator-max-microvolt = <1800000>;
+			gpio = <&gpio5 8 GPIO_ACTIVE_HIGH>;
+			enable-active-high;
+		};
+	};
+  };
+};
+
+&ehrpwm1 {
+	status = "okay";
+};
+
+&epwmss1 {
+	status = "okay";
+};
+
+&i2c5 {
+	clock-frequency = <400000>;
+	status = "okay";
+
+	pixcir_ts@5c {
+		compatible = "pixcir,pixcir_tangoc";
+		attb-gpio = <&gpio2 4 GPIO_ACTIVE_HIGH>;
+		interrupt-parent = <&gpio2>;
+		interrupts = <4 0>;
+		reg = <0x5c>;
+		reset-gpio = <&gpio2 6 GPIO_ACTIVE_HIGH>;
+		touchscreen-size-x = <1024>;
+		touchscreen-size-y = <600>;
+	};
+};
+
+&uart8 {
+	status = "okay";
+};
+
+&dss {
+	ports {
+		#address-cells = <1>;
+		#size-cells = <0>;
+
+		port {
+			reg = <0>;
+
+			dpi_out: endpoint {
+				data-lines = <24>;
+				remote-endpoint = <&lcd_in>;
+			};
+		};
+	};
+};
+
+&mmc3 {
+	status = "okay";
+	vmmc-supply = <&com_3v6>;
+	vqmmc-supply = <&vmmcwl_fixed>;
+	bus-width = <4>;
+	cap-power-off-card;
+	keep-power-in-suspend;
+	non-removable;
+	#address-cells = <1>;
+	#size-cells = <0>;
+	wlcore: wlcore@2 {
+		compatible = "ti,wl1835";
+		reg = <2>;
+		interrupt-parent = <&gpio5>;
+		interrupts = <7 IRQ_TYPE_EDGE_RISING>;
+	};
+};
diff --git a/arch/arm/boot/dts/ti/am57xx-evm-reva3.dtso b/arch/arm/boot/dts/ti/am57xx-evm-reva3.dtso
new file mode 100644
index 0000000..17e778f
--- /dev/null
+++ b/arch/arm/boot/dts/ti/am57xx-evm-reva3.dtso
@@ -0,0 +1,11 @@
+/dts-v1/;
+/plugin/;
+
+&mmc3 {
+	pinctrl-names = "default", "hs", "sdr12", "sdr25", "sdr50";
+	pinctrl-0 = <&mmc3_pins_default>;
+	pinctrl-1 = <&mmc3_pins_hs>;
+	pinctrl-2 = <&mmc3_pins_sdr12>;
+	pinctrl-3 = <&mmc3_pins_sdr25>;
+	pinctrl-4 = <&mmc3_pins_sdr50 &mmc3_iodelay_manual1_rev20_conf>;
+};
diff --git a/arch/arm/boot/dts/ti/am57xx-evm.dtso b/arch/arm/boot/dts/ti/am57xx-evm.dtso
new file mode 100644
index 0000000..91a57e9
--- /dev/null
+++ b/arch/arm/boot/dts/ti/am57xx-evm.dtso
@@ -0,0 +1,11 @@
+/dts-v1/;
+/plugin/;
+
+&mmc3 {
+	pinctrl-names = "default", "hs", "sdr12", "sdr25", "sdr50";
+	pinctrl-0 = <&mmc3_pins_default>;
+	pinctrl-1 = <&mmc3_pins_hs>;
+	pinctrl-2 = <&mmc3_pins_sdr12>;
+	pinctrl-3 = <&mmc3_pins_sdr25>;
+	pinctrl-4 = <&mmc3_pins_sdr50 &mmc3_iodelay_manual1_rev11_conf>;
+};
-- 
1.9.1

--
Texas Instruments Finland Oy, Porkkalankatu 22, 00180 Helsinki. Y-tunnus/Business ID: 0615521-4. Kotipaikka/Domicile: Helsinki

^ permalink raw reply	[flat|nested] 52+ messages in thread

* [RFC 07/13] ARM: dts: ti: add camera overlays
  2018-04-17  9:10 [RFC 00/13] ARM: dts: DT overlay support infra + some data Tero Kristo
                   ` (5 preceding siblings ...)
  2018-04-17  9:10 ` [RFC 06/13] ARM: dts: am57xx-evm: add AM57xx-evm DT overlay Tero Kristo
@ 2018-04-17  9:10 ` Tero Kristo
  2018-04-17  9:10 ` [RFC 08/13] ARM: dts: ti: add dra71-evm overlays Tero Kristo
                   ` (6 subsequent siblings)
  13 siblings, 0 replies; 52+ messages in thread
From: Tero Kristo @ 2018-04-17  9:10 UTC (permalink / raw)
  To: devicetree, robh+dt, frowand.list, mark.rutland
  Cc: wmills, tony, trini, rmk, Benoit Parrot

From: Benoit Parrot <bparrot@ti.com>

Add two different camera overlays for am57xx-evm, mt9t111 and ov10635.

Signed-off-by: Benoit Parrot <bparrot@ti.com>
Signed-off-by: Tero Kristo <t-kristo@ti.com>
---
 arch/arm/boot/dts/ti/mt9t111.dtso | 44 ++++++++++++++++++++++++
 arch/arm/boot/dts/ti/ov10635.dtso | 71 +++++++++++++++++++++++++++++++++++++++
 2 files changed, 115 insertions(+)
 create mode 100644 arch/arm/boot/dts/ti/mt9t111.dtso
 create mode 100644 arch/arm/boot/dts/ti/ov10635.dtso

diff --git a/arch/arm/boot/dts/ti/mt9t111.dtso b/arch/arm/boot/dts/ti/mt9t111.dtso
new file mode 100644
index 0000000..80e77ae
--- /dev/null
+++ b/arch/arm/boot/dts/ti/mt9t111.dtso
@@ -0,0 +1,44 @@
+// SPDX-License-Identifier: GPL-2.0
+/*
+ * Copyright (C) 2015-2018 Texas Instruments Incorporated - http://www.ti.com/
+ */
+
+/dts-v1/;
+/plugin/;
+#include <dt-bindings/gpio/gpio.h>
+
+&i2c5 {
+	mt9t11x@3C {
+		compatible = "aptina,mt9t111";
+		bufen-gpios = <&gpio5 12 GPIO_ACTIVE_LOW>;
+		camen-gpios = <&gpio6 11 GPIO_ACTIVE_LOW>;
+		oscen-gpios = <&gpio5 10 GPIO_ACTIVE_HIGH>;
+		powerdown-gpios = <&gpio5 11 GPIO_ACTIVE_LOW>;
+		reg = <0x3C>;
+		reset-gpios = <&gpio4 17 GPIO_ACTIVE_LOW>;
+
+		port {
+			cam: endpoint {
+				hsync-active = <1>;
+				input-clock-freq = <32000000>;
+				pclk-sample = <0>;
+				pixel-clock-freq = <96000000>;
+				remote-endpoint = <&vin3a>;
+				vsync-active = <0>;
+			};
+		};
+	};
+};
+
+&vin3a {
+	status = "okay";
+
+	endpoint {
+		remote-endpoint = <&cam>;
+		slave-mode;
+	};
+};
+
+&vip2 {
+	status = "okay";
+};
diff --git a/arch/arm/boot/dts/ti/ov10635.dtso b/arch/arm/boot/dts/ti/ov10635.dtso
new file mode 100644
index 0000000..856f5de
--- /dev/null
+++ b/arch/arm/boot/dts/ti/ov10635.dtso
@@ -0,0 +1,71 @@
+// SPDX-License-Identifier: GPL-2.0
+/*
+ * Copyright (C) 2015-2018 Texas Instruments Incorporated - http://www.ti.com/
+ */
+
+/dts-v1/;
+/plugin/;
+#include <dt-bindings/gpio/gpio.h>
+
+/ {
+  fragment@101 {
+	target-path = "/";
+
+	__overlay__ {
+		clk_ov10635: clk_ov10635 {
+			compatible = "gpio-gate-clock";
+			#clock-cells = <0>;
+			clocks = <&clk_ov10635_fixed>;
+			enable-gpios = <&gpio5 10 GPIO_ACTIVE_HIGH>;
+		};
+
+		clk_ov10635_fixed: clk_ov10635_fixed {
+			compatible = "fixed-clock";
+			#clock-cells = <0>;
+			clock-frequency = <24000000>;
+		};
+	};
+  };
+};
+
+&i2c5 {
+	ov10635@30 {
+		compatible = "ovti,ov10635";
+		clock-names = "xvclk";
+		clocks = <&clk_ov10635>;
+		powerdown-gpios = <&gpio5 11 GPIO_ACTIVE_HIGH>;
+		reg = <0x30>;
+		reset-gpios = <&gpio4 17 GPIO_ACTIVE_HIGH>;
+
+		port {
+			cam: endpoint {
+				hsync-active = <1>;
+				pclk-sample = <1>;
+				remote-endpoint = <&vin3a>;
+				vsync-active = <1>;
+			};
+		};
+	};
+};
+
+&vin3a {
+	status = "okay";
+
+	endpoint {
+		remote-endpoint = <&cam>;
+		slave-mode;
+	};
+};
+
+&vip2 {
+	status = "okay";
+};
+
+&gpio6 {
+	p11 {
+		gpio-hog;
+		gpios = <11 GPIO_ACTIVE_LOW>;
+		line-name = "cm-camen-gpio";
+		output-high;
+	};
+};
-- 
1.9.1

--
Texas Instruments Finland Oy, Porkkalankatu 22, 00180 Helsinki. Y-tunnus/Business ID: 0615521-4. Kotipaikka/Domicile: Helsinki

^ permalink raw reply	[flat|nested] 52+ messages in thread

* [RFC 08/13] ARM: dts: ti: add dra71-evm overlays
  2018-04-17  9:10 [RFC 00/13] ARM: dts: DT overlay support infra + some data Tero Kristo
                   ` (6 preceding siblings ...)
  2018-04-17  9:10 ` [RFC 07/13] ARM: dts: ti: add camera overlays Tero Kristo
@ 2018-04-17  9:10 ` Tero Kristo
  2018-04-17  9:10 ` [RFC 09/13] kbuild: add support for generating FIT images Tero Kristo
                   ` (5 subsequent siblings)
  13 siblings, 0 replies; 52+ messages in thread
From: Tero Kristo @ 2018-04-17  9:10 UTC (permalink / raw)
  To: devicetree, robh+dt, frowand.list, mark.rutland; +Cc: wmills, tony, trini, rmk

Add dra71-evm overlay files. There are two overlays available, the gpmc
and the display ones. These are mutually exclusive, as they share certain
hardware resources.

Signed-off-by: Tero Kristo <t-kristo@ti.com>
---
 .../boot/dts/ti/dra71-evm-lcd-auo-g101evn01.0.dtso | 121 +++++++++++++++++++++
 arch/arm/boot/dts/ti/dra71-evm-nand.dtso           |   6 +
 2 files changed, 127 insertions(+)
 create mode 100644 arch/arm/boot/dts/ti/dra71-evm-lcd-auo-g101evn01.0.dtso
 create mode 100644 arch/arm/boot/dts/ti/dra71-evm-nand.dtso

diff --git a/arch/arm/boot/dts/ti/dra71-evm-lcd-auo-g101evn01.0.dtso b/arch/arm/boot/dts/ti/dra71-evm-lcd-auo-g101evn01.0.dtso
new file mode 100644
index 0000000..bebfe43
--- /dev/null
+++ b/arch/arm/boot/dts/ti/dra71-evm-lcd-auo-g101evn01.0.dtso
@@ -0,0 +1,121 @@
+/dts-v1/;
+/plugin/;
+#include <dt-bindings/interrupt-controller/irq.h>
+#include <dt-bindings/gpio/gpio.h>
+
+/ {
+  fragment@101 {
+	target-path = "/";
+
+	__overlay__ {
+		model = "TI DRA71 EVM-LCD-AUO-Display";
+
+		aliases {
+			display0 = "/display";
+			display1 = "/connector";
+		};
+
+		backlight {
+			compatible = "led-backlight";
+			brightness-levels = <0 2 38 74 110 146 182 218 255>;
+			default-brightness-level = <8>;
+			enable-gpios = <&pcf_display_board 0 GPIO_ACTIVE_LOW>;
+			leds = <&backlight_led>;
+		};
+
+		lcd: display {
+			compatible = "auo,g101evn01.0", "panel-dpi";
+			enable-gpios = <&pcf_lcd 13 GPIO_ACTIVE_LOW>;
+			label = "lcd";
+
+			panel-timing {
+				clock-frequency = <68930000>;
+				de-active = <1>;
+				hactive = <1280>;
+				hback-porch = <48>;
+				hfront-porch = <48>;
+				hsync-active = <0>;
+				hsync-len = <32>;
+				pixelclk-active = <1>;
+				vactive = <800>;
+				vback-porch = <8>;
+				vfront-porch = <4>;
+				vsync-active = <0>;
+				vsync-len = <4>;
+			};
+
+			port {
+				lcd_in: endpoint {
+					remote-endpoint = <&dpi_out>;
+				};
+			};
+		};
+	};
+  };
+};
+
+&pcf_gpio_21 {
+	p0 {
+		gpio-hog;
+		gpios = <0 GPIO_ACTIVE_HIGH>;
+		line-name = "sel_gpmc_ad_vid_s0";
+		output-low;
+	};
+
+	p7 {
+		gpio-hog;
+		gpios = <7 GPIO_ACTIVE_HIGH>;
+		line-name = "sel_gpmc_ad_vid_s2";
+		output-high;
+	};
+};
+
+&i2c1 {
+	pcf_display_board: gpio@27 {
+		compatible = "nxp,pcf8575";
+		#gpio-cells = <2>;
+		gpio-controller;
+		reg = <0x27>;
+	};
+
+	tlc59108@40 {
+		compatible = "ti,tlc59108";
+		#address-cells = <1>;
+		#size-cells = <0>;
+		reg = <0x40>;
+
+		backlight_led: bl@2 {
+			label = "backlight";
+			reg = <0x2>;
+		};
+	};
+
+	touchscreen: goodix-gt9271@14 {
+		compatible = "goodix,gt9271";
+		interrupt-parent = <&gpio1>;
+		interrupts = <15 IRQ_TYPE_LEVEL_HIGH>;
+		irq-gpios = <&pcf_display_board 6 GPIO_ACTIVE_HIGH>;
+		reg = <0x14>;
+		reset-gpios = <&pcf_display_board 5 GPIO_ACTIVE_LOW>;
+		status = "okay";
+		touchscreen-inverted-y;
+		touchscreen-size-x = <1280>;
+		touchscreen-size-y = <800>;
+	};
+};
+
+&dss {
+	ports {
+		#address-cells = <1>;
+		#size-cells = <0>;
+
+		dss_port: port {
+			reg = <2>;
+
+			dpi_out: endpoint {
+				data-lines = <24>;
+				remote-endpoint = <&lcd_in>;
+			};
+		};
+	};
+};
diff --git a/arch/arm/boot/dts/ti/dra71-evm-nand.dtso b/arch/arm/boot/dts/ti/dra71-evm-nand.dtso
new file mode 100644
index 0000000..280b0ba
--- /dev/null
+++ b/arch/arm/boot/dts/ti/dra71-evm-nand.dtso
@@ -0,0 +1,6 @@
+/dts-v1/;
+/plugin/;
+
+&gpmc {
+	status = "okay";
+};
-- 
1.9.1

--
Texas Instruments Finland Oy, Porkkalankatu 22, 00180 Helsinki. Y-tunnus/Business ID: 0615521-4. Kotipaikka/Domicile: Helsinki

^ permalink raw reply	[flat|nested] 52+ messages in thread

* [RFC 09/13] kbuild: add support for generating FIT images
  2018-04-17  9:10 [RFC 00/13] ARM: dts: DT overlay support infra + some data Tero Kristo
                   ` (7 preceding siblings ...)
  2018-04-17  9:10 ` [RFC 08/13] ARM: dts: ti: add dra71-evm overlays Tero Kristo
@ 2018-04-17  9:10 ` Tero Kristo
  2018-04-17  9:10 ` [RFC 10/13] ARM: dts: add FIT image build support for ARM architecture Tero Kristo
                   ` (4 subsequent siblings)
  13 siblings, 0 replies; 52+ messages in thread
From: Tero Kristo @ 2018-04-17  9:10 UTC (permalink / raw)
  To: devicetree, robh+dt, frowand.list, mark.rutland; +Cc: wmills, tony, trini, rmk

FIT images are built with the mkimage tool, from source description
similar to that of DT files. There are a few FIT image generation
specifics that must be noted with this patch.

The dependency generation for the FIT files requires some makefile
magic, due to the build ordering; the dependency binaries must have
been built before the FIT image itself, which is different from typical
kernel build flow (source files are be built immediately and dependencies
can be generated during build.) To use the generated dependency files,
the user must manually include the local .itb-deps.d file in their makefile.

The PATH environment variable while calling the mkimage tool is tweaked
to contain the local / user provided DTC as first item, so that the
correct version of mkimage tool will be used. Otherwise, the build will
use the system default DTC, or won't find the tool at all.

Signed-off-by: Tero Kristo <t-kristo@ti.com>
---
 scripts/Makefile.lib | 32 ++++++++++++++++++++++++++++++++
 1 file changed, 32 insertions(+)

diff --git a/scripts/Makefile.lib b/scripts/Makefile.lib
index 95f7a17..18517ea 100644
--- a/scripts/Makefile.lib
+++ b/scripts/Makefile.lib
@@ -295,6 +295,38 @@ $(obj)/%.dtbo: $(src)/%.dtso $(DTC) FORCE
 
 dtc-tmp = $(subst $(comma),_,$(dot-target).dts.tmp)
 
+# FIT
+# ---------------------------------------------------------------------------
+define gen_itb_deps
+	@if [ -d $(obj) ] ; then \
+		echo >> $(obj)/.itb-deps.d ; \
+		echo "$(src)/$(patsubst %.its,%.itb,$(notdir $(1))): $(srctree)/$(src)/$(notdir $(1)) \\" >> $(obj)/.itb-deps.d ; \
+		cat $(1) | grep incbin | cut -d "\"" -f 2 | awk '{ printf " $(src)/%s \\\n", $$1 }' | sed '$$s/ \\$$//' >> $(obj)/.itb-deps.d ; \
+	fi
+
+endef
+
+$(obj)/.itb-deps.d:
+	@if [ -d $(obj) ] ; then \
+		echo "$(src)/.itb-deps.d: $(src)/Makefile $(wildcard $(srctree)/$(src)/*.its)" > $(obj)/.itb-deps.d ; \
+		echo >> $(obj)/.itb-deps.d ; \
+	fi
+	$(foreach f,$(wildcard $(srctree)/$(src)/*.its),$(call gen_itb_deps,$f))
+
+DTC_FLAGS_MKIMAGE = -I dts -O dtb -p 500 -Wno-unit_address_vs_reg \
+	-i $(src)
+ifneq ($(DTC),)
+  DTC_PATH=$(dir $(DTC))
+else
+  DTC_PATH=$(objtree)/scripts/dtc
+endif
+
+quiet_cmd_mkdir = MKIMAGE -f $@
+cmd_mkfit = PATH="$(DTC_PATH):$(PATH)" $(MKIMAGE) -D "$(DTC_FLAGS_MKIMAGE)" -f $< $@
+
+$(obj)/%.itb: $(src)/%.its FORCE
+	$(call cmd,mkfit)
+
 # Bzip2
 # ---------------------------------------------------------------------------
 
-- 
1.9.1

--
Texas Instruments Finland Oy, Porkkalankatu 22, 00180 Helsinki. Y-tunnus/Business ID: 0615521-4. Kotipaikka/Domicile: Helsinki

^ permalink raw reply	[flat|nested] 52+ messages in thread

* [RFC 10/13] ARM: dts: add FIT image build support for ARM architecture
  2018-04-17  9:10 [RFC 00/13] ARM: dts: DT overlay support infra + some data Tero Kristo
                   ` (8 preceding siblings ...)
  2018-04-17  9:10 ` [RFC 09/13] kbuild: add support for generating FIT images Tero Kristo
@ 2018-04-17  9:10 ` Tero Kristo
  2018-04-17  9:10 ` [RFC 11/13] ARM: dts: ti: add FIT image dependencies Tero Kristo
                   ` (3 subsequent siblings)
  13 siblings, 0 replies; 52+ messages in thread
From: Tero Kristo @ 2018-04-17  9:10 UTC (permalink / raw)
  To: devicetree, robh+dt, frowand.list, mark.rutland; +Cc: wmills, tony, trini, rmk

Add basic .itb build target for ARM architecture. FIT images generally
contain the kernel and different DTB + overlay files, so an extra
dependency is made towards zImage being available.

Signed-off-by: Tero Kristo <t-kristo@ti.com>
---
 arch/arm/Makefile | 5 ++++-
 1 file changed, 4 insertions(+), 1 deletion(-)

diff --git a/arch/arm/Makefile b/arch/arm/Makefile
index ca09509..8d4811b 100644
--- a/arch/arm/Makefile
+++ b/arch/arm/Makefile
@@ -343,11 +343,14 @@ $(BOOT_TARGETS): vmlinux
 $(INSTALL_TARGETS):
 	$(Q)$(MAKE) $(build)=$(boot) MACHINE=$(MACHINE) $@
 
-%.dtb %.dtbo: dtbdir=$(patsubst %/,%,$(patsubst %./,%,$(boot)/dts/$(dir $@)))
+%.dtb %.dtbo %.itb: dtbdir=$(patsubst %/,%,$(patsubst %./,%,$(boot)/dts/$(dir $@)))
 
 %.dtb %.dtbo: | scripts
 	$(Q)$(MAKE) $(build)=$(dtbdir) MACHINE=$(MACHINE) $(boot)/dts/$@
 
+%.itb: | scripts zImage
+	$(Q)$(MAKE) $(build)=$(dtbdir) MACHINE=$(MACHINE) $(boot)/dts/$@
+
 PHONY += dtbs dtbs_install
 
 dtbs: prepare scripts
-- 
1.9.1

--
Texas Instruments Finland Oy, Porkkalankatu 22, 00180 Helsinki. Y-tunnus/Business ID: 0615521-4. Kotipaikka/Domicile: Helsinki

^ permalink raw reply	[flat|nested] 52+ messages in thread

* [RFC 11/13] ARM: dts: ti: add FIT image dependencies
  2018-04-17  9:10 [RFC 00/13] ARM: dts: DT overlay support infra + some data Tero Kristo
                   ` (9 preceding siblings ...)
  2018-04-17  9:10 ` [RFC 10/13] ARM: dts: add FIT image build support for ARM architecture Tero Kristo
@ 2018-04-17  9:10 ` Tero Kristo
  2018-04-17  9:10 ` [RFC 12/13] ARM: dts: ti: add dra71-evm FIT description file Tero Kristo
                   ` (2 subsequent siblings)
  13 siblings, 0 replies; 52+ messages in thread
From: Tero Kristo @ 2018-04-17  9:10 UTC (permalink / raw)
  To: devicetree, robh+dt, frowand.list, mark.rutland; +Cc: wmills, tony, trini, rmk

Add the local FIT image dependencies file to build. This allows building
the FIT image dependency file before building the FIT image, and to build
the dependencies themselves also next. Without this, none of the binaries
required by the FIT image will be found.

Also, add the built FIT images to the clean targets.

Signed-off-by: Tero Kristo <t-kristo@ti.com>
---
 arch/arm/boot/dts/ti/Makefile | 4 +++-
 1 file changed, 3 insertions(+), 1 deletion(-)

diff --git a/arch/arm/boot/dts/ti/Makefile b/arch/arm/boot/dts/ti/Makefile
index 7d2d411..3ba8164 100644
--- a/arch/arm/boot/dts/ti/Makefile
+++ b/arch/arm/boot/dts/ti/Makefile
@@ -1,6 +1,8 @@
 DTC_FLAGS += -@ -Wno-reg_format -Wno-avoid_default_addr_size
 
+-include $(obj)/.itb-deps.d
+
 $(obj)/%.dtb: $(src)/../%.dts FORCE
 	$(call if_changed_dep,dtc)
 
-clean-files	+= *.dtbo
+clean-files	+= *.dtbo *.itb
-- 
1.9.1

--
Texas Instruments Finland Oy, Porkkalankatu 22, 00180 Helsinki. Y-tunnus/Business ID: 0615521-4. Kotipaikka/Domicile: Helsinki

^ permalink raw reply	[flat|nested] 52+ messages in thread

* [RFC 12/13] ARM: dts: ti: add dra71-evm FIT description file
  2018-04-17  9:10 [RFC 00/13] ARM: dts: DT overlay support infra + some data Tero Kristo
                   ` (10 preceding siblings ...)
  2018-04-17  9:10 ` [RFC 11/13] ARM: dts: ti: add FIT image dependencies Tero Kristo
@ 2018-04-17  9:10 ` Tero Kristo
  2018-04-17  9:29   ` Russell King
  2018-04-17  9:10 ` [RFC 13/13] ARM: dts: ti: add am57xx-evm " Tero Kristo
  2018-04-17  9:18 ` [RFC 00/13] ARM: dts: DT overlay support infra + some data Russell King
  13 siblings, 1 reply; 52+ messages in thread
From: Tero Kristo @ 2018-04-17  9:10 UTC (permalink / raw)
  To: devicetree, robh+dt, frowand.list, mark.rutland; +Cc: wmills, tony, trini, rmk

Add FIT image description file for dra71-evm, and the available
configurations for it.

Signed-off-by: Tero Kristo <t-kristo@ti.com>
---
 arch/arm/boot/dts/ti/dra71-evm.its | 62 ++++++++++++++++++++++++++++++++++++++
 1 file changed, 62 insertions(+)
 create mode 100644 arch/arm/boot/dts/ti/dra71-evm.its

diff --git a/arch/arm/boot/dts/ti/dra71-evm.its b/arch/arm/boot/dts/ti/dra71-evm.its
new file mode 100644
index 0000000..8dc53cb
--- /dev/null
+++ b/arch/arm/boot/dts/ti/dra71-evm.its
@@ -0,0 +1,62 @@
+/dts-v1/;
+
+/ {
+	description = "DRA71x-evm";
+	#address-cells = <1>;
+
+	images {
+		kernel@1 {
+			description = "Linux kernel";
+			data = /incbin/("../../zImage");
+			type = "kernel";
+			arch = "arm";
+			os = "linux";
+			compression = "none";
+			load = <0x82000000>;
+			entry = <0x82000000>;
+		};
+		fdt@1 {
+			description = "DRA71x-evm";
+			data = /incbin/("dra71-evm.dtb");
+			type = "flat_dt";
+			arch = "arm";
+			compression = "none";
+			load = <0x83000000>;
+		};
+		fdt@2 {
+			description = "DRA71x-evm LCD";
+			data = /incbin/("dra71-evm-lcd-auo-g101evn01.0.dtbo");
+			type = "flat_dt";
+			arch = "arm";
+			compression = "none";
+			load = <0x83100000>;
+		};
+		fdt@3 {
+			description = "DRA71x-evm NAND";
+			data = /incbin/("dra71-evm-nand.dtbo");
+			type = "flat_dt";
+			arch = "arm";
+			compression = "none";
+			load = <0x83200000>;
+		};
+	};
+
+	configurations {
+		default = "dra71-evm";
+		dra71-evm {
+			description = "DRA71x-evm";
+			kernel = "kernel@1";
+			fdt = "fdt@1";
+		};
+		dra71-evm-lcd-auo-g101evn01.0 {
+			description = "DRA71x-evm with LCD overlay";
+			kernel = "kernel@1";
+			fdt = "fdt@1", "fdt@2";
+		};
+		dra71-evm-nand {
+			description = "DRA71x-evm with NAND overlay";
+			kernel = "kernel@1";
+			fdt = "fdt@1", "fdt@3";
+		};
+	};
+};
-- 
1.9.1

--
Texas Instruments Finland Oy, Porkkalankatu 22, 00180 Helsinki. Y-tunnus/Business ID: 0615521-4. Kotipaikka/Domicile: Helsinki

^ permalink raw reply	[flat|nested] 52+ messages in thread

* [RFC 13/13] ARM: dts: ti: add am57xx-evm FIT description file
  2018-04-17  9:10 [RFC 00/13] ARM: dts: DT overlay support infra + some data Tero Kristo
                   ` (11 preceding siblings ...)
  2018-04-17  9:10 ` [RFC 12/13] ARM: dts: ti: add dra71-evm FIT description file Tero Kristo
@ 2018-04-17  9:10 ` Tero Kristo
  2018-04-17  9:18 ` [RFC 00/13] ARM: dts: DT overlay support infra + some data Russell King
  13 siblings, 0 replies; 52+ messages in thread
From: Tero Kristo @ 2018-04-17  9:10 UTC (permalink / raw)
  To: devicetree, robh+dt, frowand.list, mark.rutland; +Cc: wmills, tony, trini, rmk

Add FIT image description file for am57xx-evm, which contains the
available configurations for the board.

Signed-off-by: Tero Kristo <t-kristo@ti.com>
---
 arch/arm/boot/dts/ti/am57xx-evm.its | 97 +++++++++++++++++++++++++++++++++++++
 1 file changed, 97 insertions(+)
 create mode 100644 arch/arm/boot/dts/ti/am57xx-evm.its

diff --git a/arch/arm/boot/dts/ti/am57xx-evm.its b/arch/arm/boot/dts/ti/am57xx-evm.its
new file mode 100644
index 0000000..cd5523c
--- /dev/null
+++ b/arch/arm/boot/dts/ti/am57xx-evm.its
@@ -0,0 +1,97 @@
+/dts-v1/;
+
+/ {
+	description = "AM57xx-evm";
+	#address-cells = <1>;
+
+	images {
+		kernel@1 {
+			description = "Linux kernel";
+			data = /incbin/("../../zImage");
+			type = "kernel";
+			arch = "arm";
+			os = "linux";
+			compression = "none";
+			load = <0x82000000>;
+			entry = <0x82000000>;
+		};
+		fdt@1 {
+			description = "AM57xx-beagle-x15";
+			data = /incbin/("am57xx-beagle-x15.dtb");
+			type = "flat_dt";
+			arch = "arm";
+			compression = "none";
+			load = <0x83000000>;
+		};
+		fdt@2 {
+			description = "AM57xx-beagle-x15-revc";
+			data = /incbin/("am57xx-beagle-x15-revc.dtb");
+			type = "flat_dt";
+			arch = "arm";
+			compression = "none";
+			load = <0x83000000>;
+		};
+		fdt@3 {
+			description = "AM57xx-evm-common overlay";
+			data = /incbin/("am57xx-evm-common.dtbo");
+			type = "flat_dt";
+			arch = "arm";
+			compression = "none";
+			load = <0x83080000>;
+		};
+		fdt@4 {
+			description = "MT9T111 camera support";
+			data = /incbin/("mt9t111.dtbo");
+			type = "flat_dt";
+			arch = "arm";
+			compression = "none";
+			load = <0x83100000>;
+		};
+		fdt@5 {
+			description = "OV10635 camera support";
+			data = /incbin/("ov10635.dtbo");
+			type = "flat_dt";
+			arch = "arm";
+			compression = "none";
+			load = <0x83100000>;
+		};
+		fdt@6 {
+			description = "AM57xx-evm overlay";
+			data = /incbin/("am57xx-evm.dtbo");
+			type = "flat_dt";
+			arch = "arm";
+			compression = "none";
+			load = <0x83090000>;
+		};
+		fdt@7 {
+			description = "AM57xx-evm-reva3 overlay";
+			data = /incbin/("am57xx-evm-reva3.dtbo");
+			type = "flat_dt";
+			arch = "arm";
+			compression = "none";
+			load = <0x83090000>;
+		};
+	};
+
+	configurations {
+		default = "am57xx-evm";
+		am57xx-evm {
+			description = "AM57xx EVM";
+			kernel = "kernel@1";
+			fdt = "fdt@1", "fdt@3", "fdt@6";
+		};
+		am57xx-evm-reva3 {
+			description = "AM57xx EVM rev A3";
+			kernel = "kernel@1";
+			fdt = "fdt@2", "fdt@3", "fdt@7";
+		};
+		cam-mt9t111 {
+			description = "MT9T111 camera";
+			fdt = "fdt@4";
+		};
+		cam-ov10635 {
+			description = "OV10635 camera";
+			fdt = "fdt@5";
+		};
+	};
+};
-- 
1.9.1

--
Texas Instruments Finland Oy, Porkkalankatu 22, 00180 Helsinki. Y-tunnus/Business ID: 0615521-4. Kotipaikka/Domicile: Helsinki

^ permalink raw reply	[flat|nested] 52+ messages in thread

* Re: [RFC 00/13] ARM: dts: DT overlay support infra + some data
  2018-04-17  9:10 [RFC 00/13] ARM: dts: DT overlay support infra + some data Tero Kristo
                   ` (12 preceding siblings ...)
  2018-04-17  9:10 ` [RFC 13/13] ARM: dts: ti: add am57xx-evm " Tero Kristo
@ 2018-04-17  9:18 ` Russell King
  13 siblings, 0 replies; 52+ messages in thread
From: Russell King @ 2018-04-17  9:18 UTC (permalink / raw)
  To: Tero Kristo
  Cc: devicetree, robh+dt, frowand.list, mark.rutland, wmills, tony, trini

Hi,

Please copy me at linux@armlinux.org.uk not rmk@armlinux.org.uk - this
entire series has ended up in my spam folder.

On Tue, Apr 17, 2018 at 12:10:02PM +0300, Tero Kristo wrote:
> Hi,
> 
> This series is an attempt to start discussion on the DT overlay build time
> support. Basically, one can build DT overlays directly from kernel tree,
> and also build FIT images that contain the kernel + devicetree blobs
> required for specific configuration that can be booted directly with
> u-boot. No runtime support for overlay switching is touched by this
> series.
>
> The main controversy with this series is most likely where the DT overlay
> files should be stored at. Should they still reside with the kernel
> tree or someplace else? Also, the FIT image support is probably
> controversial, should it be part of the kernel build system like shown
> here, or should it be separate? The zImage dependency is pretty annoying
> so maybe it should be done somewhere else.

Please, no, do not add any further build targets for special boot loader
formats.  We already deprecate the "uImage" format when building multi-
platform kernels.

The problem is that we either need to pass in parameters like the load
address and dtb path to include in the image, or we need to add to the
kernel build system the load addresses for every platform, and generate
hundreds of images eating up lots of disk space, and adding to the
kernel build time.

When we switched to dtb and multi-platform support, we decided that it
was much better that such bootloader specific stuff be external to the
kernel tree.

-- 
Russell King

^ permalink raw reply	[flat|nested] 52+ messages in thread

* Re: [RFC 12/13] ARM: dts: ti: add dra71-evm FIT description file
  2018-04-17  9:10 ` [RFC 12/13] ARM: dts: ti: add dra71-evm FIT description file Tero Kristo
@ 2018-04-17  9:29   ` Russell King
  2018-04-17  9:34     ` Tero Kristo
  0 siblings, 1 reply; 52+ messages in thread
From: Russell King @ 2018-04-17  9:29 UTC (permalink / raw)
  To: Tero Kristo
  Cc: devicetree, robh+dt, frowand.list, mark.rutland, wmills, tony, trini

On Tue, Apr 17, 2018 at 12:10:14PM +0300, Tero Kristo wrote:
> Add FIT image description file for dra71-evm, and the available
> configurations for it.
> 
> Signed-off-by: Tero Kristo <t-kristo@ti.com>
> ---
>  arch/arm/boot/dts/ti/dra71-evm.its | 62 ++++++++++++++++++++++++++++++++++++++
>  1 file changed, 62 insertions(+)
>  create mode 100644 arch/arm/boot/dts/ti/dra71-evm.its
> 
> diff --git a/arch/arm/boot/dts/ti/dra71-evm.its b/arch/arm/boot/dts/ti/dra71-evm.its
> new file mode 100644
> index 0000000..8dc53cb
> --- /dev/null
> +++ b/arch/arm/boot/dts/ti/dra71-evm.its
> @@ -0,0 +1,62 @@
> +/dts-v1/;
> +
> +/ {
> +	description = "DRA71x-evm";
> +	#address-cells = <1>;
> +
> +	images {
> +		kernel@1 {
> +			description = "Linux kernel";
> +			data = /incbin/("../../zImage");
> +			type = "kernel";
> +			arch = "arm";
> +			os = "linux";
> +			compression = "none";
> +			load = <0x82000000>;
> +			entry = <0x82000000>;
> +		};
> +		fdt@1 {
> +			description = "DRA71x-evm";
> +			data = /incbin/("dra71-evm.dtb");
> +			type = "flat_dt";
> +			arch = "arm";
> +			compression = "none";
> +			load = <0x83000000>;
> +		};
> +		fdt@2 {
> +			description = "DRA71x-evm LCD";
> +			data = /incbin/("dra71-evm-lcd-auo-g101evn01.0.dtbo");
> +			type = "flat_dt";
> +			arch = "arm";
> +			compression = "none";
> +			load = <0x83100000>;
> +		};
> +		fdt@3 {
> +			description = "DRA71x-evm NAND";
> +			data = /incbin/("dra71-evm-nand.dtbo");
> +			type = "flat_dt";
> +			arch = "arm";
> +			compression = "none";
> +			load = <0x83200000>;
> +		};
> +	};
> +
> +	configurations {
> +		default = "dra71-evm";
> +		dra71-evm {
> +			description = "DRA71x-evm";
> +			kernel = "kernel@1";
> +			fdt = "fdt@1";
> +		};
> +		dra71-evm-lcd-auo-g101evn01.0 {
> +			description = "DRA71x-evm with LCD overlay";
> +			kernel = "kernel@1";
> +			fdt = "fdt@1", "fdt@2";
> +		};
> +		dra71-evm-nand {
> +			description = "DRA71x-evm with NAND overlay";
> +			kernel = "kernel@1";
> +			fdt = "fdt@1", "fdt@3";
> +		};

This strikes me as really horrid and inflexible.

Consider a platform where you have multiple choices, each one
independent - for example, you may have the selection of two base
DT files depending on the SoC.  Then you may have four board-level
DT overlays to choose from.  Then you may have a selection of
overlays depending on what hardware is connected (eg, whether a
camera is connected and what type of camera, whether a LVDS panel
is connected and what it is, etc.)

Before considering the optional hardware, you already have 8
different combinations, and that multiplies up each time there
is another variable to consider.

Exhaustively listing each combination of kernel, base dtb and
overlays is not practical in such a scenario, and if this is what
FIT requires, FIT is not fit for purpose.

-- 
Russell King

^ permalink raw reply	[flat|nested] 52+ messages in thread

* Re: [RFC 12/13] ARM: dts: ti: add dra71-evm FIT description file
  2018-04-17  9:29   ` Russell King
@ 2018-04-17  9:34     ` Tero Kristo
  2018-04-17 14:49       ` Tony Lindgren
  0 siblings, 1 reply; 52+ messages in thread
From: Tero Kristo @ 2018-04-17  9:34 UTC (permalink / raw)
  To: Russell King
  Cc: devicetree, robh+dt, frowand.list, mark.rutland, wmills, tony, trini

On 17/04/18 12:29, Russell King wrote:
> On Tue, Apr 17, 2018 at 12:10:14PM +0300, Tero Kristo wrote:
>> Add FIT image description file for dra71-evm, and the available
>> configurations for it.
>>
>> Signed-off-by: Tero Kristo <t-kristo@ti.com>
>> ---
>>   arch/arm/boot/dts/ti/dra71-evm.its | 62 ++++++++++++++++++++++++++++++++++++++
>>   1 file changed, 62 insertions(+)
>>   create mode 100644 arch/arm/boot/dts/ti/dra71-evm.its
>>
>> diff --git a/arch/arm/boot/dts/ti/dra71-evm.its b/arch/arm/boot/dts/ti/dra71-evm.its
>> new file mode 100644
>> index 0000000..8dc53cb
>> --- /dev/null
>> +++ b/arch/arm/boot/dts/ti/dra71-evm.its
>> @@ -0,0 +1,62 @@
>> +/dts-v1/;
>> +
>> +/ {
>> +	description = "DRA71x-evm";
>> +	#address-cells = <1>;
>> +
>> +	images {
>> +		kernel@1 {
>> +			description = "Linux kernel";
>> +			data = /incbin/("../../zImage");
>> +			type = "kernel";
>> +			arch = "arm";
>> +			os = "linux";
>> +			compression = "none";
>> +			load = <0x82000000>;
>> +			entry = <0x82000000>;
>> +		};
>> +		fdt@1 {
>> +			description = "DRA71x-evm";
>> +			data = /incbin/("dra71-evm.dtb");
>> +			type = "flat_dt";
>> +			arch = "arm";
>> +			compression = "none";
>> +			load = <0x83000000>;
>> +		};
>> +		fdt@2 {
>> +			description = "DRA71x-evm LCD";
>> +			data = /incbin/("dra71-evm-lcd-auo-g101evn01.0.dtbo");
>> +			type = "flat_dt";
>> +			arch = "arm";
>> +			compression = "none";
>> +			load = <0x83100000>;
>> +		};
>> +		fdt@3 {
>> +			description = "DRA71x-evm NAND";
>> +			data = /incbin/("dra71-evm-nand.dtbo");
>> +			type = "flat_dt";
>> +			arch = "arm";
>> +			compression = "none";
>> +			load = <0x83200000>;
>> +		};
>> +	};
>> +
>> +	configurations {
>> +		default = "dra71-evm";
>> +		dra71-evm {
>> +			description = "DRA71x-evm";
>> +			kernel = "kernel@1";
>> +			fdt = "fdt@1";
>> +		};
>> +		dra71-evm-lcd-auo-g101evn01.0 {
>> +			description = "DRA71x-evm with LCD overlay";
>> +			kernel = "kernel@1";
>> +			fdt = "fdt@1", "fdt@2";
>> +		};
>> +		dra71-evm-nand {
>> +			description = "DRA71x-evm with NAND overlay";
>> +			kernel = "kernel@1";
>> +			fdt = "fdt@1", "fdt@3";
>> +		};
> 
> This strikes me as really horrid and inflexible.
> 
> Consider a platform where you have multiple choices, each one
> independent - for example, you may have the selection of two base
> DT files depending on the SoC.  Then you may have four board-level
> DT overlays to choose from.  Then you may have a selection of
> overlays depending on what hardware is connected (eg, whether a
> camera is connected and what type of camera, whether a LVDS panel
> is connected and what it is, etc.)
> 
> Before considering the optional hardware, you already have 8
> different combinations, and that multiplies up each time there
> is another variable to consider.
> 
> Exhaustively listing each combination of kernel, base dtb and
> overlays is not practical in such a scenario, and if this is what
> FIT requires, FIT is not fit for purpose.
> 

This specific dra71-evm is rather a poor example, as we have built the 
available configs as separate config entries due to limited amount of them.

In typical setup, you can boot a large number of different configs via:

bootm 0x82000000#dra71-evm#nand#lcd-auo-g101evn01.0

... assuming the configs were named like that, and assuming they would 
be compatible with each other. The am57xx-evm example provided is 
better, as you can chain the different cameras to the available evm configs.

-Tero
--
Texas Instruments Finland Oy, Porkkalankatu 22, 00180 Helsinki. Y-tunnus/Business ID: 0615521-4. Kotipaikka/Domicile: Helsinki

^ permalink raw reply	[flat|nested] 52+ messages in thread

* Re: [RFC 12/13] ARM: dts: ti: add dra71-evm FIT description file
  2018-04-17  9:34     ` Tero Kristo
@ 2018-04-17 14:49       ` Tony Lindgren
  2018-05-21  6:57           ` Tero Kristo
  0 siblings, 1 reply; 52+ messages in thread
From: Tony Lindgren @ 2018-04-17 14:49 UTC (permalink / raw)
  To: Tero Kristo
  Cc: Russell King, devicetree, robh+dt, frowand.list, mark.rutland,
	wmills, trini

* Tero Kristo <t-kristo@ti.com> [180417 09:36]:
> In typical setup, you can boot a large number of different configs via:
> 
> bootm 0x82000000#dra71-evm#nand#lcd-auo-g101evn01.0
> 
> ... assuming the configs were named like that, and assuming they would be
> compatible with each other. The am57xx-evm example provided is better, as
> you can chain the different cameras to the available evm configs.

Why not just do it in the bootloader to put together the dtb?

Then for external devices, you could just pass info on the
kernel cmdline with lcd=foo camera=bar if they cannot be
detected over I2C.

Regards,

Tony

^ permalink raw reply	[flat|nested] 52+ messages in thread

* Re: [RFC 04/13] kbuild: add support for building %.dtbo targets
  2018-04-17  9:10 ` [RFC 04/13] kbuild: add support for building %.dtbo targets Tero Kristo
@ 2018-04-18 14:16   ` Geert Uytterhoeven
  0 siblings, 0 replies; 52+ messages in thread
From: Geert Uytterhoeven @ 2018-04-18 14:16 UTC (permalink / raw)
  To: Tero Kristo
  Cc: open list:OPEN FIRMWARE AND FLATTENED DEVICE TREE BINDINGS,
	Rob Herring, Frank Rowand, Mark Rutland, wmills,
	ext Tony Lindgren, Tom Rini, Russell King

On Tue, Apr 17, 2018 at 11:10 AM, Tero Kristo <t-kristo@ti.com> wrote:
> Add support for building DT overlay targets.
>
> Signed-off-by: Tero Kristo <t-kristo@ti.com>

Reviewed-by: Geert Uytterhoeven <geert+renesas@glider.be>

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

^ permalink raw reply	[flat|nested] 52+ messages in thread

* Re: [RFC 05/13] ARM: dts: ti: add support for building .dtb files containing symbols
  2018-04-17  9:10 ` [RFC 05/13] ARM: dts: ti: add support for building .dtb files containing symbols Tero Kristo
@ 2018-04-18 14:20   ` Geert Uytterhoeven
  2018-04-18 19:07     ` Tero Kristo
  2018-04-18 22:43     ` Rob Herring
  0 siblings, 2 replies; 52+ messages in thread
From: Geert Uytterhoeven @ 2018-04-18 14:20 UTC (permalink / raw)
  To: Tero Kristo
  Cc: open list:OPEN FIRMWARE AND FLATTENED DEVICE TREE BINDINGS,
	Rob Herring, Frank Rowand, Mark Rutland, wmills,
	ext Tony Lindgren, Tom Rini, Russell King

Hi Tero,

On Tue, Apr 17, 2018 at 11:10 AM, Tero Kristo <t-kristo@ti.com> wrote:
> Symbols in the DTB files are needed so that overlays can be applied
> properly. Add support for building TI SoC specific .dtb files, the
> source is fetched from parent directory.
>
> Signed-off-by: Tero Kristo <t-kristo@ti.com>

Thanks for your patch!

> ---
>  arch/arm/boot/dts/ti/Makefile | 5 +++++
>  1 file changed, 5 insertions(+)
>
> diff --git a/arch/arm/boot/dts/ti/Makefile b/arch/arm/boot/dts/ti/Makefile
> index b26328b..7d2d411 100644
> --- a/arch/arm/boot/dts/ti/Makefile
> +++ b/arch/arm/boot/dts/ti/Makefile
> @@ -1 +1,6 @@
> +DTC_FLAGS += -@ -Wno-reg_format -Wno-avoid_default_addr_size

Why the -W options?

> +
> +$(obj)/%.dtb: $(src)/../%.dts FORCE

I guess you want a dependency on $(DTC), too?

> +       $(call if_changed_dep,dtc)
> +
>  clean-files    += *.dtbo

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

^ permalink raw reply	[flat|nested] 52+ messages in thread

* Re: [RFC 06/13] ARM: dts: am57xx-evm: add AM57xx-evm DT overlay
  2018-04-17  9:10 ` [RFC 06/13] ARM: dts: am57xx-evm: add AM57xx-evm DT overlay Tero Kristo
@ 2018-04-18 14:36   ` Geert Uytterhoeven
  2018-04-18 19:12     ` Tero Kristo
  2018-04-18 22:40     ` Rob Herring
  2018-04-19  0:19   ` Rob Herring
  1 sibling, 2 replies; 52+ messages in thread
From: Geert Uytterhoeven @ 2018-04-18 14:36 UTC (permalink / raw)
  To: Tero Kristo
  Cc: open list:OPEN FIRMWARE AND FLATTENED DEVICE TREE BINDINGS,
	Rob Herring, Frank Rowand, Mark Rutland, wmills,
	ext Tony Lindgren, Tom Rini, Russell King

On Tue, Apr 17, 2018 at 11:10 AM, Tero Kristo <t-kristo@ti.com> wrote:
> The AM57xx-evm is an overlay on top of beagle-x15 board. This contains
> a display extension macro, and a few extra peripherals. Two versions
> of the evm are supported, the base evm and the latest rev A3 evm. A
> common overlay file is used for both boards.
>
> Signed-off-by: Tero Kristo <t-kristo@ti.com>
> ---
>  arch/arm/boot/dts/ti/am57xx-evm-common.dtso | 175 ++++++++++++++++++++++++++++
>  arch/arm/boot/dts/ti/am57xx-evm-reva3.dtso  |  11 ++
>  arch/arm/boot/dts/ti/am57xx-evm.dtso        |  11 ++
>  3 files changed, 197 insertions(+)
>  create mode 100644 arch/arm/boot/dts/ti/am57xx-evm-common.dtso
>  create mode 100644 arch/arm/boot/dts/ti/am57xx-evm-reva3.dtso
>  create mode 100644 arch/arm/boot/dts/ti/am57xx-evm.dtso
>
> diff --git a/arch/arm/boot/dts/ti/am57xx-evm-common.dtso b/arch/arm/boot/dts/ti/am57xx-evm-common.dtso
> new file mode 100644
> index 0000000..68c3937
> --- /dev/null
> +++ b/arch/arm/boot/dts/ti/am57xx-evm-common.dtso
> @@ -0,0 +1,175 @@
> +/dts-v1/;
> +/plugin/;
> +#include <dt-bindings/interrupt-controller/irq.h>
> +#include <dt-bindings/gpio/gpio.h>
> +#include <dt-bindings/input/input.h>
> +
> +/ {
> +  fragment@101 {
> +       target-path = "/";
> +
> +       __overlay__ {

It would be good to have "scripts/dtc: Correct overlay syntactic sugar for
generating target-path fragments" in the kernel's copy of dtc, so this
section can be converted to sugar syntax, too.


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

^ permalink raw reply	[flat|nested] 52+ messages in thread

* Re: [RFC 05/13] ARM: dts: ti: add support for building .dtb files containing symbols
  2018-04-18 14:20   ` Geert Uytterhoeven
@ 2018-04-18 19:07     ` Tero Kristo
  2018-04-18 22:43     ` Rob Herring
  1 sibling, 0 replies; 52+ messages in thread
From: Tero Kristo @ 2018-04-18 19:07 UTC (permalink / raw)
  To: Geert Uytterhoeven
  Cc: open list:OPEN FIRMWARE AND FLATTENED DEVICE TREE BINDINGS,
	Rob Herring, Frank Rowand, Mark Rutland, wmills,
	ext Tony Lindgren, Tom Rini, Russell King

On 18/04/18 17:20, Geert Uytterhoeven wrote:
> Hi Tero,
> 
> On Tue, Apr 17, 2018 at 11:10 AM, Tero Kristo <t-kristo@ti.com> wrote:
>> Symbols in the DTB files are needed so that overlays can be applied
>> properly. Add support for building TI SoC specific .dtb files, the
>> source is fetched from parent directory.
>>
>> Signed-off-by: Tero Kristo <t-kristo@ti.com>
> 
> Thanks for your patch!
> 
>> ---
>>   arch/arm/boot/dts/ti/Makefile | 5 +++++
>>   1 file changed, 5 insertions(+)
>>
>> diff --git a/arch/arm/boot/dts/ti/Makefile b/arch/arm/boot/dts/ti/Makefile
>> index b26328b..7d2d411 100644
>> --- a/arch/arm/boot/dts/ti/Makefile
>> +++ b/arch/arm/boot/dts/ti/Makefile
>> @@ -1 +1,6 @@
>> +DTC_FLAGS += -@ -Wno-reg_format -Wno-avoid_default_addr_size
> 
> Why the -W options?

The overlay files typically contain declarations that miss these bits, 
and will lead to build time warnings. Mostly, because we are working 
with fragments / references only, and don't have the base declaration 
available at all.

> 
>> +
>> +$(obj)/%.dtb: $(src)/../%.dts FORCE
> 
> I guess you want a dependency on $(DTC), too?

Yeah, that should be added actually.

> 
>> +       $(call if_changed_dep,dtc)
>> +
>>   clean-files    += *.dtbo
> 
> Gr{oetje,eeting}s,
> 
>                          Geert
> 

--
Texas Instruments Finland Oy, Porkkalankatu 22, 00180 Helsinki. Y-tunnus/Business ID: 0615521-4. Kotipaikka/Domicile: Helsinki

^ permalink raw reply	[flat|nested] 52+ messages in thread

* Re: [RFC 06/13] ARM: dts: am57xx-evm: add AM57xx-evm DT overlay
  2018-04-18 14:36   ` Geert Uytterhoeven
@ 2018-04-18 19:12     ` Tero Kristo
  2018-04-18 19:15       ` Russell King
  2018-04-18 22:40     ` Rob Herring
  1 sibling, 1 reply; 52+ messages in thread
From: Tero Kristo @ 2018-04-18 19:12 UTC (permalink / raw)
  To: Geert Uytterhoeven
  Cc: open list:OPEN FIRMWARE AND FLATTENED DEVICE TREE BINDINGS,
	Rob Herring, Frank Rowand, Mark Rutland, wmills,
	ext Tony Lindgren, Tom Rini, Russell King

On 18/04/18 17:36, Geert Uytterhoeven wrote:
> On Tue, Apr 17, 2018 at 11:10 AM, Tero Kristo <t-kristo@ti.com> wrote:
>> The AM57xx-evm is an overlay on top of beagle-x15 board. This contains
>> a display extension macro, and a few extra peripherals. Two versions
>> of the evm are supported, the base evm and the latest rev A3 evm. A
>> common overlay file is used for both boards.
>>
>> Signed-off-by: Tero Kristo <t-kristo@ti.com>
>> ---
>>   arch/arm/boot/dts/ti/am57xx-evm-common.dtso | 175 ++++++++++++++++++++++++++++
>>   arch/arm/boot/dts/ti/am57xx-evm-reva3.dtso  |  11 ++
>>   arch/arm/boot/dts/ti/am57xx-evm.dtso        |  11 ++
>>   3 files changed, 197 insertions(+)
>>   create mode 100644 arch/arm/boot/dts/ti/am57xx-evm-common.dtso
>>   create mode 100644 arch/arm/boot/dts/ti/am57xx-evm-reva3.dtso
>>   create mode 100644 arch/arm/boot/dts/ti/am57xx-evm.dtso
>>
>> diff --git a/arch/arm/boot/dts/ti/am57xx-evm-common.dtso b/arch/arm/boot/dts/ti/am57xx-evm-common.dtso
>> new file mode 100644
>> index 0000000..68c3937
>> --- /dev/null
>> +++ b/arch/arm/boot/dts/ti/am57xx-evm-common.dtso
>> @@ -0,0 +1,175 @@
>> +/dts-v1/;
>> +/plugin/;
>> +#include <dt-bindings/interrupt-controller/irq.h>
>> +#include <dt-bindings/gpio/gpio.h>
>> +#include <dt-bindings/input/input.h>
>> +
>> +/ {
>> +  fragment@101 {
>> +       target-path = "/";
>> +
>> +       __overlay__ {
> 
> It would be good to have "scripts/dtc: Correct overlay syntactic sugar for
> generating target-path fragments" in the kernel's copy of dtc, so this
> section can be converted to sugar syntax, too.

Ah yea, that seems to be a recent patch I've missed, but yes, if that 
fixes this limitation, it would be a great addition.

-Tero

> 
> 
> Gr{oetje,eeting}s,
> 
>                          Geert
> 

--
Texas Instruments Finland Oy, Porkkalankatu 22, 00180 Helsinki. Y-tunnus/Business ID: 0615521-4. Kotipaikka/Domicile: Helsinki

^ permalink raw reply	[flat|nested] 52+ messages in thread

* Re: [RFC 06/13] ARM: dts: am57xx-evm: add AM57xx-evm DT overlay
  2018-04-18 19:12     ` Tero Kristo
@ 2018-04-18 19:15       ` Russell King
  2018-04-20 13:27         ` Geert Uytterhoeven
  0 siblings, 1 reply; 52+ messages in thread
From: Russell King @ 2018-04-18 19:15 UTC (permalink / raw)
  To: Tero Kristo
  Cc: Geert Uytterhoeven,
	open list:OPEN FIRMWARE AND FLATTENED DEVICE TREE BINDINGS,
	Rob Herring, Frank Rowand, Mark Rutland, wmills,
	ext Tony Lindgren, Tom Rini

As already requested, can you *all* please use my linux@armlinux.org.uk
address for this stuff please, and not rmk@armlinux.org.uk - it's
screwing up my mailboxes.  Thanks.

On Wed, Apr 18, 2018 at 10:12:08PM +0300, Tero Kristo wrote:
> On 18/04/18 17:36, Geert Uytterhoeven wrote:
> >On Tue, Apr 17, 2018 at 11:10 AM, Tero Kristo <t-kristo@ti.com> wrote:
> >>The AM57xx-evm is an overlay on top of beagle-x15 board. This contains
> >>a display extension macro, and a few extra peripherals. Two versions
> >>of the evm are supported, the base evm and the latest rev A3 evm. A
> >>common overlay file is used for both boards.
> >>
> >>Signed-off-by: Tero Kristo <t-kristo@ti.com>
> >>---
> >>  arch/arm/boot/dts/ti/am57xx-evm-common.dtso | 175 ++++++++++++++++++++++++++++
> >>  arch/arm/boot/dts/ti/am57xx-evm-reva3.dtso  |  11 ++
> >>  arch/arm/boot/dts/ti/am57xx-evm.dtso        |  11 ++
> >>  3 files changed, 197 insertions(+)
> >>  create mode 100644 arch/arm/boot/dts/ti/am57xx-evm-common.dtso
> >>  create mode 100644 arch/arm/boot/dts/ti/am57xx-evm-reva3.dtso
> >>  create mode 100644 arch/arm/boot/dts/ti/am57xx-evm.dtso
> >>
> >>diff --git a/arch/arm/boot/dts/ti/am57xx-evm-common.dtso b/arch/arm/boot/dts/ti/am57xx-evm-common.dtso
> >>new file mode 100644
> >>index 0000000..68c3937
> >>--- /dev/null
> >>+++ b/arch/arm/boot/dts/ti/am57xx-evm-common.dtso
> >>@@ -0,0 +1,175 @@
> >>+/dts-v1/;
> >>+/plugin/;
> >>+#include <dt-bindings/interrupt-controller/irq.h>
> >>+#include <dt-bindings/gpio/gpio.h>
> >>+#include <dt-bindings/input/input.h>
> >>+
> >>+/ {
> >>+  fragment@101 {
> >>+       target-path = "/";
> >>+
> >>+       __overlay__ {
> >
> >It would be good to have "scripts/dtc: Correct overlay syntactic sugar for
> >generating target-path fragments" in the kernel's copy of dtc, so this
> >section can be converted to sugar syntax, too.
> 
> Ah yea, that seems to be a recent patch I've missed, but yes, if that fixes
> this limitation, it would be a great addition.
> 
> -Tero
> 
> >
> >
> >Gr{oetje,eeting}s,
> >
> >                         Geert
> >
> 
> --
> Texas Instruments Finland Oy, Porkkalankatu 22, 00180 Helsinki. Y-tunnus/Business ID: 0615521-4. Kotipaikka/Domicile: Helsinki

-- 
Russell King
ARM architecture Linux Kernel maintainer

^ permalink raw reply	[flat|nested] 52+ messages in thread

* Re: [RFC 06/13] ARM: dts: am57xx-evm: add AM57xx-evm DT overlay
  2018-04-18 14:36   ` Geert Uytterhoeven
  2018-04-18 19:12     ` Tero Kristo
@ 2018-04-18 22:40     ` Rob Herring
  1 sibling, 0 replies; 52+ messages in thread
From: Rob Herring @ 2018-04-18 22:40 UTC (permalink / raw)
  To: Geert Uytterhoeven
  Cc: Tero Kristo,
	open list:OPEN FIRMWARE AND FLATTENED DEVICE TREE BINDINGS,
	Frank Rowand, Mark Rutland, Mills, William, ext Tony Lindgren,
	Tom Rini, Russell King

On Wed, Apr 18, 2018 at 9:36 AM, Geert Uytterhoeven
<geert@linux-m68k.org> wrote:
> On Tue, Apr 17, 2018 at 11:10 AM, Tero Kristo <t-kristo@ti.com> wrote:
>> The AM57xx-evm is an overlay on top of beagle-x15 board. This contains
>> a display extension macro, and a few extra peripherals. Two versions
>> of the evm are supported, the base evm and the latest rev A3 evm. A
>> common overlay file is used for both boards.
>>
>> Signed-off-by: Tero Kristo <t-kristo@ti.com>
>> ---
>>  arch/arm/boot/dts/ti/am57xx-evm-common.dtso | 175 ++++++++++++++++++++++++++++
>>  arch/arm/boot/dts/ti/am57xx-evm-reva3.dtso  |  11 ++
>>  arch/arm/boot/dts/ti/am57xx-evm.dtso        |  11 ++
>>  3 files changed, 197 insertions(+)
>>  create mode 100644 arch/arm/boot/dts/ti/am57xx-evm-common.dtso
>>  create mode 100644 arch/arm/boot/dts/ti/am57xx-evm-reva3.dtso
>>  create mode 100644 arch/arm/boot/dts/ti/am57xx-evm.dtso
>>
>> diff --git a/arch/arm/boot/dts/ti/am57xx-evm-common.dtso b/arch/arm/boot/dts/ti/am57xx-evm-common.dtso
>> new file mode 100644
>> index 0000000..68c3937
>> --- /dev/null
>> +++ b/arch/arm/boot/dts/ti/am57xx-evm-common.dtso
>> @@ -0,0 +1,175 @@
>> +/dts-v1/;
>> +/plugin/;
>> +#include <dt-bindings/interrupt-controller/irq.h>
>> +#include <dt-bindings/gpio/gpio.h>
>> +#include <dt-bindings/input/input.h>
>> +
>> +/ {
>> +  fragment@101 {
>> +       target-path = "/";
>> +
>> +       __overlay__ {
>
> It would be good to have "scripts/dtc: Correct overlay syntactic sugar for
> generating target-path fragments" in the kernel's copy of dtc, so this
> section can be converted to sugar syntax, too.

I'm planning to do a dtc update for 4.18 too. New warnings coming too. :)

Rob

^ permalink raw reply	[flat|nested] 52+ messages in thread

* Re: [RFC 05/13] ARM: dts: ti: add support for building .dtb files containing symbols
  2018-04-18 14:20   ` Geert Uytterhoeven
  2018-04-18 19:07     ` Tero Kristo
@ 2018-04-18 22:43     ` Rob Herring
  2018-04-19  6:36       ` Tero Kristo
  1 sibling, 1 reply; 52+ messages in thread
From: Rob Herring @ 2018-04-18 22:43 UTC (permalink / raw)
  To: Geert Uytterhoeven
  Cc: Tero Kristo,
	open list:OPEN FIRMWARE AND FLATTENED DEVICE TREE BINDINGS,
	Frank Rowand, Mark Rutland, Mills, William, ext Tony Lindgren,
	Tom Rini, Russell King

On Wed, Apr 18, 2018 at 9:20 AM, Geert Uytterhoeven
<geert@linux-m68k.org> wrote:
> Hi Tero,
>
> On Tue, Apr 17, 2018 at 11:10 AM, Tero Kristo <t-kristo@ti.com> wrote:
>> Symbols in the DTB files are needed so that overlays can be applied
>> properly. Add support for building TI SoC specific .dtb files, the
>> source is fetched from parent directory.
>>
>> Signed-off-by: Tero Kristo <t-kristo@ti.com>
>
> Thanks for your patch!
>
>> ---
>>  arch/arm/boot/dts/ti/Makefile | 5 +++++
>>  1 file changed, 5 insertions(+)
>>
>> diff --git a/arch/arm/boot/dts/ti/Makefile b/arch/arm/boot/dts/ti/Makefile
>> index b26328b..7d2d411 100644
>> --- a/arch/arm/boot/dts/ti/Makefile
>> +++ b/arch/arm/boot/dts/ti/Makefile
>> @@ -1 +1,6 @@
>> +DTC_FLAGS += -@ -Wno-reg_format -Wno-avoid_default_addr_size
>
> Why the -W options?
>
>> +
>> +$(obj)/%.dtb: $(src)/../%.dts FORCE
>
> I guess you want a dependency on $(DTC), too?

I think that is handled globally already. I did a fix not to long ago.

Rob

^ permalink raw reply	[flat|nested] 52+ messages in thread

* Re: [RFC 01/13] ARM: dts: allow building .dtb files under platform subdirs
  2018-04-17  9:10 ` [RFC 01/13] ARM: dts: allow building .dtb files under platform subdirs Tero Kristo
@ 2018-04-19  0:02   ` Rob Herring
  0 siblings, 0 replies; 52+ messages in thread
From: Rob Herring @ 2018-04-19  0:02 UTC (permalink / raw)
  To: Tero Kristo
  Cc: devicetree, Frank Rowand, Mark Rutland, Mills, William,
	Tony Lindgren, Tom Rini, Russell King

On Tue, Apr 17, 2018 at 4:10 AM, Tero Kristo <t-kristo@ti.com> wrote:
> Add support to base ARM makefile for building .dtb files under platform
> specific subdirs (e.g. arch/arm/boot/dts/ti for TI SoCs.)
>
> Signed-off-by: Tero Kristo <t-kristo@ti.com>
> ---
>  arch/arm/Makefile | 4 +++-
>  1 file changed, 3 insertions(+), 1 deletion(-)
>
> diff --git a/arch/arm/Makefile b/arch/arm/Makefile
> index e4e537f..f6c90bc 100644
> --- a/arch/arm/Makefile
> +++ b/arch/arm/Makefile
> @@ -343,8 +343,10 @@ $(BOOT_TARGETS): vmlinux
>  $(INSTALL_TARGETS):
>         $(Q)$(MAKE) $(build)=$(boot) MACHINE=$(MACHINE) $@
>
> +%.dtb: dtbdir=$(patsubst %/,%,$(patsubst %./,%,$(boot)/dts/$(dir $@)))

I'd expect this to look more like the arm64 version and just add
'subdir-y' entries in the boot/dts/Makefile.

> +
>  %.dtb: | scripts
> -       $(Q)$(MAKE) $(build)=$(boot)/dts MACHINE=$(MACHINE) $(boot)/dts/$@
> +       $(Q)$(MAKE) $(build)=$(dtbdir) MACHINE=$(MACHINE) $(boot)/dts/$@

We can drop MACHINE here.

Rob

^ permalink raw reply	[flat|nested] 52+ messages in thread

* Re: [RFC 06/13] ARM: dts: am57xx-evm: add AM57xx-evm DT overlay
  2018-04-17  9:10 ` [RFC 06/13] ARM: dts: am57xx-evm: add AM57xx-evm DT overlay Tero Kristo
  2018-04-18 14:36   ` Geert Uytterhoeven
@ 2018-04-19  0:19   ` Rob Herring
  2018-04-19  6:49     ` Tero Kristo
  1 sibling, 1 reply; 52+ messages in thread
From: Rob Herring @ 2018-04-19  0:19 UTC (permalink / raw)
  To: Tero Kristo
  Cc: devicetree, Frank Rowand, Mark Rutland, Mills, William,
	Tony Lindgren, Tom Rini, Russell King

On Tue, Apr 17, 2018 at 4:10 AM, Tero Kristo <t-kristo@ti.com> wrote:
> The AM57xx-evm is an overlay on top of beagle-x15 board. This contains
> a display extension macro, and a few extra peripherals. Two versions
> of the evm are supported, the base evm and the latest rev A3 evm. A
> common overlay file is used for both boards.
>
> Signed-off-by: Tero Kristo <t-kristo@ti.com>
> ---
>  arch/arm/boot/dts/ti/am57xx-evm-common.dtso | 175 ++++++++++++++++++++++++++++

Why do this as an overlay? To what level is an AM57xx-evm functional
using a beagle-x15 dtb?

>  arch/arm/boot/dts/ti/am57xx-evm-reva3.dtso  |  11 ++
>  arch/arm/boot/dts/ti/am57xx-evm.dtso        |  11 ++

I think I'd structure this as just the A3 is an overlay. Applying it
will override everything in am57xx-evm.dtso, so what's the point to
making users of both board variations apply an overlay. Plus, you
could have only known the differences in the board revisions after you
had both boards. That wouldn't work if you developed this as new
boards appear.

Rob

^ permalink raw reply	[flat|nested] 52+ messages in thread

* Re: [RFC 05/13] ARM: dts: ti: add support for building .dtb files containing symbols
  2018-04-18 22:43     ` Rob Herring
@ 2018-04-19  6:36       ` Tero Kristo
  2018-04-19 15:26         ` Rob Herring
  0 siblings, 1 reply; 52+ messages in thread
From: Tero Kristo @ 2018-04-19  6:36 UTC (permalink / raw)
  To: Rob Herring, Geert Uytterhoeven
  Cc: open list:OPEN FIRMWARE AND FLATTENED DEVICE TREE BINDINGS,
	Frank Rowand, Mark Rutland, Mills, William, ext Tony Lindgren,
	Tom Rini, Russell King

On 19/04/18 01:43, Rob Herring wrote:
> On Wed, Apr 18, 2018 at 9:20 AM, Geert Uytterhoeven
> <geert@linux-m68k.org> wrote:
>> Hi Tero,
>>
>> On Tue, Apr 17, 2018 at 11:10 AM, Tero Kristo <t-kristo@ti.com> wrote:
>>> Symbols in the DTB files are needed so that overlays can be applied
>>> properly. Add support for building TI SoC specific .dtb files, the
>>> source is fetched from parent directory.
>>>
>>> Signed-off-by: Tero Kristo <t-kristo@ti.com>
>>
>> Thanks for your patch!
>>
>>> ---
>>>   arch/arm/boot/dts/ti/Makefile | 5 +++++
>>>   1 file changed, 5 insertions(+)
>>>
>>> diff --git a/arch/arm/boot/dts/ti/Makefile b/arch/arm/boot/dts/ti/Makefile
>>> index b26328b..7d2d411 100644
>>> --- a/arch/arm/boot/dts/ti/Makefile
>>> +++ b/arch/arm/boot/dts/ti/Makefile
>>> @@ -1 +1,6 @@
>>> +DTC_FLAGS += -@ -Wno-reg_format -Wno-avoid_default_addr_size
>>
>> Why the -W options?
>>
>>> +
>>> +$(obj)/%.dtb: $(src)/../%.dts FORCE
>>
>> I guess you want a dependency on $(DTC), too?
> 
> I think that is handled globally already. I did a fix not to long ago.

Globally it is handled, but as you see this is a special rule under the 
TI SoC specific makefile. This is building the .dts files under 
arch/arm/boot/dts/* into arch/arm/boot/dts/ti/ containing the symbol 
info (-@ flag for DTC.)

-Tero
--
Texas Instruments Finland Oy, Porkkalankatu 22, 00180 Helsinki. Y-tunnus/Business ID: 0615521-4. Kotipaikka/Domicile: Helsinki

^ permalink raw reply	[flat|nested] 52+ messages in thread

* Re: [RFC 06/13] ARM: dts: am57xx-evm: add AM57xx-evm DT overlay
  2018-04-19  0:19   ` Rob Herring
@ 2018-04-19  6:49     ` Tero Kristo
  2018-04-20  1:31       ` Rob Herring
  0 siblings, 1 reply; 52+ messages in thread
From: Tero Kristo @ 2018-04-19  6:49 UTC (permalink / raw)
  To: Rob Herring
  Cc: devicetree, Frank Rowand, Mark Rutland, Mills, William,
	Tony Lindgren, Tom Rini, Russell King

On 19/04/18 03:19, Rob Herring wrote:
> On Tue, Apr 17, 2018 at 4:10 AM, Tero Kristo <t-kristo@ti.com> wrote:
>> The AM57xx-evm is an overlay on top of beagle-x15 board. This contains
>> a display extension macro, and a few extra peripherals. Two versions
>> of the evm are supported, the base evm and the latest rev A3 evm. A
>> common overlay file is used for both boards.
>>
>> Signed-off-by: Tero Kristo <t-kristo@ti.com>
>> ---
>>   arch/arm/boot/dts/ti/am57xx-evm-common.dtso | 175 ++++++++++++++++++++++++++++
> 
> Why do this as an overlay? To what level is an AM57xx-evm functional
> using a beagle-x15 dtb?

Basically, am57xx-evm is just a beagle-x15 with an extension board 
physically plugged into it. If you don't add the am57xx-evm overlay, 
display (+ WLAN + some gpios) obviously don't work, but rest of the 
functionality does.

If you have an am57xx-evm, you can also unplug the extension board to 
get a plain beagle-x15 board as I did, I don't typically care about 
things like display / WLAN in my work.

> 
>>   arch/arm/boot/dts/ti/am57xx-evm-reva3.dtso  |  11 ++
>>   arch/arm/boot/dts/ti/am57xx-evm.dtso        |  11 ++
> 
> I think I'd structure this as just the A3 is an overlay. Applying it
> will override everything in am57xx-evm.dtso, so what's the point to
> making users of both board variations apply an overlay. Plus, you
> could have only known the differences in the board revisions after you
> had both boards. That wouldn't work if you developed this as new
> boards appear.

Well, beagle-x15 is still the base board for both, and different 
revisions of those also. The changes are relatively minor, but they are 
there. But yes, different hierarchies for these could be applied.

-Tero
--
Texas Instruments Finland Oy, Porkkalankatu 22, 00180 Helsinki. Y-tunnus/Business ID: 0615521-4. Kotipaikka/Domicile: Helsinki

^ permalink raw reply	[flat|nested] 52+ messages in thread

* Re: [RFC 05/13] ARM: dts: ti: add support for building .dtb files containing symbols
  2018-04-19  6:36       ` Tero Kristo
@ 2018-04-19 15:26         ` Rob Herring
  2018-04-19 18:00           ` Tero Kristo
  0 siblings, 1 reply; 52+ messages in thread
From: Rob Herring @ 2018-04-19 15:26 UTC (permalink / raw)
  To: Tero Kristo
  Cc: Geert Uytterhoeven,
	open list:OPEN FIRMWARE AND FLATTENED DEVICE TREE BINDINGS,
	Frank Rowand, Mark Rutland, Mills, William, ext Tony Lindgren,
	Tom Rini, Russell King

On Thu, Apr 19, 2018 at 1:36 AM, Tero Kristo <t-kristo@ti.com> wrote:
> On 19/04/18 01:43, Rob Herring wrote:
>>
>> On Wed, Apr 18, 2018 at 9:20 AM, Geert Uytterhoeven
>> <geert@linux-m68k.org> wrote:
>>>
>>> Hi Tero,
>>>
>>> On Tue, Apr 17, 2018 at 11:10 AM, Tero Kristo <t-kristo@ti.com> wrote:
>>>>
>>>> Symbols in the DTB files are needed so that overlays can be applied
>>>> properly. Add support for building TI SoC specific .dtb files, the
>>>> source is fetched from parent directory.
>>>>
>>>> Signed-off-by: Tero Kristo <t-kristo@ti.com>
>>>
>>>
>>> Thanks for your patch!
>>>
>>>> ---
>>>>   arch/arm/boot/dts/ti/Makefile | 5 +++++
>>>>   1 file changed, 5 insertions(+)
>>>>
>>>> diff --git a/arch/arm/boot/dts/ti/Makefile
>>>> b/arch/arm/boot/dts/ti/Makefile
>>>> index b26328b..7d2d411 100644
>>>> --- a/arch/arm/boot/dts/ti/Makefile
>>>> +++ b/arch/arm/boot/dts/ti/Makefile
>>>> @@ -1 +1,6 @@
>>>> +DTC_FLAGS += -@ -Wno-reg_format -Wno-avoid_default_addr_size
>>>
>>>
>>> Why the -W options?
>>>
>>>> +
>>>> +$(obj)/%.dtb: $(src)/../%.dts FORCE
>>>
>>>
>>> I guess you want a dependency on $(DTC), too?
>>
>>
>> I think that is handled globally already. I did a fix not to long ago.
>
>
> Globally it is handled, but as you see this is a special rule under the TI
> SoC specific makefile. This is building the .dts files under
> arch/arm/boot/dts/* into arch/arm/boot/dts/ti/ containing the symbol info
> (-@ flag for DTC.)

Ah, I see. That means we end up with 2 builds of the base dtbs, right?
We need to not do that. Either we need to be able to set per dtb flags
or set per directory flags and move the TI base dts files to /ti
directory.

Rob

^ permalink raw reply	[flat|nested] 52+ messages in thread

* Re: [RFC 05/13] ARM: dts: ti: add support for building .dtb files containing symbols
  2018-04-19 15:26         ` Rob Herring
@ 2018-04-19 18:00           ` Tero Kristo
  0 siblings, 0 replies; 52+ messages in thread
From: Tero Kristo @ 2018-04-19 18:00 UTC (permalink / raw)
  To: Rob Herring
  Cc: Geert Uytterhoeven,
	open list:OPEN FIRMWARE AND FLATTENED DEVICE TREE BINDINGS 
	<devicetree@vger.kernel.org>,
	Frank Rowand, Mark Rutland, Mills, William  <wmills@ti.com>,
	ext Tony Lindgren, Tom Rini, Russell King

On 19/04/18 18:26, Rob Herring wrote:
> On Thu, Apr 19, 2018 at 1:36 AM, Tero Kristo <t-kristo@ti.com> wrote:
>> On 19/04/18 01:43, Rob Herring wrote:
>>>
>>> On Wed, Apr 18, 2018 at 9:20 AM, Geert Uytterhoeven
>>> <geert@linux-m68k.org> wrote:
>>>>
>>>> Hi Tero,
>>>>
>>>> On Tue, Apr 17, 2018 at 11:10 AM, Tero Kristo <t-kristo@ti.com> wrote:
>>>>>
>>>>> Symbols in the DTB files are needed so that overlays can be applied
>>>>> properly. Add support for building TI SoC specific .dtb files, the
>>>>> source is fetched from parent directory.
>>>>>
>>>>> Signed-off-by: Tero Kristo <t-kristo@ti.com>
>>>>
>>>>
>>>> Thanks for your patch!
>>>>
>>>>> ---
>>>>>    arch/arm/boot/dts/ti/Makefile | 5 +++++
>>>>>    1 file changed, 5 insertions(+)
>>>>>
>>>>> diff --git a/arch/arm/boot/dts/ti/Makefile
>>>>> b/arch/arm/boot/dts/ti/Makefile
>>>>> index b26328b..7d2d411 100644
>>>>> --- a/arch/arm/boot/dts/ti/Makefile
>>>>> +++ b/arch/arm/boot/dts/ti/Makefile
>>>>> @@ -1 +1,6 @@
>>>>> +DTC_FLAGS += -@ -Wno-reg_format -Wno-avoid_default_addr_size
>>>>
>>>>
>>>> Why the -W options?
>>>>
>>>>> +
>>>>> +$(obj)/%.dtb: $(src)/../%.dts FORCE
>>>>
>>>>
>>>> I guess you want a dependency on $(DTC), too?
>>>
>>>
>>> I think that is handled globally already. I did a fix not to long ago.
>>
>>
>> Globally it is handled, but as you see this is a special rule under the TI
>> SoC specific makefile. This is building the .dts files under
>> arch/arm/boot/dts/* into arch/arm/boot/dts/ti/ containing the symbol info
>> (-@ flag for DTC.)
> 
> Ah, I see. That means we end up with 2 builds of the base dtbs, right?

Yes, thats intentional in this series.

> We need to not do that. Either we need to be able to set per dtb flags
> or set per directory flags and move the TI base dts files to /ti
> directory.

Well, actually we kind of need two builds of the same file. One is for 
the base beagle-x15 board, which doesn't need any overlays, and as such, 
does not need the symbol info either. The other one needs symbol info, 
as it is used with applying overlays. The application of overlays can't 
be done without the symbol info.

If we force both builds to use symbols, then the resulting beagle-x15 
DTB file is unnecessarily large (the size delta might be irrelevant in 
practice, but it is there; ~40 kilobytes in this case, or +50% increase 
in size.)

-Tero
--
Texas Instruments Finland Oy, Porkkalankatu 22, 00180 Helsinki. Y-tunnus/Business ID: 0615521-4. Kotipaikka/Domicile: Helsinki

^ permalink raw reply	[flat|nested] 52+ messages in thread

* Re: [RFC 06/13] ARM: dts: am57xx-evm: add AM57xx-evm DT overlay
  2018-04-19  6:49     ` Tero Kristo
@ 2018-04-20  1:31       ` Rob Herring
  0 siblings, 0 replies; 52+ messages in thread
From: Rob Herring @ 2018-04-20  1:31 UTC (permalink / raw)
  To: Tero Kristo
  Cc: devicetree, Frank Rowand, Mark Rutland, Mills, William,
	Tony Lindgren, Tom Rini, Russell King

On Thu, Apr 19, 2018 at 1:49 AM, Tero Kristo <t-kristo@ti.com> wrote:
> On 19/04/18 03:19, Rob Herring wrote:
>>
>> On Tue, Apr 17, 2018 at 4:10 AM, Tero Kristo <t-kristo@ti.com> wrote:
>>>
>>> The AM57xx-evm is an overlay on top of beagle-x15 board. This contains
>>> a display extension macro, and a few extra peripherals. Two versions
>>> of the evm are supported, the base evm and the latest rev A3 evm. A
>>> common overlay file is used for both boards.
>>>
>>> Signed-off-by: Tero Kristo <t-kristo@ti.com>
>>> ---
>>>   arch/arm/boot/dts/ti/am57xx-evm-common.dtso | 175
>>> ++++++++++++++++++++++++++++
>>
>>
>> Why do this as an overlay? To what level is an AM57xx-evm functional
>> using a beagle-x15 dtb?
>
>
> Basically, am57xx-evm is just a beagle-x15 with an extension board
> physically plugged into it. If you don't add the am57xx-evm overlay, display
> (+ WLAN + some gpios) obviously don't work, but rest of the functionality
> does.
>
> If you have an am57xx-evm, you can also unplug the extension board to get a
> plain beagle-x15 board as I did, I don't typically care about things like
> display / WLAN in my work.

Okay, makes sense, but the naming convention doesn't really convey
these details. I guess users of the boards would understand this.

>>>   arch/arm/boot/dts/ti/am57xx-evm-reva3.dtso  |  11 ++
>>>   arch/arm/boot/dts/ti/am57xx-evm.dtso        |  11 ++
>>
>>
>> I think I'd structure this as just the A3 is an overlay. Applying it
>> will override everything in am57xx-evm.dtso, so what's the point to
>> making users of both board variations apply an overlay. Plus, you
>> could have only known the differences in the board revisions after you
>> had both boards. That wouldn't work if you developed this as new
>> boards appear.
>
>
> Well, beagle-x15 is still the base board for both, and different revisions
> of those also. The changes are relatively minor, but they are there. But
> yes, different hierarchies for these could be applied.

My point is that if you have 2 revisions of a given board, at some
point in time there was only 1 revision of that board. So you have a
dtb for that revision. Then a new revision comes out. You should not
be refactoring the existing dtbs based on what changed in the new
revision such that you have the common bits, rev 1 overlay and rev 2
overlay. Instead, make a rev 1 to rev 2 overlay.

Now if you have 2 different revisions in parallel that's a different
story. For example, if the beagle-x15 is stuffed differently for use
with the EVM vs. standalone.

Rob

^ permalink raw reply	[flat|nested] 52+ messages in thread

* Re: [RFC 06/13] ARM: dts: am57xx-evm: add AM57xx-evm DT overlay
  2018-04-18 19:15       ` Russell King
@ 2018-04-20 13:27         ` Geert Uytterhoeven
  0 siblings, 0 replies; 52+ messages in thread
From: Geert Uytterhoeven @ 2018-04-20 13:27 UTC (permalink / raw)
  To: Russell King
  Cc: Tero Kristo,
	open list:OPEN FIRMWARE AND FLATTENED DEVICE TREE BINDINGS,
	Rob Herring, Frank Rowand, Mark Rutland, wmills,
	ext Tony Lindgren, Tom Rini

Hi Russell,

On Wed, Apr 18, 2018 at 9:15 PM, Russell King <rmk@armlinux.org.uk> wrote:
> As already requested, can you *all* please use my linux@armlinux.org.uk
> address for this stuff please, and not rmk@armlinux.org.uk - it's
> screwing up my mailboxes.  Thanks.

I have no idea when you request that (sorry if I missed it), but your rmk
address is all over the Linux kernel sources.

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

^ permalink raw reply	[flat|nested] 52+ messages in thread

* Re: [RFC 12/13] ARM: dts: ti: add dra71-evm FIT description file
  2018-04-17 14:49       ` Tony Lindgren
@ 2018-05-21  6:57           ` Tero Kristo
  0 siblings, 0 replies; 52+ messages in thread
From: Tero Kristo @ 2018-05-21  6:57 UTC (permalink / raw)
  To: Tony Lindgren
  Cc: mark.rutland, devicetree, trini, Russell King - ARM Linux,
	robh+dt, frowand.list, wmills, linux-arm-kernel

On 17/04/18 17:49, Tony Lindgren wrote:
> * Tero Kristo <t-kristo@ti.com> [180417 09:36]:
>> In typical setup, you can boot a large number of different configs via:
>>
>> bootm 0x82000000#dra71-evm#nand#lcd-auo-g101evn01.0
>>
>> ... assuming the configs were named like that, and assuming they would be
>> compatible with each other. The am57xx-evm example provided is better, as
>> you can chain the different cameras to the available evm configs.
> 
> Why not just do it in the bootloader to put together the dtb?
> 
> Then for external devices, you could just pass info on the
> kernel cmdline with lcd=foo camera=bar if they cannot be
> detected over I2C.

(Added Linux ARM list to CC, this was not part of the original delivery.)

Ok trying to resurrect this thread a bit. Is there any kind of consensus 
how things like this should be handled? Should we add the DT overlay 
files to kernel tree or not?

Should we add any kind of build infra to kernel tree, and at what level 
would this be? Just DT overlay file building support, and drop the FIT 
build support as was proposed in this RFC series or...?

U-boot can obviously parse the base DTB + overlay DTB:s into a single 
DTB, but this is somewhat clumsy approach and is relatively error prone 
to get it right.

Building the FIT image post kernel build would also be possible, but who 
would be doing this, is there any need to get this done in generic 
manner or shall we just add SoC vendor specific tools for this?

-Tero
--
Texas Instruments Finland Oy, Porkkalankatu 22, 00180 Helsinki. Y-tunnus/Business ID: 0615521-4. Kotipaikka/Domicile: Helsinki

^ permalink raw reply	[flat|nested] 52+ messages in thread

* [RFC 12/13] ARM: dts: ti: add dra71-evm FIT description file
@ 2018-05-21  6:57           ` Tero Kristo
  0 siblings, 0 replies; 52+ messages in thread
From: Tero Kristo @ 2018-05-21  6:57 UTC (permalink / raw)
  To: linux-arm-kernel

On 17/04/18 17:49, Tony Lindgren wrote:
> * Tero Kristo <t-kristo@ti.com> [180417 09:36]:
>> In typical setup, you can boot a large number of different configs via:
>>
>> bootm 0x82000000#dra71-evm#nand#lcd-auo-g101evn01.0
>>
>> ... assuming the configs were named like that, and assuming they would be
>> compatible with each other. The am57xx-evm example provided is better, as
>> you can chain the different cameras to the available evm configs.
> 
> Why not just do it in the bootloader to put together the dtb?
> 
> Then for external devices, you could just pass info on the
> kernel cmdline with lcd=foo camera=bar if they cannot be
> detected over I2C.

(Added Linux ARM list to CC, this was not part of the original delivery.)

Ok trying to resurrect this thread a bit. Is there any kind of consensus 
how things like this should be handled? Should we add the DT overlay 
files to kernel tree or not?

Should we add any kind of build infra to kernel tree, and at what level 
would this be? Just DT overlay file building support, and drop the FIT 
build support as was proposed in this RFC series or...?

U-boot can obviously parse the base DTB + overlay DTB:s into a single 
DTB, but this is somewhat clumsy approach and is relatively error prone 
to get it right.

Building the FIT image post kernel build would also be possible, but who 
would be doing this, is there any need to get this done in generic 
manner or shall we just add SoC vendor specific tools for this?

-Tero
--
Texas Instruments Finland Oy, Porkkalankatu 22, 00180 Helsinki. Y-tunnus/Business ID: 0615521-4. Kotipaikka/Domicile: Helsinki

^ permalink raw reply	[flat|nested] 52+ messages in thread

* Re: [RFC 12/13] ARM: dts: ti: add dra71-evm FIT description file
  2018-05-21  6:57           ` Tero Kristo
@ 2018-05-22 20:01             ` Rob Herring
  -1 siblings, 0 replies; 52+ messages in thread
From: Rob Herring @ 2018-05-22 20:01 UTC (permalink / raw)
  To: Tero Kristo
  Cc: mark.rutland, devicetree, trini, Tony Lindgren,
	Russell King - ARM Linux, frowand.list, wmills, linux-arm-kernel

On Mon, May 21, 2018 at 09:57:54AM +0300, Tero Kristo wrote:
> On 17/04/18 17:49, Tony Lindgren wrote:
> > * Tero Kristo <t-kristo@ti.com> [180417 09:36]:
> > > In typical setup, you can boot a large number of different configs via:
> > > 
> > > bootm 0x82000000#dra71-evm#nand#lcd-auo-g101evn01.0
> > > 
> > > ... assuming the configs were named like that, and assuming they would be
> > > compatible with each other. The am57xx-evm example provided is better, as
> > > you can chain the different cameras to the available evm configs.
> > 
> > Why not just do it in the bootloader to put together the dtb?
> > 
> > Then for external devices, you could just pass info on the
> > kernel cmdline with lcd=foo camera=bar if they cannot be
> > detected over I2C.
> 
> (Added Linux ARM list to CC, this was not part of the original delivery.)
> 
> Ok trying to resurrect this thread a bit. Is there any kind of consensus how
> things like this should be handled? Should we add the DT overlay files to
> kernel tree or not?

IMO, yes.

> Should we add any kind of build infra to kernel tree, and at what level
> would this be? Just DT overlay file building support, and drop the FIT build
> support as was proposed in this RFC series or...?

I think I mentioned this already, but I expect that this is going to 
cause a number of conversions of dtsi + dtsi -> dtb into base dts and 
overlay(s) dts files. In doing so, we still need to be able to build the 
original, full dtb.

> U-boot can obviously parse the base DTB + overlay DTB:s into a single DTB,
> but this is somewhat clumsy approach and is relatively error prone to get it
> right.

Why? How is the kernel better?

> Building the FIT image post kernel build would also be possible, but who
> would be doing this, is there any need to get this done in generic manner or
> shall we just add SoC vendor specific tools for this?

I'll tell you up front, I'm not a fan of FIT image (nor uImage, 
Android boot image, $bootloader image). If you want a collection of 
files and some configuration data, use a filesystem and a text file.

Rob

^ permalink raw reply	[flat|nested] 52+ messages in thread

* [RFC 12/13] ARM: dts: ti: add dra71-evm FIT description file
@ 2018-05-22 20:01             ` Rob Herring
  0 siblings, 0 replies; 52+ messages in thread
From: Rob Herring @ 2018-05-22 20:01 UTC (permalink / raw)
  To: linux-arm-kernel

On Mon, May 21, 2018 at 09:57:54AM +0300, Tero Kristo wrote:
> On 17/04/18 17:49, Tony Lindgren wrote:
> > * Tero Kristo <t-kristo@ti.com> [180417 09:36]:
> > > In typical setup, you can boot a large number of different configs via:
> > > 
> > > bootm 0x82000000#dra71-evm#nand#lcd-auo-g101evn01.0
> > > 
> > > ... assuming the configs were named like that, and assuming they would be
> > > compatible with each other. The am57xx-evm example provided is better, as
> > > you can chain the different cameras to the available evm configs.
> > 
> > Why not just do it in the bootloader to put together the dtb?
> > 
> > Then for external devices, you could just pass info on the
> > kernel cmdline with lcd=foo camera=bar if they cannot be
> > detected over I2C.
> 
> (Added Linux ARM list to CC, this was not part of the original delivery.)
> 
> Ok trying to resurrect this thread a bit. Is there any kind of consensus how
> things like this should be handled? Should we add the DT overlay files to
> kernel tree or not?

IMO, yes.

> Should we add any kind of build infra to kernel tree, and at what level
> would this be? Just DT overlay file building support, and drop the FIT build
> support as was proposed in this RFC series or...?

I think I mentioned this already, but I expect that this is going to 
cause a number of conversions of dtsi + dtsi -> dtb into base dts and 
overlay(s) dts files. In doing so, we still need to be able to build the 
original, full dtb.

> U-boot can obviously parse the base DTB + overlay DTB:s into a single DTB,
> but this is somewhat clumsy approach and is relatively error prone to get it
> right.

Why? How is the kernel better?

> Building the FIT image post kernel build would also be possible, but who
> would be doing this, is there any need to get this done in generic manner or
> shall we just add SoC vendor specific tools for this?

I'll tell you up front, I'm not a fan of FIT image (nor uImage, 
Android boot image, $bootloader image). If you want a collection of 
files and some configuration data, use a filesystem and a text file.

Rob

^ permalink raw reply	[flat|nested] 52+ messages in thread

* Re: [RFC 12/13] ARM: dts: ti: add dra71-evm FIT description file
  2018-05-22 20:01             ` Rob Herring
@ 2018-05-23  5:55               ` Tero Kristo
  -1 siblings, 0 replies; 52+ messages in thread
From: Tero Kristo @ 2018-05-23  5:55 UTC (permalink / raw)
  To: Rob Herring
  Cc: mark.rutland, devicetree, trini, Tony Lindgren,
	Russell King - ARM Linux, frowand.list, wmills, linux-arm-kernel

On 22/05/18 23:01, Rob Herring wrote:
> On Mon, May 21, 2018 at 09:57:54AM +0300, Tero Kristo wrote:
>> On 17/04/18 17:49, Tony Lindgren wrote:
>>> * Tero Kristo <t-kristo@ti.com> [180417 09:36]:
>>>> In typical setup, you can boot a large number of different configs via:
>>>>
>>>> bootm 0x82000000#dra71-evm#nand#lcd-auo-g101evn01.0
>>>>
>>>> ... assuming the configs were named like that, and assuming they would be
>>>> compatible with each other. The am57xx-evm example provided is better, as
>>>> you can chain the different cameras to the available evm configs.
>>>
>>> Why not just do it in the bootloader to put together the dtb?
>>>
>>> Then for external devices, you could just pass info on the
>>> kernel cmdline with lcd=foo camera=bar if they cannot be
>>> detected over I2C.
>>
>> (Added Linux ARM list to CC, this was not part of the original delivery.)
>>
>> Ok trying to resurrect this thread a bit. Is there any kind of consensus how
>> things like this should be handled? Should we add the DT overlay files to
>> kernel tree or not?
> 
> IMO, yes.
> 
>> Should we add any kind of build infra to kernel tree, and at what level
>> would this be? Just DT overlay file building support, and drop the FIT build
>> support as was proposed in this RFC series or...?
> 
> I think I mentioned this already, but I expect that this is going to
> cause a number of conversions of dtsi + dtsi -> dtb into base dts and
> overlay(s) dts files. In doing so, we still need to be able to build the
> original, full dtb.

So you mean like breaking apart the existing .dts files? Are there any 
plans to get that done (I know the android folks talk about this but I 
don't like their idea.) If we do the split, how are we going to 
determine which dts + overlay files are required to get a specific DTB 
done? I actually wrote a tool for this purpose which parses the FIT 
image configurations and generates plain dtb files out of the info there 
if needed, but assuming FIT is abandoned then what...?

> 
>> U-boot can obviously parse the base DTB + overlay DTB:s into a single DTB,
>> but this is somewhat clumsy approach and is relatively error prone to get it
>> right.
> 
> Why? How is the kernel better?

I am mostly speaking about runtime applying of the overlays. If done 
build time, it is obviously on same level. If you apply the base DTS + 
overlays from u-boot prompt, it is not too much fun, and if there are 
any failures it just won't work, but don't really tell you why not.

> 
>> Building the FIT image post kernel build would also be possible, but who
>> would be doing this, is there any need to get this done in generic manner or
>> shall we just add SoC vendor specific tools for this?
> 
> I'll tell you up front, I'm not a fan of FIT image (nor uImage,
> Android boot image, $bootloader image). If you want a collection of
> files and some configuration data, use a filesystem and a text file.

Ok, thanks for your frank comments. I believe based on this feedback 
I'll try to modify this series into bare minimal overlay support to 
kernel, and have the post processing done elsewhere (either u-boot build 
or possibly completely separate tool.)

-Tero
--
Texas Instruments Finland Oy, Porkkalankatu 22, 00180 Helsinki. Y-tunnus/Business ID: 0615521-4. Kotipaikka/Domicile: Helsinki

^ permalink raw reply	[flat|nested] 52+ messages in thread

* [RFC 12/13] ARM: dts: ti: add dra71-evm FIT description file
@ 2018-05-23  5:55               ` Tero Kristo
  0 siblings, 0 replies; 52+ messages in thread
From: Tero Kristo @ 2018-05-23  5:55 UTC (permalink / raw)
  To: linux-arm-kernel

On 22/05/18 23:01, Rob Herring wrote:
> On Mon, May 21, 2018 at 09:57:54AM +0300, Tero Kristo wrote:
>> On 17/04/18 17:49, Tony Lindgren wrote:
>>> * Tero Kristo <t-kristo@ti.com> [180417 09:36]:
>>>> In typical setup, you can boot a large number of different configs via:
>>>>
>>>> bootm 0x82000000#dra71-evm#nand#lcd-auo-g101evn01.0
>>>>
>>>> ... assuming the configs were named like that, and assuming they would be
>>>> compatible with each other. The am57xx-evm example provided is better, as
>>>> you can chain the different cameras to the available evm configs.
>>>
>>> Why not just do it in the bootloader to put together the dtb?
>>>
>>> Then for external devices, you could just pass info on the
>>> kernel cmdline with lcd=foo camera=bar if they cannot be
>>> detected over I2C.
>>
>> (Added Linux ARM list to CC, this was not part of the original delivery.)
>>
>> Ok trying to resurrect this thread a bit. Is there any kind of consensus how
>> things like this should be handled? Should we add the DT overlay files to
>> kernel tree or not?
> 
> IMO, yes.
> 
>> Should we add any kind of build infra to kernel tree, and at what level
>> would this be? Just DT overlay file building support, and drop the FIT build
>> support as was proposed in this RFC series or...?
> 
> I think I mentioned this already, but I expect that this is going to
> cause a number of conversions of dtsi + dtsi -> dtb into base dts and
> overlay(s) dts files. In doing so, we still need to be able to build the
> original, full dtb.

So you mean like breaking apart the existing .dts files? Are there any 
plans to get that done (I know the android folks talk about this but I 
don't like their idea.) If we do the split, how are we going to 
determine which dts + overlay files are required to get a specific DTB 
done? I actually wrote a tool for this purpose which parses the FIT 
image configurations and generates plain dtb files out of the info there 
if needed, but assuming FIT is abandoned then what...?

> 
>> U-boot can obviously parse the base DTB + overlay DTB:s into a single DTB,
>> but this is somewhat clumsy approach and is relatively error prone to get it
>> right.
> 
> Why? How is the kernel better?

I am mostly speaking about runtime applying of the overlays. If done 
build time, it is obviously on same level. If you apply the base DTS + 
overlays from u-boot prompt, it is not too much fun, and if there are 
any failures it just won't work, but don't really tell you why not.

> 
>> Building the FIT image post kernel build would also be possible, but who
>> would be doing this, is there any need to get this done in generic manner or
>> shall we just add SoC vendor specific tools for this?
> 
> I'll tell you up front, I'm not a fan of FIT image (nor uImage,
> Android boot image, $bootloader image). If you want a collection of
> files and some configuration data, use a filesystem and a text file.

Ok, thanks for your frank comments. I believe based on this feedback 
I'll try to modify this series into bare minimal overlay support to 
kernel, and have the post processing done elsewhere (either u-boot build 
or possibly completely separate tool.)

-Tero
--
Texas Instruments Finland Oy, Porkkalankatu 22, 00180 Helsinki. Y-tunnus/Business ID: 0615521-4. Kotipaikka/Domicile: Helsinki

^ permalink raw reply	[flat|nested] 52+ messages in thread

* Re: [RFC 12/13] ARM: dts: ti: add dra71-evm FIT description file
  2018-05-23  5:55               ` Tero Kristo
@ 2018-05-23 14:13                 ` Rob Herring
  -1 siblings, 0 replies; 52+ messages in thread
From: Rob Herring @ 2018-05-23 14:13 UTC (permalink / raw)
  To: Tero Kristo
  Cc: Mark Rutland, devicetree, Tom Rini, Tony Lindgren,
	Russell King - ARM Linux, Frank Rowand, Mills, William,
	linux-arm-kernel

On Wed, May 23, 2018 at 12:55 AM, Tero Kristo <t-kristo@ti.com> wrote:
> On 22/05/18 23:01, Rob Herring wrote:
>>
>> On Mon, May 21, 2018 at 09:57:54AM +0300, Tero Kristo wrote:
>>>
>>> On 17/04/18 17:49, Tony Lindgren wrote:
>>>>
>>>> * Tero Kristo <t-kristo@ti.com> [180417 09:36]:
>>>>>
>>>>> In typical setup, you can boot a large number of different configs via:
>>>>>
>>>>> bootm 0x82000000#dra71-evm#nand#lcd-auo-g101evn01.0
>>>>>
>>>>> ... assuming the configs were named like that, and assuming they would
>>>>> be
>>>>> compatible with each other. The am57xx-evm example provided is better,
>>>>> as
>>>>> you can chain the different cameras to the available evm configs.
>>>>
>>>>
>>>> Why not just do it in the bootloader to put together the dtb?
>>>>
>>>> Then for external devices, you could just pass info on the
>>>> kernel cmdline with lcd=foo camera=bar if they cannot be
>>>> detected over I2C.
>>>
>>>
>>> (Added Linux ARM list to CC, this was not part of the original delivery.)
>>>
>>> Ok trying to resurrect this thread a bit. Is there any kind of consensus
>>> how
>>> things like this should be handled? Should we add the DT overlay files to
>>> kernel tree or not?
>>
>>
>> IMO, yes.
>>
>>> Should we add any kind of build infra to kernel tree, and at what level
>>> would this be? Just DT overlay file building support, and drop the FIT
>>> build
>>> support as was proposed in this RFC series or...?
>>
>>
>> I think I mentioned this already, but I expect that this is going to
>> cause a number of conversions of dtsi + dtsi -> dtb into base dts and
>> overlay(s) dts files. In doing so, we still need to be able to build the
>> original, full dtb.
>
>
> So you mean like breaking apart the existing .dts files? Are there any plans
> to get that done (I know the android folks talk about this but I don't like
> their idea.) If we do the split, how are we going to determine which dts +
> overlay files are required to get a specific DTB done? I actually wrote a
> tool for this purpose which parses the FIT image configurations and
> generates plain dtb files out of the info there if needed, but assuming FIT
> is abandoned then what...?

There aren't any plans that I'm aware of. I'm just assuming there are
some cases in the tree. It would just be some additional build rules:

board-kit.dtb: soc-som.dtb expansion-board.dtbo
  fdtoverlay -o $@ -i $^

We'd need to come up with some way to express the input and output
files in a kbuild way. Perhaps similar to how multiple module files
are done.

Even if you are adding new platforms, having the above would still be
good. It captures what base the overlays apply to and tests that
applying actually works (rather than leaving that for the user to do
in the bootloader). FIT images also have or need that information, so
perhaps we can define a format that works as input for both kbuild and
FIT images.

>>> U-boot can obviously parse the base DTB + overlay DTB:s into a single
>>> DTB,
>>> but this is somewhat clumsy approach and is relatively error prone to get
>>> it
>>> right.
>>
>>
>> Why? How is the kernel better?
>
>
> I am mostly speaking about runtime applying of the overlays. If done build
> time, it is obviously on same level. If you apply the base DTS + overlays
> from u-boot prompt, it is not too much fun, and if there are any failures it
> just won't work, but don't really tell you why not.

Runtime, but still at boot time, right?

How is the kernel going to have better error handling? Is libfdt error
handling worse than the kernel's overlay code?

I do think we need to standardize how we tell bootloaders what
overlays to apply. I expect that we'll do that as part of EBBR spec[1]
though that is not part of the immediate focus.

Rob

[1] https://github.com/ARM-software/ebbr

^ permalink raw reply	[flat|nested] 52+ messages in thread

* [RFC 12/13] ARM: dts: ti: add dra71-evm FIT description file
@ 2018-05-23 14:13                 ` Rob Herring
  0 siblings, 0 replies; 52+ messages in thread
From: Rob Herring @ 2018-05-23 14:13 UTC (permalink / raw)
  To: linux-arm-kernel

On Wed, May 23, 2018 at 12:55 AM, Tero Kristo <t-kristo@ti.com> wrote:
> On 22/05/18 23:01, Rob Herring wrote:
>>
>> On Mon, May 21, 2018 at 09:57:54AM +0300, Tero Kristo wrote:
>>>
>>> On 17/04/18 17:49, Tony Lindgren wrote:
>>>>
>>>> * Tero Kristo <t-kristo@ti.com> [180417 09:36]:
>>>>>
>>>>> In typical setup, you can boot a large number of different configs via:
>>>>>
>>>>> bootm 0x82000000#dra71-evm#nand#lcd-auo-g101evn01.0
>>>>>
>>>>> ... assuming the configs were named like that, and assuming they would
>>>>> be
>>>>> compatible with each other. The am57xx-evm example provided is better,
>>>>> as
>>>>> you can chain the different cameras to the available evm configs.
>>>>
>>>>
>>>> Why not just do it in the bootloader to put together the dtb?
>>>>
>>>> Then for external devices, you could just pass info on the
>>>> kernel cmdline with lcd=foo camera=bar if they cannot be
>>>> detected over I2C.
>>>
>>>
>>> (Added Linux ARM list to CC, this was not part of the original delivery.)
>>>
>>> Ok trying to resurrect this thread a bit. Is there any kind of consensus
>>> how
>>> things like this should be handled? Should we add the DT overlay files to
>>> kernel tree or not?
>>
>>
>> IMO, yes.
>>
>>> Should we add any kind of build infra to kernel tree, and at what level
>>> would this be? Just DT overlay file building support, and drop the FIT
>>> build
>>> support as was proposed in this RFC series or...?
>>
>>
>> I think I mentioned this already, but I expect that this is going to
>> cause a number of conversions of dtsi + dtsi -> dtb into base dts and
>> overlay(s) dts files. In doing so, we still need to be able to build the
>> original, full dtb.
>
>
> So you mean like breaking apart the existing .dts files? Are there any plans
> to get that done (I know the android folks talk about this but I don't like
> their idea.) If we do the split, how are we going to determine which dts +
> overlay files are required to get a specific DTB done? I actually wrote a
> tool for this purpose which parses the FIT image configurations and
> generates plain dtb files out of the info there if needed, but assuming FIT
> is abandoned then what...?

There aren't any plans that I'm aware of. I'm just assuming there are
some cases in the tree. It would just be some additional build rules:

board-kit.dtb: soc-som.dtb expansion-board.dtbo
  fdtoverlay -o $@ -i $^

We'd need to come up with some way to express the input and output
files in a kbuild way. Perhaps similar to how multiple module files
are done.

Even if you are adding new platforms, having the above would still be
good. It captures what base the overlays apply to and tests that
applying actually works (rather than leaving that for the user to do
in the bootloader). FIT images also have or need that information, so
perhaps we can define a format that works as input for both kbuild and
FIT images.

>>> U-boot can obviously parse the base DTB + overlay DTB:s into a single
>>> DTB,
>>> but this is somewhat clumsy approach and is relatively error prone to get
>>> it
>>> right.
>>
>>
>> Why? How is the kernel better?
>
>
> I am mostly speaking about runtime applying of the overlays. If done build
> time, it is obviously on same level. If you apply the base DTS + overlays
> from u-boot prompt, it is not too much fun, and if there are any failures it
> just won't work, but don't really tell you why not.

Runtime, but still at boot time, right?

How is the kernel going to have better error handling? Is libfdt error
handling worse than the kernel's overlay code?

I do think we need to standardize how we tell bootloaders what
overlays to apply. I expect that we'll do that as part of EBBR spec[1]
though that is not part of the immediate focus.

Rob

[1] https://github.com/ARM-software/ebbr

^ permalink raw reply	[flat|nested] 52+ messages in thread

* Re: [RFC 12/13] ARM: dts: ti: add dra71-evm FIT description file
  2018-05-23  5:55               ` Tero Kristo
@ 2018-05-23 18:37                 ` Tony Lindgren
  -1 siblings, 0 replies; 52+ messages in thread
From: Tony Lindgren @ 2018-05-23 18:37 UTC (permalink / raw)
  To: Tero Kristo
  Cc: mark.rutland, Rob Herring, devicetree, Russell King - ARM Linux,
	trini, frowand.list, wmills, linux-arm-kernel

* Tero Kristo <t-kristo@ti.com> [180523 05:58]:
> On 22/05/18 23:01, Rob Herring wrote:
> > On Mon, May 21, 2018 at 09:57:54AM +0300, Tero Kristo wrote:
> > > Ok trying to resurrect this thread a bit. Is there any kind of consensus how
> > > things like this should be handled? Should we add the DT overlay files to
> > > kernel tree or not?
> > 
> > IMO, yes.

I too agree the overlay files should be in the kernel rather than
people having to try to figure out where to find them.

No idea how we'll verify they'll build though :) Maybe we
just need randconfig support for DT overlay files too?

Regards,

Tony

^ permalink raw reply	[flat|nested] 52+ messages in thread

* [RFC 12/13] ARM: dts: ti: add dra71-evm FIT description file
@ 2018-05-23 18:37                 ` Tony Lindgren
  0 siblings, 0 replies; 52+ messages in thread
From: Tony Lindgren @ 2018-05-23 18:37 UTC (permalink / raw)
  To: linux-arm-kernel

* Tero Kristo <t-kristo@ti.com> [180523 05:58]:
> On 22/05/18 23:01, Rob Herring wrote:
> > On Mon, May 21, 2018 at 09:57:54AM +0300, Tero Kristo wrote:
> > > Ok trying to resurrect this thread a bit. Is there any kind of consensus how
> > > things like this should be handled? Should we add the DT overlay files to
> > > kernel tree or not?
> > 
> > IMO, yes.

I too agree the overlay files should be in the kernel rather than
people having to try to figure out where to find them.

No idea how we'll verify they'll build though :) Maybe we
just need randconfig support for DT overlay files too?

Regards,

Tony

^ permalink raw reply	[flat|nested] 52+ messages in thread

* Re: [RFC 12/13] ARM: dts: ti: add dra71-evm FIT description file
  2018-05-22 20:01             ` Rob Herring
@ 2018-05-29 17:05               ` Frank Rowand
  -1 siblings, 0 replies; 52+ messages in thread
From: Frank Rowand @ 2018-05-29 17:05 UTC (permalink / raw)
  To: Rob Herring, Tero Kristo
  Cc: mark.rutland, devicetree, trini, Tony Lindgren,
	Russell King - ARM Linux, wmills, linux-arm-kernel

On 05/22/18 13:01, Rob Herring wrote:
> On Mon, May 21, 2018 at 09:57:54AM +0300, Tero Kristo wrote:
>> On 17/04/18 17:49, Tony Lindgren wrote:
>>> * Tero Kristo <t-kristo@ti.com> [180417 09:36]:
>>>> In typical setup, you can boot a large number of different configs via:
>>>>
>>>> bootm 0x82000000#dra71-evm#nand#lcd-auo-g101evn01.0
>>>>
>>>> ... assuming the configs were named like that, and assuming they would be
>>>> compatible with each other. The am57xx-evm example provided is better, as
>>>> you can chain the different cameras to the available evm configs.
>>>
>>> Why not just do it in the bootloader to put together the dtb?
>>>
>>> Then for external devices, you could just pass info on the
>>> kernel cmdline with lcd=foo camera=bar if they cannot be
>>> detected over I2C.
>>
>> (Added Linux ARM list to CC, this was not part of the original delivery.)
>>
>> Ok trying to resurrect this thread a bit. Is there any kind of consensus how
>> things like this should be handled? Should we add the DT overlay files to
>> kernel tree or not?
> 
> IMO, yes.

Agreed.

> 
>> Should we add any kind of build infra to kernel tree, and at what level
>> would this be? Just DT overlay file building support, and drop the FIT build
>> support as was proposed in this RFC series or...?
> 
> I think I mentioned this already, but I expect that this is going to 
> cause a number of conversions of dtsi + dtsi -> dtb into base dts and 
> overlay(s) dts files. In doing so, we still need to be able to build the 
> original, full dtb.
> 
>> U-boot can obviously parse the base DTB + overlay DTB:s into a single DTB,
>> but this is somewhat clumsy approach and is relatively error prone to get it
>> right.
> 
> Why? How is the kernel better?
> 
>> Building the FIT image post kernel build would also be possible, but who
>> would be doing this, is there any need to get this done in generic manner or
>> shall we just add SoC vendor specific tools for this?
> 
> I'll tell you up front, I'm not a fan of FIT image (nor uImage, 
> Android boot image, $bootloader image). If you want a collection of 
> files and some configuration data, use a filesystem and a text file.

My gut feel is that using a filesystem and a text file is the easier way
to create the boot info.  But that also makes applying the overlay(s)
during early Linux boot (at the point of FDT unflattening) impractical
(can't access the file system without a driver, the driver depends on
the devicetree, the devicetree depends upon the overlay).

> 
> Rob
> 

^ permalink raw reply	[flat|nested] 52+ messages in thread

* [RFC 12/13] ARM: dts: ti: add dra71-evm FIT description file
@ 2018-05-29 17:05               ` Frank Rowand
  0 siblings, 0 replies; 52+ messages in thread
From: Frank Rowand @ 2018-05-29 17:05 UTC (permalink / raw)
  To: linux-arm-kernel

On 05/22/18 13:01, Rob Herring wrote:
> On Mon, May 21, 2018 at 09:57:54AM +0300, Tero Kristo wrote:
>> On 17/04/18 17:49, Tony Lindgren wrote:
>>> * Tero Kristo <t-kristo@ti.com> [180417 09:36]:
>>>> In typical setup, you can boot a large number of different configs via:
>>>>
>>>> bootm 0x82000000#dra71-evm#nand#lcd-auo-g101evn01.0
>>>>
>>>> ... assuming the configs were named like that, and assuming they would be
>>>> compatible with each other. The am57xx-evm example provided is better, as
>>>> you can chain the different cameras to the available evm configs.
>>>
>>> Why not just do it in the bootloader to put together the dtb?
>>>
>>> Then for external devices, you could just pass info on the
>>> kernel cmdline with lcd=foo camera=bar if they cannot be
>>> detected over I2C.
>>
>> (Added Linux ARM list to CC, this was not part of the original delivery.)
>>
>> Ok trying to resurrect this thread a bit. Is there any kind of consensus how
>> things like this should be handled? Should we add the DT overlay files to
>> kernel tree or not?
> 
> IMO, yes.

Agreed.

> 
>> Should we add any kind of build infra to kernel tree, and at what level
>> would this be? Just DT overlay file building support, and drop the FIT build
>> support as was proposed in this RFC series or...?
> 
> I think I mentioned this already, but I expect that this is going to 
> cause a number of conversions of dtsi + dtsi -> dtb into base dts and 
> overlay(s) dts files. In doing so, we still need to be able to build the 
> original, full dtb.
> 
>> U-boot can obviously parse the base DTB + overlay DTB:s into a single DTB,
>> but this is somewhat clumsy approach and is relatively error prone to get it
>> right.
> 
> Why? How is the kernel better?
> 
>> Building the FIT image post kernel build would also be possible, but who
>> would be doing this, is there any need to get this done in generic manner or
>> shall we just add SoC vendor specific tools for this?
> 
> I'll tell you up front, I'm not a fan of FIT image (nor uImage, 
> Android boot image, $bootloader image). If you want a collection of 
> files and some configuration data, use a filesystem and a text file.

My gut feel is that using a filesystem and a text file is the easier way
to create the boot info.  But that also makes applying the overlay(s)
during early Linux boot (at the point of FDT unflattening) impractical
(can't access the file system without a driver, the driver depends on
the devicetree, the devicetree depends upon the overlay).

> 
> Rob
> 

^ permalink raw reply	[flat|nested] 52+ messages in thread

* Re: [RFC 12/13] ARM: dts: ti: add dra71-evm FIT description file
  2018-05-29 17:05               ` Frank Rowand
@ 2018-05-29 17:33                 ` Russell King - ARM Linux
  -1 siblings, 0 replies; 52+ messages in thread
From: Russell King - ARM Linux @ 2018-05-29 17:33 UTC (permalink / raw)
  To: Frank Rowand
  Cc: mark.rutland, Rob Herring, devicetree, Tony Lindgren,
	Tero Kristo, trini, wmills, linux-arm-kernel

On Tue, May 29, 2018 at 10:05:37AM -0700, Frank Rowand wrote:
> On 05/22/18 13:01, Rob Herring wrote:
> > I'll tell you up front, I'm not a fan of FIT image (nor uImage, 
> > Android boot image, $bootloader image). If you want a collection of 
> > files and some configuration data, use a filesystem and a text file.

Me neither.

> My gut feel is that using a filesystem and a text file is the easier way
> to create the boot info.  But that also makes applying the overlay(s)
> during early Linux boot (at the point of FDT unflattening) impractical
> (can't access the file system without a driver, the driver depends on
> the devicetree, the devicetree depends upon the overlay).

Why do you want to apply overlays during the kernel boot?  The boot
loader should be providing the kernel with the merged DT to describe
the system that the kernel is running on - it's not the kernel's
job to put that together.

The whole point of DT is to make the kernel _less_ tied to the hardware
and more generic.  If we're going to introduce an entirely new set of
drivers into the kernel to "probe" the hardware to determine which
overlays are required, then that's really defeating the purpose of DT.

-- 
RMK's Patch system: http://www.armlinux.org.uk/developer/patches/
FTTC broadband for 0.8mile line in suburbia: sync at 8.8Mbps down 630kbps up
According to speedtest.net: 8.21Mbps down 510kbps up

^ permalink raw reply	[flat|nested] 52+ messages in thread

* [RFC 12/13] ARM: dts: ti: add dra71-evm FIT description file
@ 2018-05-29 17:33                 ` Russell King - ARM Linux
  0 siblings, 0 replies; 52+ messages in thread
From: Russell King - ARM Linux @ 2018-05-29 17:33 UTC (permalink / raw)
  To: linux-arm-kernel

On Tue, May 29, 2018 at 10:05:37AM -0700, Frank Rowand wrote:
> On 05/22/18 13:01, Rob Herring wrote:
> > I'll tell you up front, I'm not a fan of FIT image (nor uImage, 
> > Android boot image, $bootloader image). If you want a collection of 
> > files and some configuration data, use a filesystem and a text file.

Me neither.

> My gut feel is that using a filesystem and a text file is the easier way
> to create the boot info.  But that also makes applying the overlay(s)
> during early Linux boot (at the point of FDT unflattening) impractical
> (can't access the file system without a driver, the driver depends on
> the devicetree, the devicetree depends upon the overlay).

Why do you want to apply overlays during the kernel boot?  The boot
loader should be providing the kernel with the merged DT to describe
the system that the kernel is running on - it's not the kernel's
job to put that together.

The whole point of DT is to make the kernel _less_ tied to the hardware
and more generic.  If we're going to introduce an entirely new set of
drivers into the kernel to "probe" the hardware to determine which
overlays are required, then that's really defeating the purpose of DT.

-- 
RMK's Patch system: http://www.armlinux.org.uk/developer/patches/
FTTC broadband for 0.8mile line in suburbia: sync at 8.8Mbps down 630kbps up
According to speedtest.net: 8.21Mbps down 510kbps up

^ permalink raw reply	[flat|nested] 52+ messages in thread

* Re: [RFC 12/13] ARM: dts: ti: add dra71-evm FIT description file
  2018-05-29 17:33                 ` Russell King - ARM Linux
@ 2018-05-29 22:45                   ` Frank Rowand
  -1 siblings, 0 replies; 52+ messages in thread
From: Frank Rowand @ 2018-05-29 22:45 UTC (permalink / raw)
  To: Russell King - ARM Linux
  Cc: mark.rutland, Rob Herring, devicetree, Tony Lindgren,
	Tero Kristo, trini, wmills, linux-arm-kernel

On 05/29/18 10:33, Russell King - ARM Linux wrote:
> On Tue, May 29, 2018 at 10:05:37AM -0700, Frank Rowand wrote:
>> On 05/22/18 13:01, Rob Herring wrote:
>>> I'll tell you up front, I'm not a fan of FIT image (nor uImage, 
>>> Android boot image, $bootloader image). If you want a collection of 
>>> files and some configuration data, use a filesystem and a text file.
> 
> Me neither.
> 
>> My gut feel is that using a filesystem and a text file is the easier way
>> to create the boot info.  But that also makes applying the overlay(s)
>> during early Linux boot (at the point of FDT unflattening) impractical
>> (can't access the file system without a driver, the driver depends on
>> the devicetree, the devicetree depends upon the overlay).
> 
> Why do you want to apply overlays during the kernel boot?  The boot
> loader should be providing the kernel with the merged DT to describe
> the system that the kernel is running on - it's not the kernel's
> job to put that together.

I would much prefer that overlays get applied before the unflattened
devicetree is made available to the kernel instead of applying overlays
late in the boot (after many susbsystems and drivers are initialized)
or after boot.

If overlays are applied before the unflattened devicetree is made
available to the kernel then subsystems and drivers do not have to be
aware of the possibility of the data in the devicetree changing instead
of being invariant.  (I will call this "apply early overlays" later in
this email.)

There are use cases of overlays where the overlay is not available until
late in the boot, or after the boot completes.  I am not suggesting that
those use cases be ignored.  That is a completely different conversation.

If overlays are applied before the unflattened devicetree is made
available to the kernel, there are at least two obvious methods
(and I can think of at least one more) -- either the kernel does it
or the bootloader does it.  I do not see either of the two as being
the obvious and only correct choice.  If the kernel does it, then
there is no need for multiple bootloaders to implement the same code.
If the bootloaders do it, then there is no need for multiple kernels
(Linux, BSD, etc) to implement the same code.  I do not have a
strong opinion about whether the bootloaders or the kernels are a
better place to apply early overlays.


> The whole point of DT is to make the kernel _less_ tied to the hardware
> and more generic.  If we're going to introduce an entirely new set of
> drivers into the kernel to "probe" the hardware to determine which
> overlays are required, then that's really defeating the purpose of DT.

If you read my circular dependency sentence carefully, I said a kernel
driver is impractical for the task of getting the overlay.  So I agree.

If the kernel applies the overlay, an alternative to drivers is that the
kernel could receive the overlay(s) in a similar manner as the method it
currently receives the base devicetree.  (The overlay(s) could be
appended to the base devicetree, a wrapper could be placed around the
base devicetree and the overlay(s), or some other implementation.  There
are multiple ways to achieve the same result.)

^ permalink raw reply	[flat|nested] 52+ messages in thread

* [RFC 12/13] ARM: dts: ti: add dra71-evm FIT description file
@ 2018-05-29 22:45                   ` Frank Rowand
  0 siblings, 0 replies; 52+ messages in thread
From: Frank Rowand @ 2018-05-29 22:45 UTC (permalink / raw)
  To: linux-arm-kernel

On 05/29/18 10:33, Russell King - ARM Linux wrote:
> On Tue, May 29, 2018 at 10:05:37AM -0700, Frank Rowand wrote:
>> On 05/22/18 13:01, Rob Herring wrote:
>>> I'll tell you up front, I'm not a fan of FIT image (nor uImage, 
>>> Android boot image, $bootloader image). If you want a collection of 
>>> files and some configuration data, use a filesystem and a text file.
> 
> Me neither.
> 
>> My gut feel is that using a filesystem and a text file is the easier way
>> to create the boot info.  But that also makes applying the overlay(s)
>> during early Linux boot (at the point of FDT unflattening) impractical
>> (can't access the file system without a driver, the driver depends on
>> the devicetree, the devicetree depends upon the overlay).
> 
> Why do you want to apply overlays during the kernel boot?  The boot
> loader should be providing the kernel with the merged DT to describe
> the system that the kernel is running on - it's not the kernel's
> job to put that together.

I would much prefer that overlays get applied before the unflattened
devicetree is made available to the kernel instead of applying overlays
late in the boot (after many susbsystems and drivers are initialized)
or after boot.

If overlays are applied before the unflattened devicetree is made
available to the kernel then subsystems and drivers do not have to be
aware of the possibility of the data in the devicetree changing instead
of being invariant.  (I will call this "apply early overlays" later in
this email.)

There are use cases of overlays where the overlay is not available until
late in the boot, or after the boot completes.  I am not suggesting that
those use cases be ignored.  That is a completely different conversation.

If overlays are applied before the unflattened devicetree is made
available to the kernel, there are at least two obvious methods
(and I can think of at least one more) -- either the kernel does it
or the bootloader does it.  I do not see either of the two as being
the obvious and only correct choice.  If the kernel does it, then
there is no need for multiple bootloaders to implement the same code.
If the bootloaders do it, then there is no need for multiple kernels
(Linux, BSD, etc) to implement the same code.  I do not have a
strong opinion about whether the bootloaders or the kernels are a
better place to apply early overlays.


> The whole point of DT is to make the kernel _less_ tied to the hardware
> and more generic.  If we're going to introduce an entirely new set of
> drivers into the kernel to "probe" the hardware to determine which
> overlays are required, then that's really defeating the purpose of DT.

If you read my circular dependency sentence carefully, I said a kernel
driver is impractical for the task of getting the overlay.  So I agree.

If the kernel applies the overlay, an alternative to drivers is that the
kernel could receive the overlay(s) in a similar manner as the method it
currently receives the base devicetree.  (The overlay(s) could be
appended to the base devicetree, a wrapper could be placed around the
base devicetree and the overlay(s), or some other implementation.  There
are multiple ways to achieve the same result.)

^ permalink raw reply	[flat|nested] 52+ messages in thread

* Re: [RFC 12/13] ARM: dts: ti: add dra71-evm FIT description file
  2018-05-29 22:45                   ` Frank Rowand
@ 2018-05-29 22:51                     ` Russell King - ARM Linux
  -1 siblings, 0 replies; 52+ messages in thread
From: Russell King - ARM Linux @ 2018-05-29 22:51 UTC (permalink / raw)
  To: Frank Rowand
  Cc: mark.rutland, Rob Herring, devicetree, Tony Lindgren,
	Tero Kristo, trini, wmills, linux-arm-kernel

On Tue, May 29, 2018 at 03:45:12PM -0700, Frank Rowand wrote:
> If the kernel applies the overlay, an alternative to drivers is that the
> kernel could receive the overlay(s) in a similar manner as the method it
> currently receives the base devicetree.  (The overlay(s) could be
> appended to the base devicetree, a wrapper could be placed around the

No wrappers, sorry.  We already have too many places in the Linux
kernel and its decompressor that try to work out whether a device
tree or ATAGs are present and how large, and that is done in assembly
code.  We don't need more complexity to deal with some kind of
wrapping of device trees as well.

-- 
RMK's Patch system: http://www.armlinux.org.uk/developer/patches/
FTTC broadband for 0.8mile line in suburbia: sync at 8.8Mbps down 630kbps up
According to speedtest.net: 8.21Mbps down 510kbps up

^ permalink raw reply	[flat|nested] 52+ messages in thread

* [RFC 12/13] ARM: dts: ti: add dra71-evm FIT description file
@ 2018-05-29 22:51                     ` Russell King - ARM Linux
  0 siblings, 0 replies; 52+ messages in thread
From: Russell King - ARM Linux @ 2018-05-29 22:51 UTC (permalink / raw)
  To: linux-arm-kernel

On Tue, May 29, 2018 at 03:45:12PM -0700, Frank Rowand wrote:
> If the kernel applies the overlay, an alternative to drivers is that the
> kernel could receive the overlay(s) in a similar manner as the method it
> currently receives the base devicetree.  (The overlay(s) could be
> appended to the base devicetree, a wrapper could be placed around the

No wrappers, sorry.  We already have too many places in the Linux
kernel and its decompressor that try to work out whether a device
tree or ATAGs are present and how large, and that is done in assembly
code.  We don't need more complexity to deal with some kind of
wrapping of device trees as well.

-- 
RMK's Patch system: http://www.armlinux.org.uk/developer/patches/
FTTC broadband for 0.8mile line in suburbia: sync at 8.8Mbps down 630kbps up
According to speedtest.net: 8.21Mbps down 510kbps up

^ permalink raw reply	[flat|nested] 52+ messages in thread

end of thread, other threads:[~2018-05-29 22:51 UTC | newest]

Thread overview: 52+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2018-04-17  9:10 [RFC 00/13] ARM: dts: DT overlay support infra + some data Tero Kristo
2018-04-17  9:10 ` [RFC 01/13] ARM: dts: allow building .dtb files under platform subdirs Tero Kristo
2018-04-19  0:02   ` Rob Herring
2018-04-17  9:10 ` [RFC 02/13] ARM: dts: add support for building DT overlays Tero Kristo
2018-04-17  9:10 ` [RFC 03/13] ARM: dts: add subdir for TI SoC DT files Tero Kristo
2018-04-17  9:10 ` [RFC 04/13] kbuild: add support for building %.dtbo targets Tero Kristo
2018-04-18 14:16   ` Geert Uytterhoeven
2018-04-17  9:10 ` [RFC 05/13] ARM: dts: ti: add support for building .dtb files containing symbols Tero Kristo
2018-04-18 14:20   ` Geert Uytterhoeven
2018-04-18 19:07     ` Tero Kristo
2018-04-18 22:43     ` Rob Herring
2018-04-19  6:36       ` Tero Kristo
2018-04-19 15:26         ` Rob Herring
2018-04-19 18:00           ` Tero Kristo
2018-04-17  9:10 ` [RFC 06/13] ARM: dts: am57xx-evm: add AM57xx-evm DT overlay Tero Kristo
2018-04-18 14:36   ` Geert Uytterhoeven
2018-04-18 19:12     ` Tero Kristo
2018-04-18 19:15       ` Russell King
2018-04-20 13:27         ` Geert Uytterhoeven
2018-04-18 22:40     ` Rob Herring
2018-04-19  0:19   ` Rob Herring
2018-04-19  6:49     ` Tero Kristo
2018-04-20  1:31       ` Rob Herring
2018-04-17  9:10 ` [RFC 07/13] ARM: dts: ti: add camera overlays Tero Kristo
2018-04-17  9:10 ` [RFC 08/13] ARM: dts: ti: add dra71-evm overlays Tero Kristo
2018-04-17  9:10 ` [RFC 09/13] kbuild: add support for generating FIT images Tero Kristo
2018-04-17  9:10 ` [RFC 10/13] ARM: dts: add FIT image build support for ARM architecture Tero Kristo
2018-04-17  9:10 ` [RFC 11/13] ARM: dts: ti: add FIT image dependencies Tero Kristo
2018-04-17  9:10 ` [RFC 12/13] ARM: dts: ti: add dra71-evm FIT description file Tero Kristo
2018-04-17  9:29   ` Russell King
2018-04-17  9:34     ` Tero Kristo
2018-04-17 14:49       ` Tony Lindgren
2018-05-21  6:57         ` Tero Kristo
2018-05-21  6:57           ` Tero Kristo
2018-05-22 20:01           ` Rob Herring
2018-05-22 20:01             ` Rob Herring
2018-05-23  5:55             ` Tero Kristo
2018-05-23  5:55               ` Tero Kristo
2018-05-23 14:13               ` Rob Herring
2018-05-23 14:13                 ` Rob Herring
2018-05-23 18:37               ` Tony Lindgren
2018-05-23 18:37                 ` Tony Lindgren
2018-05-29 17:05             ` Frank Rowand
2018-05-29 17:05               ` Frank Rowand
2018-05-29 17:33               ` Russell King - ARM Linux
2018-05-29 17:33                 ` Russell King - ARM Linux
2018-05-29 22:45                 ` Frank Rowand
2018-05-29 22:45                   ` Frank Rowand
2018-05-29 22:51                   ` Russell King - ARM Linux
2018-05-29 22:51                     ` Russell King - ARM Linux
2018-04-17  9:10 ` [RFC 13/13] ARM: dts: ti: add am57xx-evm " Tero Kristo
2018-04-17  9:18 ` [RFC 00/13] ARM: dts: DT overlay support infra + some data Russell King

This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.