[RFC 00/13] ARM: dts: DT overlay support infra + some data

[RFC 00/13] ARM: dts: DT overlay support infra + some data

[Tero Kristo]

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

[RFC 01/13] ARM: dts: allow building .dtb files under platform subdirs

[Tero Kristo]

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

Re: [RFC 01/13] ARM: dts: allow building .dtb files under platform subdirs

[Rob Herring]

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

[RFC 02/13] ARM: dts: add support for building DT overlays

[Tero Kristo]

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

[RFC 03/13] ARM: dts: add subdir for TI SoC DT files

[Tero Kristo]

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

[RFC 04/13] kbuild: add support for building %.dtbo targets

[Tero Kristo]

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

Re: [RFC 04/13] kbuild: add support for building %.dtbo targets

[Geert Uytterhoeven]

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

[RFC 05/13] ARM: dts: ti: add support for building .dtb files containing symbols

[Tero Kristo]

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

Re: [RFC 05/13] ARM: dts: ti: add support for building .dtb files containing symbols

[Geert Uytterhoeven]

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

Re: [RFC 05/13] ARM: dts: ti: add support for building .dtb files containing symbols

[Tero Kristo]

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

Re: [RFC 05/13] ARM: dts: ti: add support for building .dtb files containing symbols

[Rob Herring]

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

Re: [RFC 05/13] ARM: dts: ti: add support for building .dtb files containing symbols

[Tero Kristo]

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

Re: [RFC 05/13] ARM: dts: ti: add support for building .dtb files containing symbols

[Rob Herring]

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

Re: [RFC 05/13] ARM: dts: ti: add support for building .dtb files containing symbols

[Tero Kristo]

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

[RFC 06/13] ARM: dts: am57xx-evm: add AM57xx-evm DT overlay

[Tero Kristo]

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

Re: [RFC 06/13] ARM: dts: am57xx-evm: add AM57xx-evm DT overlay

[Geert Uytterhoeven]

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

Re: [RFC 06/13] ARM: dts: am57xx-evm: add AM57xx-evm DT overlay

[Tero Kristo]

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

Re: [RFC 06/13] ARM: dts: am57xx-evm: add AM57xx-evm DT overlay

[Russell King]

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

Re: [RFC 06/13] ARM: dts: am57xx-evm: add AM57xx-evm DT overlay

[Geert Uytterhoeven]

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

Re: [RFC 06/13] ARM: dts: am57xx-evm: add AM57xx-evm DT overlay

[Rob Herring]

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

Re: [RFC 06/13] ARM: dts: am57xx-evm: add AM57xx-evm DT overlay

[Rob Herring]

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

Re: [RFC 06/13] ARM: dts: am57xx-evm: add AM57xx-evm DT overlay

[Tero Kristo]

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

Re: [RFC 06/13] ARM: dts: am57xx-evm: add AM57xx-evm DT overlay

[Rob Herring]

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

[RFC 07/13] ARM: dts: ti: add camera overlays

[Tero Kristo]

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

[RFC 08/13] ARM: dts: ti: add dra71-evm overlays

[Tero Kristo]

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

[RFC 09/13] kbuild: add support for generating FIT images

[Tero Kristo]

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

[RFC 10/13] ARM: dts: add FIT image build support for ARM architecture

[Tero Kristo]

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

[RFC 11/13] ARM: dts: ti: add FIT image dependencies

[Tero Kristo]

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

[RFC 12/13] ARM: dts: ti: add dra71-evm FIT description file

[Tero Kristo]

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

Re: [RFC 12/13] ARM: dts: ti: add dra71-evm FIT description file

[Russell King]

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

Re: [RFC 12/13] ARM: dts: ti: add dra71-evm FIT description file

[Tero Kristo]

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

Re: [RFC 12/13] ARM: dts: ti: add dra71-evm FIT description file

[Tony Lindgren]

* 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

Re: [RFC 12/13] ARM: dts: ti: add dra71-evm FIT description file

[Tero Kristo]

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

[RFC 12/13] ARM: dts: ti: add dra71-evm FIT description file

[Tero Kristo]

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

Re: [RFC 12/13] ARM: dts: ti: add dra71-evm FIT description file

[Rob Herring]

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

[RFC 12/13] ARM: dts: ti: add dra71-evm FIT description file

[Rob Herring]

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

Re: [RFC 12/13] ARM: dts: ti: add dra71-evm FIT description file

[Tero Kristo]

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

[RFC 12/13] ARM: dts: ti: add dra71-evm FIT description file

[Tero Kristo]

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

Re: [RFC 12/13] ARM: dts: ti: add dra71-evm FIT description file

[Rob Herring]

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

[RFC 12/13] ARM: dts: ti: add dra71-evm FIT description file

[Rob Herring]

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

Re: [RFC 12/13] ARM: dts: ti: add dra71-evm FIT description file

[Tony Lindgren]

* 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

[RFC 12/13] ARM: dts: ti: add dra71-evm FIT description file

[Tony Lindgren]

* 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

Re: [RFC 12/13] ARM: dts: ti: add dra71-evm FIT description file

[Frank Rowand]

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
> 

[RFC 12/13] ARM: dts: ti: add dra71-evm FIT description file

[Frank Rowand]

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
> 

Re: [RFC 12/13] ARM: dts: ti: add dra71-evm FIT description file

[Russell King - ARM Linux]

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

[RFC 12/13] ARM: dts: ti: add dra71-evm FIT description file

[Russell King - ARM Linux]

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

Re: [RFC 12/13] ARM: dts: ti: add dra71-evm FIT description file

[Frank Rowand]

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.)

[RFC 12/13] ARM: dts: ti: add dra71-evm FIT description file

[Frank Rowand]

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.)

Re: [RFC 12/13] ARM: dts: ti: add dra71-evm FIT description file

[Russell King - ARM Linux]

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

[RFC 12/13] ARM: dts: ti: add dra71-evm FIT description file

[Russell King - ARM Linux]

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

[RFC 13/13] ARM: dts: ti: add am57xx-evm FIT description file

[Tero Kristo]

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

Re: [RFC 00/13] ARM: dts: DT overlay support infra + some data

[Russell King]

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