[PATCH 0/8] An effort to bring DT bindings compliance within U-boot
Prerquisite -----------
This patch series requires devicetree-rebasing git repo to be added as a subtree to the main U-boot repo via:
$ git subtree add --prefix devicetree-rebasing \ git://git.kernel.org/pub/scm/linux/kernel/git/devicetree/devicetree-rebasing.git \ v6.6-dts --squash
Background ----------
This effort started while I was reviewing patch series corresponding to Qcom platforms [1] which was about to import modified devicetree source files from Linux kernel. I suppose keeping devicetree files sync with Linux kernel without any DT bindings schema validation has been a pain for U-boot SoC/platform maintainers. There has been past discussions about a single DT repo but that hasn't come up and Linux kernel remained the place where DT source files as well as bindings are placed and maintained.
However, Linux kernel DT maintainers proposed [2] for U-boot to rather use devicetree-rebasing repo [3] which is a forked copy from Linux kernel for DT source files as well as bindings. It is tagged at every Linux kernel major release or intermideate release candidates. So here I have tried to reuse that to bring DT bingings compliance as well as a standard way to maintain a regular sync of DT source files with Linux kernel.
In order to maintain devicetree files sync, U-boot will maintains a Git subtree for devicetee-rebasing repo as `devicetee-rebasing/` sub-directory. It will be regularly updated with every new kernel major release via subtree pull as follows::
$ git subtree pull --prefix devicetree-rebasing \ git://git.kernel.org/pub/scm/linux/kernel/git/devicetree/devicetree-rebasing.git \ <release-tag> --squash
The RFC/prototype for this series has been discussed with Linux DT maintainers as well as U-boot maintainers here [4]. Now we would like to reach out to wider U-boot community to seek feedback.
[1] https://lore.kernel.org/all/CAFA6WYMLUD9cnkr=R0Uur+1UeTMkKjM2zDdMJtXb3nmrLk+... [2] https://lore.kernel.org/all/CAL_JsqKEjv2tSGmT+0ZiO7_qbBfhTycbGnhJhYpKDFzfO9j... [3] https://git.kernel.org/pub/scm/linux/kernel/git/devicetree/devicetree-rebasi... [4] https://github.com/u-boot/u-boot/pull/451
Changes -------
Traditionally, U-boot placed copies of devicetree source files from Linux kernel into `arch/<arch>/dts/<name>.dts`, which can be selected via:
CONFIG_DEFAULT_DEVICE_TREE "<name>"
SoC/board maintainers are encouraged to migrate to using mirrored copies from `devicetree-rebasing/` into `dts/arch/<arch>/<vendor>` via:
CONFIG_OF_UPSTREAM=y CONFIG_DEFAULT_DEVICE_TREE "<vendor>/<name>"
An example have been shown for Amlogic meson-gxbb SoC and corresponding derived boards via patch #7 and #8.
Devicetree bindings schema checks ---------------------------------
With devicetee-rebasing Git subtree, the devicetree bindings are also regularly synced with Linux kernel as `devicetree-rebasing/Bindings/` sub-directory. This allows U-boot to run devicetree bindings schema checks which will bring compliance to U-boot core/drivers regarding usage of devicetree.
Dependencies ------------
The DT schema project must be installed in order to validate the DT schema binding documents and validate DTS files using the DT schema. The DT schema project can be installed with pip:
$ pip3 install dtschema
Note that 'dtschema' installation requires 'swig' and Python development files installed first. On Debian/Ubuntu systems:
$ apt install swig python3-dev
Several executables (dt-doc-validate, dt-mk-schema, dt-validate) will be installed. Ensure they are in your PATH (~/.local/bin by default).
Recommended is also to install yamllint (used by dtschema when present).
Running checks --------------
In order to perform validation of DTB files, use the ``dtbs_check`` target:
$ make dtbs_check
It is also possible to run checks with a subset of matching schema files by setting the ``DT_SCHEMA_FILES`` variable to 1 or more specific schema files or patterns (partial match of a fixed string). Each file or pattern should be separated by ':'.
$ make dtbs_check DT_SCHEMA_FILES=trivial-devices.yaml:rtc.yaml $ make dtbs_check DT_SCHEMA_FILES=/gpio/ $ make dtbs_check DT_SCHEMA_FILES=trivial-devices.yaml
Sumit Garg (8): Azure CI: Exclude devicetree-rebasing subtree for CONFIG checks Makefile: Add support for DT bindings schema checks scripts/Makefile.lib: Statically define *-u-boot.dtsi files location dts: Add alternative location for upstream DTB builds doc: devicetree: Updates for devicetree-rebasing subtree MAINTAINERS: Add myself as devicetree-rebasing maintainer dts: meson-gxbb: Switch to using upstream DT dts: meson-gxbb: Drop redundant devicetree files
.azure-pipelines.yml | 3 +- MAINTAINERS | 6 + Makefile | 20 +- arch/arm/dts/Makefile | 8 - arch/arm/dts/meson-gxbb-kii-pro.dts | 140 ---- arch/arm/dts/meson-gxbb-nanopi-k2.dts | 415 ------------ arch/arm/dts/meson-gxbb-odroidc2.dts | 418 ------------ arch/arm/dts/meson-gxbb-p200.dts | 100 --- arch/arm/dts/meson-gxbb-p201.dts | 26 - arch/arm/dts/meson-gxbb-p20x.dtsi | 250 ------- arch/arm/dts/meson-gxbb-wetek-hub.dts | 58 -- arch/arm/dts/meson-gxbb-wetek-play2.dts | 119 ---- arch/arm/dts/meson-gxbb-wetek.dtsi | 292 -------- arch/arm/dts/meson-gxbb.dtsi | 856 ------------------------ configs/nanopi-k2_defconfig | 3 +- configs/odroid-c2_defconfig | 3 +- configs/p200_defconfig | 3 +- configs/p201_defconfig | 3 +- configs/videostrong-kii-pro_defconfig | 3 +- configs/wetek-hub_defconfig | 3 +- configs/wetek-play2_defconfig | 3 +- doc/develop/devicetree/control.rst | 108 ++- dts/Kconfig | 11 + dts/Makefile | 17 +- dts/arch/arm64/Makefile | 23 + dts/arch/arm64/amlogic | 1 + scripts/Makefile.lib | 42 +- 27 files changed, 204 insertions(+), 2730 deletions(-) delete mode 100644 arch/arm/dts/meson-gxbb-kii-pro.dts delete mode 100644 arch/arm/dts/meson-gxbb-nanopi-k2.dts delete mode 100644 arch/arm/dts/meson-gxbb-odroidc2.dts delete mode 100644 arch/arm/dts/meson-gxbb-p200.dts delete mode 100644 arch/arm/dts/meson-gxbb-p201.dts delete mode 100644 arch/arm/dts/meson-gxbb-p20x.dtsi delete mode 100644 arch/arm/dts/meson-gxbb-wetek-hub.dts delete mode 100644 arch/arm/dts/meson-gxbb-wetek-play2.dts delete mode 100644 arch/arm/dts/meson-gxbb-wetek.dtsi delete mode 100644 arch/arm/dts/meson-gxbb.dtsi create mode 100644 dts/arch/arm64/Makefile create mode 120000 dts/arch/arm64/amlogic
Signed-off-by: Sumit Garg sumit.garg@linaro.org --- .azure-pipelines.yml | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/.azure-pipelines.yml b/.azure-pipelines.yml index d6f3fa423c6..f100c4493e6 100644 --- a/.azure-pipelines.yml +++ b/.azure-pipelines.yml @@ -65,7 +65,8 @@ stages: # have no matches. - script: git grep -E '^#[[:blank:]]*(define|undef)[[:blank:]]*CONFIG_' :^doc/ :^arch/arm/dts/ :^scripts/kconfig/lkc.h - :^include/linux/kconfig.h :^tools/ && exit 1 || exit 0 + :^include/linux/kconfig.h :^tools/ :^devicetree-rebasing/ && + exit 1 || exit 0
- job: docs displayName: 'Build documentation'
On Thu, Dec 14, 2023 at 07:20:56PM +0530, Sumit Garg wrote:
Signed-off-by: Sumit Garg sumit.garg@linaro.org
.azure-pipelines.yml | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/.azure-pipelines.yml b/.azure-pipelines.yml index d6f3fa423c6..f100c4493e6 100644 --- a/.azure-pipelines.yml +++ b/.azure-pipelines.yml @@ -65,7 +65,8 @@ stages: # have no matches. - script: git grep -E '^#[[:blank:]]*(define|undef)[[:blank:]]*CONFIG_' :^doc/ :^arch/arm/dts/ :^scripts/kconfig/lkc.h
:^include/linux/kconfig.h :^tools/ && exit 1 || exit 0
:^include/linux/kconfig.h :^tools/ :^devicetree-rebasing/ &&exit 1 || exit 0
- job: docs displayName: 'Build documentation'
The GitLab tests needs an equivalent change.
On Thu, 14 Dec 2023 at 19:57, Tom Rini trini@konsulko.com wrote:
On Thu, Dec 14, 2023 at 07:20:56PM +0530, Sumit Garg wrote:
Signed-off-by: Sumit Garg sumit.garg@linaro.org
.azure-pipelines.yml | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/.azure-pipelines.yml b/.azure-pipelines.yml index d6f3fa423c6..f100c4493e6 100644 --- a/.azure-pipelines.yml +++ b/.azure-pipelines.yml @@ -65,7 +65,8 @@ stages: # have no matches. - script: git grep -E '^#[[:blank:]]*(define|undef)[[:blank:]]*CONFIG_' :^doc/ :^arch/arm/dts/ :^scripts/kconfig/lkc.h
:^include/linux/kconfig.h :^tools/ && exit 1 || exit 0
:^include/linux/kconfig.h :^tools/ :^devicetree-rebasing/ &&exit 1 || exit 0
- job: docs displayName: 'Build documentation'
The GitLab tests needs an equivalent change.
Sure I will do that in the next spin of this patch-set, thanks for catching it.
-Sumit
-- Tom
Hi Sumit,
On Thu, 14 Dec 2023 at 07:46, Sumit Garg sumit.garg@linaro.org wrote:
On Thu, 14 Dec 2023 at 19:57, Tom Rini trini@konsulko.com wrote:
On Thu, Dec 14, 2023 at 07:20:56PM +0530, Sumit Garg wrote:
Signed-off-by: Sumit Garg sumit.garg@linaro.org
.azure-pipelines.yml | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/.azure-pipelines.yml b/.azure-pipelines.yml index d6f3fa423c6..f100c4493e6 100644 --- a/.azure-pipelines.yml +++ b/.azure-pipelines.yml @@ -65,7 +65,8 @@ stages: # have no matches. - script: git grep -E '^#[[:blank:]]*(define|undef)[[:blank:]]*CONFIG_' :^doc/ :^arch/arm/dts/ :^scripts/kconfig/lkc.h
:^include/linux/kconfig.h :^tools/ && exit 1 || exit 0
:^include/linux/kconfig.h :^tools/ :^devicetree-rebasing/ &&exit 1 || exit 0
- job: docs displayName: 'Build documentation'
The GitLab tests needs an equivalent change.
Sure I will do that in the next spin of this patch-set, thanks for catching it.
Also, please add a commit message with that :-)
Regards, Simon
On Wed, 20 Dec 2023 at 10:17, Simon Glass sjg@chromium.org wrote:
Hi Sumit,
On Thu, 14 Dec 2023 at 07:46, Sumit Garg sumit.garg@linaro.org wrote:
On Thu, 14 Dec 2023 at 19:57, Tom Rini trini@konsulko.com wrote:
On Thu, Dec 14, 2023 at 07:20:56PM +0530, Sumit Garg wrote:
Signed-off-by: Sumit Garg sumit.garg@linaro.org
.azure-pipelines.yml | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/.azure-pipelines.yml b/.azure-pipelines.yml index d6f3fa423c6..f100c4493e6 100644 --- a/.azure-pipelines.yml +++ b/.azure-pipelines.yml @@ -65,7 +65,8 @@ stages: # have no matches. - script: git grep -E '^#[[:blank:]]*(define|undef)[[:blank:]]*CONFIG_' :^doc/ :^arch/arm/dts/ :^scripts/kconfig/lkc.h
:^include/linux/kconfig.h :^tools/ && exit 1 || exit 0
:^include/linux/kconfig.h :^tools/ :^devicetree-rebasing/ &&exit 1 || exit 0
- job: docs displayName: 'Build documentation'
The GitLab tests needs an equivalent change.
Sure I will do that in the next spin of this patch-set, thanks for catching it.
Also, please add a commit message with that :-)
Ack.
-Sumit
Regards, Simon
This adds the build infrastructure for checking DT binding schema documents and validating dtb files using the binding schema. Here we use devicetree-rebasing directory to provide the DT bindings.
Dependency: -----------
The DT schema project must be installed in order to validate the DT schema binding documents and validate DTS files using the DT schema. The DT schema project can be installed with pip::
pip3 install dtschema
Note that 'dtschema' installation requires 'swig' and Python development files installed first. On Debian/Ubuntu systems::
apt install swig python3-dev
Testing: --------
Build dts files and check using DT binding schema: $ make dtbs_check
Optionally, DT_SCHEMA_FILES can be passed in with a schema file(s) to use for validation. This makes it easier to find and fix errors generated by a specific schema.
Note, at this point dtbs_check is an optional build target as there are many warnings generated due to custom DT properties used by many platforms in u-boot. It is expected with these checks that compliance with DT bindings to take place. Once that's done it can be added to CI builds to remain compliant with DT bindings.
Signed-off-by: Sumit Garg sumit.garg@linaro.org --- Makefile | 20 ++++++++++++++++++-- scripts/Makefile.lib | 17 +++++++++++++++-- 2 files changed, 33 insertions(+), 4 deletions(-)
diff --git a/Makefile b/Makefile index 750bbdb1b71..d8d168cd4c3 100644 --- a/Makefile +++ b/Makefile @@ -1158,12 +1158,28 @@ endif @# disabling OF_BOARD. $(call cmd,ofcheck,$(KCONFIG_CONFIG))
-PHONY += dtbs +PHONY += dtbs dtbs_check dtbs: dts/dt.dtb @: -dts/dt.dtb: u-boot +dts/dt.dtb: dtbs_prepare u-boot $(Q)$(MAKE) $(build)=dts dtbs
+dtbs_prepare: prepare3 + +ifneq ($(filter dtbs_check, $(MAKECMDGOALS)),) +export CHECK_DTBS=y +endif + +ifneq ($(CHECK_DTBS),) +dtbs_prepare: dt_binding_check +endif + +dtbs_check: dt_binding_check dtbs + +DT_BINDING_DIR := devicetree-rebasing/Bindings +dt_binding_check: scripts_dtc + $(Q)$(MAKE) $(build)=$(DT_BINDING_DIR) $(DT_BINDING_DIR)/processed-schema.json + quiet_cmd_copy = COPY $@ cmd_copy = cp $< $@
diff --git a/scripts/Makefile.lib b/scripts/Makefile.lib index 16bbc277a9f..27b9437027c 100644 --- a/scripts/Makefile.lib +++ b/scripts/Makefile.lib @@ -356,8 +356,21 @@ endif
dtsi_include_list_deps = $(addprefix $(obj)/,$(subst $(quote),,$(dtsi_include_list)))
-$(obj)/%.dtb: $(src)/%.dts $(DTC) $(dtsi_include_list_deps) FORCE - $(call if_changed_dep,dtc) +ifneq ($(CHECK_DTBS),) +DT_CHECKER ?= dt-validate +DT_CHECKER_FLAGS ?= $(if $(DT_SCHEMA_FILES),-l $(DT_SCHEMA_FILES),-m) +DT_BINDING_DIR := devicetree-rebasing/Bindings +DT_TMP_SCHEMA := $(objtree)/$(DT_BINDING_DIR)/processed-schema.json + +quiet_cmd_dtb = DTC_CHK $@ + cmd_dtb = $(cmd_dtc) ; $(DT_CHECKER) $(DT_CHECKER_FLAGS) -u $(srctree)/$(DT_BINDING_DIR) -p $(DT_TMP_SCHEMA) $@ || true +else +quiet_cmd_dtb = $(quiet_cmd_dtc) + cmd_dtb = $(cmd_dtc) +endif + +$(obj)/%.dtb: $(src)/%.dts $(DTC) $(dtsi_include_list_deps) $(DT_TMP_SCHEMA) FORCE + $(call if_changed_dep,dtb)
pre-tmp = $(subst $(comma),_,$(dot-target).pre.tmp) dtc-tmp = $(subst $(comma),_,$(dot-target).dts.tmp)
Hi Sumit,
On Thu, 14 Dec 2023 at 06:51, Sumit Garg sumit.garg@linaro.org wrote:
This adds the build infrastructure for checking DT binding schema documents and validating dtb files using the binding schema. Here we use devicetree-rebasing directory to provide the DT bindings.
Dependency:
The DT schema project must be installed in order to validate the DT schema binding documents and validate DTS files using the DT schema. The DT schema project can be installed with pip::
pip3 install dtschemaNote that 'dtschema' installation requires 'swig' and Python development files installed first. On Debian/Ubuntu systems::
apt install swig python3-devTesting:
Build dts files and check using DT binding schema: $ make dtbs_check
Optionally, DT_SCHEMA_FILES can be passed in with a schema file(s) to use for validation. This makes it easier to find and fix errors generated by a specific schema.
Note, at this point dtbs_check is an optional build target as there are many warnings generated due to custom DT properties used by many platforms in u-boot. It is expected with these checks that compliance with DT bindings to take place. Once that's done it can be added to CI builds to remain compliant with DT bindings.
Signed-off-by: Sumit Garg sumit.garg@linaro.org
Makefile | 20 ++++++++++++++++++-- scripts/Makefile.lib | 17 +++++++++++++++-- 2 files changed, 33 insertions(+), 4 deletions(-)
diff --git a/Makefile b/Makefile index 750bbdb1b71..d8d168cd4c3 100644 --- a/Makefile +++ b/Makefile @@ -1158,12 +1158,28 @@ endif @# disabling OF_BOARD. $(call cmd,ofcheck,$(KCONFIG_CONFIG))
-PHONY += dtbs +PHONY += dtbs dtbs_check dtbs: dts/dt.dtb @: -dts/dt.dtb: u-boot +dts/dt.dtb: dtbs_prepare u-boot $(Q)$(MAKE) $(build)=dts dtbs
+dtbs_prepare: prepare3
+ifneq ($(filter dtbs_check, $(MAKECMDGOALS)),) +export CHECK_DTBS=y +endif
+ifneq ($(CHECK_DTBS),) +dtbs_prepare: dt_binding_check +endif
+dtbs_check: dt_binding_check dtbs
+DT_BINDING_DIR := devicetree-rebasing/Bindings +dt_binding_check: scripts_dtc
$(Q)$(MAKE) $(build)=$(DT_BINDING_DIR) $(DT_BINDING_DIR)/processed-schema.jsonquiet_cmd_copy = COPY $@ cmd_copy = cp $< $@
diff --git a/scripts/Makefile.lib b/scripts/Makefile.lib index 16bbc277a9f..27b9437027c 100644 --- a/scripts/Makefile.lib +++ b/scripts/Makefile.lib @@ -356,8 +356,21 @@ endif
dtsi_include_list_deps = $(addprefix $(obj)/,$(subst $(quote),,$(dtsi_include_list)))
-$(obj)/%.dtb: $(src)/%.dts $(DTC) $(dtsi_include_list_deps) FORCE
$(call if_changed_dep,dtc)+ifneq ($(CHECK_DTBS),) +DT_CHECKER ?= dt-validate +DT_CHECKER_FLAGS ?= $(if $(DT_SCHEMA_FILES),-l $(DT_SCHEMA_FILES),-m) +DT_BINDING_DIR := devicetree-rebasing/Bindings +DT_TMP_SCHEMA := $(objtree)/$(DT_BINDING_DIR)/processed-schema.json
+quiet_cmd_dtb = DTC_CHK $@
cmd_dtb = $(cmd_dtc) ; $(DT_CHECKER) $(DT_CHECKER_FLAGS) -u $(srctree)/$(DT_BINDING_DIR) -p $(DT_TMP_SCHEMA) $@ || true+else +quiet_cmd_dtb = $(quiet_cmd_dtc)
cmd_dtb = $(cmd_dtc)+endif
+$(obj)/%.dtb: $(src)/%.dts $(DTC) $(dtsi_include_list_deps) $(DT_TMP_SCHEMA) FORCE
$(call if_changed_dep,dtb)pre-tmp = $(subst $(comma),_,$(dot-target).pre.tmp) dtc-tmp = $(subst $(comma),_,$(dot-target).dts.tmp) -- 2.34.1
This is great.
Can you put the commit message in doc/ somewhere?
Regards, Simon
On Wed, 20 Dec 2023 at 10:17, Simon Glass sjg@chromium.org wrote:
Hi Sumit,
On Thu, 14 Dec 2023 at 06:51, Sumit Garg sumit.garg@linaro.org wrote:
This adds the build infrastructure for checking DT binding schema documents and validating dtb files using the binding schema. Here we use devicetree-rebasing directory to provide the DT bindings.
Dependency:
The DT schema project must be installed in order to validate the DT schema binding documents and validate DTS files using the DT schema. The DT schema project can be installed with pip::
pip3 install dtschemaNote that 'dtschema' installation requires 'swig' and Python development files installed first. On Debian/Ubuntu systems::
apt install swig python3-devTesting:
Build dts files and check using DT binding schema: $ make dtbs_check
Optionally, DT_SCHEMA_FILES can be passed in with a schema file(s) to use for validation. This makes it easier to find and fix errors generated by a specific schema.
Note, at this point dtbs_check is an optional build target as there are many warnings generated due to custom DT properties used by many platforms in u-boot. It is expected with these checks that compliance with DT bindings to take place. Once that's done it can be added to CI builds to remain compliant with DT bindings.
Signed-off-by: Sumit Garg sumit.garg@linaro.org
Makefile | 20 ++++++++++++++++++-- scripts/Makefile.lib | 17 +++++++++++++++-- 2 files changed, 33 insertions(+), 4 deletions(-)
diff --git a/Makefile b/Makefile index 750bbdb1b71..d8d168cd4c3 100644 --- a/Makefile +++ b/Makefile @@ -1158,12 +1158,28 @@ endif @# disabling OF_BOARD. $(call cmd,ofcheck,$(KCONFIG_CONFIG))
-PHONY += dtbs +PHONY += dtbs dtbs_check dtbs: dts/dt.dtb @: -dts/dt.dtb: u-boot +dts/dt.dtb: dtbs_prepare u-boot $(Q)$(MAKE) $(build)=dts dtbs
+dtbs_prepare: prepare3
+ifneq ($(filter dtbs_check, $(MAKECMDGOALS)),) +export CHECK_DTBS=y +endif
+ifneq ($(CHECK_DTBS),) +dtbs_prepare: dt_binding_check +endif
+dtbs_check: dt_binding_check dtbs
+DT_BINDING_DIR := devicetree-rebasing/Bindings +dt_binding_check: scripts_dtc
$(Q)$(MAKE) $(build)=$(DT_BINDING_DIR) $(DT_BINDING_DIR)/processed-schema.jsonquiet_cmd_copy = COPY $@ cmd_copy = cp $< $@
diff --git a/scripts/Makefile.lib b/scripts/Makefile.lib index 16bbc277a9f..27b9437027c 100644 --- a/scripts/Makefile.lib +++ b/scripts/Makefile.lib @@ -356,8 +356,21 @@ endif
dtsi_include_list_deps = $(addprefix $(obj)/,$(subst $(quote),,$(dtsi_include_list)))
-$(obj)/%.dtb: $(src)/%.dts $(DTC) $(dtsi_include_list_deps) FORCE
$(call if_changed_dep,dtc)+ifneq ($(CHECK_DTBS),) +DT_CHECKER ?= dt-validate +DT_CHECKER_FLAGS ?= $(if $(DT_SCHEMA_FILES),-l $(DT_SCHEMA_FILES),-m) +DT_BINDING_DIR := devicetree-rebasing/Bindings +DT_TMP_SCHEMA := $(objtree)/$(DT_BINDING_DIR)/processed-schema.json
+quiet_cmd_dtb = DTC_CHK $@
cmd_dtb = $(cmd_dtc) ; $(DT_CHECKER) $(DT_CHECKER_FLAGS) -u $(srctree)/$(DT_BINDING_DIR) -p $(DT_TMP_SCHEMA) $@ || true+else +quiet_cmd_dtb = $(quiet_cmd_dtc)
cmd_dtb = $(cmd_dtc)+endif
+$(obj)/%.dtb: $(src)/%.dts $(DTC) $(dtsi_include_list_deps) $(DT_TMP_SCHEMA) FORCE
$(call if_changed_dep,dtb)pre-tmp = $(subst $(comma),_,$(dot-target).pre.tmp) dtc-tmp = $(subst $(comma),_,$(dot-target).dts.tmp) -- 2.34.1
This is great.
Can you put the commit message in doc/ somewhere?
As per your comment on the doc patch, this is already addressed.
-Sumit
Regards, Simon
Allow u-boot to build DTB from a different directory tree such that *-u-boot.dtsi files can be included from a common location. Currently that location is arch/$(ARCH)/dts/, so statically define that common location.
This is needed for platform owners to start building DTB files from devicetree-rebasing directory but still being able to include *-u-boot.dtsi files.
Signed-off-by: Sumit Garg sumit.garg@linaro.org --- scripts/Makefile.lib | 25 ++++++++++++++----------- 1 file changed, 14 insertions(+), 11 deletions(-)
diff --git a/scripts/Makefile.lib b/scripts/Makefile.lib index 27b9437027c..4a002b0e0ca 100644 --- a/scripts/Makefile.lib +++ b/scripts/Makefile.lib @@ -159,18 +159,20 @@ cpp_flags = -Wp,-MD,$(depfile) $(NOSTDINC_FLAGS) $(UBOOTINCLUDE) \ ld_flags = $(KBUILD_LDFLAGS) $(ldflags-y) $(LDFLAGS_$(@F))
# Try these files in order to find the U-Boot-specific .dtsi include file -u_boot_dtsi_options = $(strip $(wildcard $(dir $<)$(basename $(notdir $<))-u-boot.dtsi) \ - $(wildcard $(dir $<)$(subst $",,$(CONFIG_SYS_SOC))-u-boot.dtsi) \ - $(wildcard $(dir $<)$(subst $",,$(CONFIG_SYS_CPU))-u-boot.dtsi) \ - $(wildcard $(dir $<)$(subst $",,$(CONFIG_SYS_VENDOR))-u-boot.dtsi) \ - $(wildcard $(dir $<)u-boot.dtsi)) +UBOOT_DTSI_LOC = $(srctree)/arch/$(ARCH)/dts/ + +u_boot_dtsi_options = $(strip $(wildcard $(UBOOT_DTSI_LOC)$(basename $(notdir $<))-u-boot.dtsi) \ + $(wildcard $(UBOOT_DTSI_LOC)$(subst $",,$(CONFIG_SYS_SOC))-u-boot.dtsi) \ + $(wildcard $(UBOOT_DTSI_LOC)$(subst $",,$(CONFIG_SYS_CPU))-u-boot.dtsi) \ + $(wildcard $(UBOOT_DTSI_LOC)$(subst $",,$(CONFIG_SYS_VENDOR))-u-boot.dtsi) \ + $(wildcard $(UBOOT_DTSI_LOC)u-boot.dtsi))
u_boot_dtsi_options_raw = $(warning Automatic .dtsi inclusion: options: \ - $(dir $<)$(basename $(notdir $<))-u-boot.dtsi \ - $(dir $<)$(subst $",,$(CONFIG_SYS_SOC))-u-boot.dtsi \ - $(dir $<)$(subst $",,$(CONFIG_SYS_CPU))-u-boot.dtsi \ - $(dir $<)$(subst $",,$(CONFIG_SYS_VENDOR))-u-boot.dtsi \ - $(dir $<)u-boot.dtsi ... \ + $(UBOOT_DTSI_LOC)$(basename $(notdir $<))-u-boot.dtsi \ + $(UBOOT_DTSI_LOC)$(subst $",,$(CONFIG_SYS_SOC))-u-boot.dtsi \ + $(UBOOT_DTSI_LOC)$(subst $",,$(CONFIG_SYS_CPU))-u-boot.dtsi \ + $(UBOOT_DTSI_LOC)$(subst $",,$(CONFIG_SYS_VENDOR))-u-boot.dtsi \ + $(UBOOT_DTSI_LOC)u-boot.dtsi ... \ found: $(if $(u_boot_dtsi_options),"$(u_boot_dtsi_options)",nothing!))
# Uncomment for debugging @@ -190,6 +192,7 @@ dtsi_include_list += $(CONFIG_DEVICE_TREE_INCLUDES) dtc_cpp_flags = -Wp,-MD,$(depfile).pre.tmp -nostdinc \ $(UBOOTINCLUDE) \ -I$(dir $<) \ + -I$(UBOOT_DTSI_LOC) \ -I$(srctree)/arch/$(ARCH)/dts/include \ -I$(srctree)/include \ -D__ASSEMBLY__ \ @@ -328,7 +331,7 @@ cmd_dtc = mkdir -p $(dir ${dtc-tmp}) ; \ echo '$(pound)include "$(f)"' >> $(pre-tmp);) \ $(HOSTCC) -E $(dtc_cpp_flags) -x assembler-with-cpp -o $(dtc-tmp) $(pre-tmp) ; \ $(DTC) -O dtb -o $@ -b 0 \ - -i $(dir $<) $(DTC_FLAGS) \ + -i $(dir $<) -i $(UBOOT_DTSI_LOC) $(DTC_FLAGS) \ -d $(depfile).dtc.tmp $(dtc-tmp) || \ (echo "Check $(shell pwd)/$(pre-tmp) for errors" && false) \ ; \
Hi Sumit,
On Thu, 14 Dec 2023 at 06:52, Sumit Garg sumit.garg@linaro.org wrote:
Allow u-boot to build DTB from a different directory tree such that *-u-boot.dtsi files can be included from a common location. Currently that location is arch/$(ARCH)/dts/, so statically define that common location.
This is needed for platform owners to start building DTB files from devicetree-rebasing directory but still being able to include *-u-boot.dtsi files.
Signed-off-by: Sumit Garg sumit.garg@linaro.org
scripts/Makefile.lib | 25 ++++++++++++++----------- 1 file changed, 14 insertions(+), 11 deletions(-)
diff --git a/scripts/Makefile.lib b/scripts/Makefile.lib index 27b9437027c..4a002b0e0ca 100644 --- a/scripts/Makefile.lib +++ b/scripts/Makefile.lib @@ -159,18 +159,20 @@ cpp_flags = -Wp,-MD,$(depfile) $(NOSTDINC_FLAGS) $(UBOOTINCLUDE) \ ld_flags = $(KBUILD_LDFLAGS) $(ldflags-y) $(LDFLAGS_$(@F))
# Try these files in order to find the U-Boot-specific .dtsi include file -u_boot_dtsi_options = $(strip $(wildcard $(dir $<)$(basename $(notdir $<))-u-boot.dtsi) \
$(wildcard $(dir $<)$(subst $\",,$(CONFIG_SYS_SOC))-u-boot.dtsi) \$(wildcard $(dir $<)$(subst $\",,$(CONFIG_SYS_CPU))-u-boot.dtsi) \$(wildcard $(dir $<)$(subst $\",,$(CONFIG_SYS_VENDOR))-u-boot.dtsi) \$(wildcard $(dir $<)u-boot.dtsi))+UBOOT_DTSI_LOC = $(srctree)/arch/$(ARCH)/dts/
How about lower case since it is internal. Also we know it is U-Boot, so perhap dtsi_loc ?
Otherwise looks OK to me.
+u_boot_dtsi_options = $(strip $(wildcard $(UBOOT_DTSI_LOC)$(basename $(notdir $<))-u-boot.dtsi) \
$(wildcard $(UBOOT_DTSI_LOC)$(subst $\",,$(CONFIG_SYS_SOC))-u-boot.dtsi) \$(wildcard $(UBOOT_DTSI_LOC)$(subst $\",,$(CONFIG_SYS_CPU))-u-boot.dtsi) \$(wildcard $(UBOOT_DTSI_LOC)$(subst $\",,$(CONFIG_SYS_VENDOR))-u-boot.dtsi) \$(wildcard $(UBOOT_DTSI_LOC)u-boot.dtsi))u_boot_dtsi_options_raw = $(warning Automatic .dtsi inclusion: options: \
$(dir $<)$(basename $(notdir $<))-u-boot.dtsi \$(dir $<)$(subst $\",,$(CONFIG_SYS_SOC))-u-boot.dtsi \$(dir $<)$(subst $\",,$(CONFIG_SYS_CPU))-u-boot.dtsi \$(dir $<)$(subst $\",,$(CONFIG_SYS_VENDOR))-u-boot.dtsi \$(dir $<)u-boot.dtsi ... \
$(UBOOT_DTSI_LOC)$(basename $(notdir $<))-u-boot.dtsi \$(UBOOT_DTSI_LOC)$(subst $\",,$(CONFIG_SYS_SOC))-u-boot.dtsi \$(UBOOT_DTSI_LOC)$(subst $\",,$(CONFIG_SYS_CPU))-u-boot.dtsi \$(UBOOT_DTSI_LOC)$(subst $\",,$(CONFIG_SYS_VENDOR))-u-boot.dtsi \$(UBOOT_DTSI_LOC)u-boot.dtsi ... \ found: $(if $(u_boot_dtsi_options),"$(u_boot_dtsi_options)",nothing!))# Uncomment for debugging @@ -190,6 +192,7 @@ dtsi_include_list += $(CONFIG_DEVICE_TREE_INCLUDES) dtc_cpp_flags = -Wp,-MD,$(depfile).pre.tmp -nostdinc \ $(UBOOTINCLUDE) \ -I$(dir $<) \
-I$(UBOOT_DTSI_LOC) \ -I$(srctree)/arch/$(ARCH)/dts/include \ -I$(srctree)/include \ -D__ASSEMBLY__ \@@ -328,7 +331,7 @@ cmd_dtc = mkdir -p $(dir ${dtc-tmp}) ; \ echo '$(pound)include "$(f)"' >> $(pre-tmp);) \ $(HOSTCC) -E $(dtc_cpp_flags) -x assembler-with-cpp -o $(dtc-tmp) $(pre-tmp) ; \ $(DTC) -O dtb -o $@ -b 0 \
-i $(dir $<) $(DTC_FLAGS) \
-i $(dir $<) -i $(UBOOT_DTSI_LOC) $(DTC_FLAGS) \ -d $(depfile).dtc.tmp $(dtc-tmp) || \ (echo "Check $(shell pwd)/$(pre-tmp) for errors" && false) \ ; \-- 2.34.1
Regards, Simon
On Wed, 20 Dec 2023 at 10:17, Simon Glass sjg@chromium.org wrote:
Hi Sumit,
On Thu, 14 Dec 2023 at 06:52, Sumit Garg sumit.garg@linaro.org wrote:
Allow u-boot to build DTB from a different directory tree such that *-u-boot.dtsi files can be included from a common location. Currently that location is arch/$(ARCH)/dts/, so statically define that common location.
This is needed for platform owners to start building DTB files from devicetree-rebasing directory but still being able to include *-u-boot.dtsi files.
Signed-off-by: Sumit Garg sumit.garg@linaro.org
scripts/Makefile.lib | 25 ++++++++++++++----------- 1 file changed, 14 insertions(+), 11 deletions(-)
diff --git a/scripts/Makefile.lib b/scripts/Makefile.lib index 27b9437027c..4a002b0e0ca 100644 --- a/scripts/Makefile.lib +++ b/scripts/Makefile.lib @@ -159,18 +159,20 @@ cpp_flags = -Wp,-MD,$(depfile) $(NOSTDINC_FLAGS) $(UBOOTINCLUDE) \ ld_flags = $(KBUILD_LDFLAGS) $(ldflags-y) $(LDFLAGS_$(@F))
# Try these files in order to find the U-Boot-specific .dtsi include file -u_boot_dtsi_options = $(strip $(wildcard $(dir $<)$(basename $(notdir $<))-u-boot.dtsi) \
$(wildcard $(dir $<)$(subst $\",,$(CONFIG_SYS_SOC))-u-boot.dtsi) \$(wildcard $(dir $<)$(subst $\",,$(CONFIG_SYS_CPU))-u-boot.dtsi) \$(wildcard $(dir $<)$(subst $\",,$(CONFIG_SYS_VENDOR))-u-boot.dtsi) \$(wildcard $(dir $<)u-boot.dtsi))+UBOOT_DTSI_LOC = $(srctree)/arch/$(ARCH)/dts/
How about lower case since it is internal. Also we know it is U-Boot, so perhap ?
Although I just named it after *-u-boot.dtsi, I am fine with dtsi_loc too. So I will use that instead.
Otherwise looks OK to me.
Thanks, -Sumit
+u_boot_dtsi_options = $(strip $(wildcard $(UBOOT_DTSI_LOC)$(basename $(notdir $<))-u-boot.dtsi) \
$(wildcard $(UBOOT_DTSI_LOC)$(subst $\",,$(CONFIG_SYS_SOC))-u-boot.dtsi) \$(wildcard $(UBOOT_DTSI_LOC)$(subst $\",,$(CONFIG_SYS_CPU))-u-boot.dtsi) \$(wildcard $(UBOOT_DTSI_LOC)$(subst $\",,$(CONFIG_SYS_VENDOR))-u-boot.dtsi) \$(wildcard $(UBOOT_DTSI_LOC)u-boot.dtsi))u_boot_dtsi_options_raw = $(warning Automatic .dtsi inclusion: options: \
$(dir $<)$(basename $(notdir $<))-u-boot.dtsi \$(dir $<)$(subst $\",,$(CONFIG_SYS_SOC))-u-boot.dtsi \$(dir $<)$(subst $\",,$(CONFIG_SYS_CPU))-u-boot.dtsi \$(dir $<)$(subst $\",,$(CONFIG_SYS_VENDOR))-u-boot.dtsi \$(dir $<)u-boot.dtsi ... \
$(UBOOT_DTSI_LOC)$(basename $(notdir $<))-u-boot.dtsi \$(UBOOT_DTSI_LOC)$(subst $\",,$(CONFIG_SYS_SOC))-u-boot.dtsi \$(UBOOT_DTSI_LOC)$(subst $\",,$(CONFIG_SYS_CPU))-u-boot.dtsi \$(UBOOT_DTSI_LOC)$(subst $\",,$(CONFIG_SYS_VENDOR))-u-boot.dtsi \$(UBOOT_DTSI_LOC)u-boot.dtsi ... \ found: $(if $(u_boot_dtsi_options),"$(u_boot_dtsi_options)",nothing!))# Uncomment for debugging @@ -190,6 +192,7 @@ dtsi_include_list += $(CONFIG_DEVICE_TREE_INCLUDES) dtc_cpp_flags = -Wp,-MD,$(depfile).pre.tmp -nostdinc \ $(UBOOTINCLUDE) \ -I$(dir $<) \
-I$(UBOOT_DTSI_LOC) \ -I$(srctree)/arch/$(ARCH)/dts/include \ -I$(srctree)/include \ -D__ASSEMBLY__ \@@ -328,7 +331,7 @@ cmd_dtc = mkdir -p $(dir ${dtc-tmp}) ; \ echo '$(pound)include "$(f)"' >> $(pre-tmp);) \ $(HOSTCC) -E $(dtc_cpp_flags) -x assembler-with-cpp -o $(dtc-tmp) $(pre-tmp) ; \ $(DTC) -O dtb -o $@ -b 0 \
-i $(dir $<) $(DTC_FLAGS) \
-i $(dir $<) -i $(UBOOT_DTSI_LOC) $(DTC_FLAGS) \ -d $(depfile).dtc.tmp $(dtc-tmp) || \ (echo "Check $(shell pwd)/$(pre-tmp) for errors" && false) \ ; \-- 2.34.1
Regards, Simon
On Wed, Dec 20, 2023 at 05:00:20PM +0530, Sumit Garg wrote:
On Wed, 20 Dec 2023 at 10:17, Simon Glass sjg@chromium.org wrote:
Hi Sumit,
On Thu, 14 Dec 2023 at 06:52, Sumit Garg sumit.garg@linaro.org wrote:
Allow u-boot to build DTB from a different directory tree such that *-u-boot.dtsi files can be included from a common location. Currently that location is arch/$(ARCH)/dts/, so statically define that common location.
This is needed for platform owners to start building DTB files from devicetree-rebasing directory but still being able to include *-u-boot.dtsi files.
Signed-off-by: Sumit Garg sumit.garg@linaro.org
scripts/Makefile.lib | 25 ++++++++++++++----------- 1 file changed, 14 insertions(+), 11 deletions(-)
diff --git a/scripts/Makefile.lib b/scripts/Makefile.lib index 27b9437027c..4a002b0e0ca 100644 --- a/scripts/Makefile.lib +++ b/scripts/Makefile.lib @@ -159,18 +159,20 @@ cpp_flags = -Wp,-MD,$(depfile) $(NOSTDINC_FLAGS) $(UBOOTINCLUDE) \ ld_flags = $(KBUILD_LDFLAGS) $(ldflags-y) $(LDFLAGS_$(@F))
# Try these files in order to find the U-Boot-specific .dtsi include file -u_boot_dtsi_options = $(strip $(wildcard $(dir $<)$(basename $(notdir $<))-u-boot.dtsi) \
$(wildcard $(dir $<)$(subst $\",,$(CONFIG_SYS_SOC))-u-boot.dtsi) \$(wildcard $(dir $<)$(subst $\",,$(CONFIG_SYS_CPU))-u-boot.dtsi) \$(wildcard $(dir $<)$(subst $\",,$(CONFIG_SYS_VENDOR))-u-boot.dtsi) \$(wildcard $(dir $<)u-boot.dtsi))+UBOOT_DTSI_LOC = $(srctree)/arch/$(ARCH)/dts/
How about lower case since it is internal. Also we know it is U-Boot, so perhap ?
Although I just named it after *-u-boot.dtsi, I am fine with dtsi_loc too. So I will use that instead.
I was going to say lets use "uboot_dtsi_loc" so it's both clear what the variable does and for future re-syncs.
On Wed, 20 Dec 2023 at 18:59, Tom Rini trini@konsulko.com wrote:
On Wed, Dec 20, 2023 at 05:00:20PM +0530, Sumit Garg wrote:
On Wed, 20 Dec 2023 at 10:17, Simon Glass sjg@chromium.org wrote:
Hi Sumit,
On Thu, 14 Dec 2023 at 06:52, Sumit Garg sumit.garg@linaro.org wrote:
Allow u-boot to build DTB from a different directory tree such that *-u-boot.dtsi files can be included from a common location. Currently that location is arch/$(ARCH)/dts/, so statically define that common location.
This is needed for platform owners to start building DTB files from devicetree-rebasing directory but still being able to include *-u-boot.dtsi files.
Signed-off-by: Sumit Garg sumit.garg@linaro.org
scripts/Makefile.lib | 25 ++++++++++++++----------- 1 file changed, 14 insertions(+), 11 deletions(-)
diff --git a/scripts/Makefile.lib b/scripts/Makefile.lib index 27b9437027c..4a002b0e0ca 100644 --- a/scripts/Makefile.lib +++ b/scripts/Makefile.lib @@ -159,18 +159,20 @@ cpp_flags = -Wp,-MD,$(depfile) $(NOSTDINC_FLAGS) $(UBOOTINCLUDE) \ ld_flags = $(KBUILD_LDFLAGS) $(ldflags-y) $(LDFLAGS_$(@F))
# Try these files in order to find the U-Boot-specific .dtsi include file -u_boot_dtsi_options = $(strip $(wildcard $(dir $<)$(basename $(notdir $<))-u-boot.dtsi) \
$(wildcard $(dir $<)$(subst $\",,$(CONFIG_SYS_SOC))-u-boot.dtsi) \$(wildcard $(dir $<)$(subst $\",,$(CONFIG_SYS_CPU))-u-boot.dtsi) \$(wildcard $(dir $<)$(subst $\",,$(CONFIG_SYS_VENDOR))-u-boot.dtsi) \$(wildcard $(dir $<)u-boot.dtsi))+UBOOT_DTSI_LOC = $(srctree)/arch/$(ARCH)/dts/
How about lower case since it is internal. Also we know it is U-Boot, so perhap ?
Although I just named it after *-u-boot.dtsi, I am fine with dtsi_loc too. So I will use that instead.
I was going to say lets use "uboot_dtsi_loc" so it's both clear what the variable does and for future re-syncs.
Okay that makes further sense. I will use it if I don't see any objection from Simon.
-Sumit
-- Tom
Allow platform owners to mirror devicetree files from devitree-rebasing directory into dts/arch/$(ARCH) (special case for dts/arch/arm64). Then build then along with any *-u-boot.dtsi file present in arch/$(ARCH)/dts directory.
This will help easy migration for platforms which currently are compliant with upstream Linux kernel devicetree files.
Signed-off-by: Sumit Garg sumit.garg@linaro.org --- dts/Kconfig | 11 +++++++++++ dts/Makefile | 17 ++++++++++++++--- dts/arch/arm64/Makefile | 14 ++++++++++++++ 3 files changed, 39 insertions(+), 3 deletions(-) create mode 100644 dts/arch/arm64/Makefile
diff --git a/dts/Kconfig b/dts/Kconfig index 00c0aeff893..96396f12b67 100644 --- a/dts/Kconfig +++ b/dts/Kconfig @@ -85,6 +85,17 @@ config OF_LIVE enables a live tree which is available after relocation, and can be adjusted as needed.
+config OF_UPSTREAM + bool "Enable use of devicetree imported from Linux kernel release" + help + Traditionally, U-boot platforms used to have their custom devicetree + files or copy devicetree files from Linux kernel which are hard to + maintain and can usually get out-of-sync from Linux kernel. This + option enables platforms to migrate to devicetree-rebasing repo where + a regular sync will be maintained every major Linux kernel release + cycle. However, platforms can still have some custom u-boot specific + bits maintained as part of *-u-boot.dtsi files. + choice prompt "Provider of DTB for DT control" depends on OF_CONTROL diff --git a/dts/Makefile b/dts/Makefile index 3437e54033d..8098bf8191a 100644 --- a/dts/Makefile +++ b/dts/Makefile @@ -10,10 +10,20 @@ ifeq ($(DEVICE_TREE),) DEVICE_TREE := unset endif
+ifeq ($(CONFIG_OF_UPSTREAM),y) +ifeq ($(CONFIG_ARM64),y) +DEVICE_TREE_LOC := dts/arch/arm64 +else +DEVICE_TREE_LOC := dts/arch/$(ARCH) +endif +else +DEVICE_TREE_LOC := arch/$(ARCH)/dts +endif + ifneq ($(EXT_DTB),) DTB := $(EXT_DTB) else -DTB := arch/$(ARCH)/dts/$(DEVICE_TREE).dtb +DTB := $(DEVICE_TREE_LOC)/$(DEVICE_TREE).dtb endif
$(obj)/dt-$(SPL_NAME).dtb: dts/dt.dtb $(objtree)/tools/fdtgrep FORCE @@ -41,7 +51,7 @@ $(DTB): arch-dtbs
PHONY += arch-dtbs arch-dtbs: - $(Q)$(MAKE) $(build)=arch/$(ARCH)/dts dtbs + $(Q)$(MAKE) $(build)=$(DEVICE_TREE_LOC) dtbs
ifeq ($(CONFIG_SPL_BUILD),y) obj-$(CONFIG_OF_EMBED) := dt-spl.dtb.o @@ -65,4 +75,5 @@ clean-files := dt.dtb.S # Let clean descend into dts directories subdir- += ../arch/arc/dts ../arch/arm/dts ../arch/m68k/dts ../arch/microblaze/dts \ ../arch/mips/dts ../arch/nios2/dts ../arch/powerpc/dts ../arch/riscv/dts \ - ../arch/sandbox/dts ../arch/sh/dts ../arch/x86/dts ../arch/xtensa/dts + ../arch/sandbox/dts ../arch/sh/dts ../arch/x86/dts ../arch/xtensa/dts \ + ./arch/arm64 ./arch/$(ARCH) diff --git a/dts/arch/arm64/Makefile b/dts/arch/arm64/Makefile new file mode 100644 index 00000000000..16e9fea622d --- /dev/null +++ b/dts/arch/arm64/Makefile @@ -0,0 +1,14 @@ +# SPDX-License-Identifier: GPL-2.0+ + +include $(srctree)/scripts/Makefile.dts + +targets += $(dtb-y) + +# Add any required device tree compiler flags here +DTC_FLAGS += -a 0x8 + +PHONY += dtbs +dtbs: $(addprefix $(obj)/, $(dtb-y)) + @: + +clean-files := */*.dtb */*.dtbo */*_HS
Hi Sumit,
On Thu, 14 Dec 2023 at 06:52, Sumit Garg sumit.garg@linaro.org wrote:
Allow platform owners to mirror devicetree files from devitree-rebasing directory into dts/arch/$(ARCH) (special case for dts/arch/arm64). Then build then along with any *-u-boot.dtsi file present in arch/$(ARCH)/dts directory.
Also add a new Makefile for arm64.
This will help easy migration for platforms which currently are compliant with upstream Linux kernel devicetree files.
Signed-off-by: Sumit Garg sumit.garg@linaro.org
dts/Kconfig | 11 +++++++++++ dts/Makefile | 17 ++++++++++++++--- dts/arch/arm64/Makefile | 14 ++++++++++++++ 3 files changed, 39 insertions(+), 3 deletions(-) create mode 100644 dts/arch/arm64/Makefile
diff --git a/dts/Kconfig b/dts/Kconfig index 00c0aeff893..96396f12b67 100644 --- a/dts/Kconfig +++ b/dts/Kconfig @@ -85,6 +85,17 @@ config OF_LIVE enables a live tree which is available after relocation, and can be adjusted as needed.
+config OF_UPSTREAM
bool "Enable use of devicetree imported from Linux kernel release"helpTraditionally, U-boot platforms used to have their custom devicetree
U-Boot
(I think I mentioned this, but you thought I said U-boot...but it really is U-Boot). Perhaps grep your patches next time.
files or copy devicetree files from Linux kernel which are hard tomaintain and can usually get out-of-sync from Linux kernel. Thisoption enables platforms to migrate to devicetree-rebasing repo wherea regular sync will be maintained every major Linux kernel releasecycle. However, platforms can still have some custom u-boot specificbits maintained as part of *-u-boot.dtsi files.
I'm a bit nervous about this. It means that boards chose between this dir of the local files. It means there is some effort to switch.
I wonder if we could default to using the rebasing thing, with boards having to 'opt out'? So this should be 'default y' ?
choice prompt "Provider of DTB for DT control" depends on OF_CONTROL diff --git a/dts/Makefile b/dts/Makefile index 3437e54033d..8098bf8191a 100644 --- a/dts/Makefile +++ b/dts/Makefile @@ -10,10 +10,20 @@ ifeq ($(DEVICE_TREE),) DEVICE_TREE := unset endif
+ifeq ($(CONFIG_OF_UPSTREAM),y) +ifeq ($(CONFIG_ARM64),y) +DEVICE_TREE_LOC := dts/arch/arm64
dt_dir ?
Should we move the arm64 DTs to arch/arm64 ?
What about the subdirs used in Linux?
+else +DEVICE_TREE_LOC := dts/arch/$(ARCH) +endif +else +DEVICE_TREE_LOC := arch/$(ARCH)/dts +endif
ifneq ($(EXT_DTB),) DTB := $(EXT_DTB)
else -DTB := arch/$(ARCH)/dts/$(DEVICE_TREE).dtb +DTB := $(DEVICE_TREE_LOC)/$(DEVICE_TREE).dtb endif
$(obj)/dt-$(SPL_NAME).dtb: dts/dt.dtb $(objtree)/tools/fdtgrep FORCE @@ -41,7 +51,7 @@ $(DTB): arch-dtbs
PHONY += arch-dtbs arch-dtbs:
$(Q)$(MAKE) $(build)=arch/$(ARCH)/dts dtbs
$(Q)$(MAKE) $(build)=$(DEVICE_TREE_LOC) dtbsifeq ($(CONFIG_SPL_BUILD),y) obj-$(CONFIG_OF_EMBED) := dt-spl.dtb.o @@ -65,4 +75,5 @@ clean-files := dt.dtb.S # Let clean descend into dts directories subdir- += ../arch/arc/dts ../arch/arm/dts ../arch/m68k/dts ../arch/microblaze/dts \ ../arch/mips/dts ../arch/nios2/dts ../arch/powerpc/dts ../arch/riscv/dts \
../arch/sandbox/dts ../arch/sh/dts ../arch/x86/dts ../arch/xtensa/dts
../arch/sandbox/dts ../arch/sh/dts ../arch/x86/dts ../arch/xtensa/dts \./arch/arm64 ./arch/$(ARCH)diff --git a/dts/arch/arm64/Makefile b/dts/arch/arm64/Makefile new file mode 100644 index 00000000000..16e9fea622d --- /dev/null +++ b/dts/arch/arm64/Makefile @@ -0,0 +1,14 @@ +# SPDX-License-Identifier: GPL-2.0+
+include $(srctree)/scripts/Makefile.dts
+targets += $(dtb-y)
+# Add any required device tree compiler flags here +DTC_FLAGS += -a 0x8
+PHONY += dtbs +dtbs: $(addprefix $(obj)/, $(dtb-y))
@:+clean-files := */*.dtb */*.dtbo */*_HS
2.34.1
Regards, Simon
Hi Simon,
On Wed, 20 Dec 2023 at 10:17, Simon Glass sjg@chromium.org wrote:
Hi Sumit,
On Thu, 14 Dec 2023 at 06:52, Sumit Garg sumit.garg@linaro.org wrote:
Allow platform owners to mirror devicetree files from devitree-rebasing directory into dts/arch/$(ARCH) (special case for dts/arch/arm64). Then build then along with any *-u-boot.dtsi file present in arch/$(ARCH)/dts directory.
Also add a new Makefile for arm64.
I suppose you are referring to dts/arch/arm64/Makefile which has been added by this patch.
This will help easy migration for platforms which currently are compliant with upstream Linux kernel devicetree files.
Signed-off-by: Sumit Garg sumit.garg@linaro.org
dts/Kconfig | 11 +++++++++++ dts/Makefile | 17 ++++++++++++++--- dts/arch/arm64/Makefile | 14 ++++++++++++++ 3 files changed, 39 insertions(+), 3 deletions(-) create mode 100644 dts/arch/arm64/Makefile
diff --git a/dts/Kconfig b/dts/Kconfig index 00c0aeff893..96396f12b67 100644 --- a/dts/Kconfig +++ b/dts/Kconfig @@ -85,6 +85,17 @@ config OF_LIVE enables a live tree which is available after relocation, and can be adjusted as needed.
+config OF_UPSTREAM
bool "Enable use of devicetree imported from Linux kernel release"helpTraditionally, U-boot platforms used to have their custom devicetreeU-Boot
(I think I mentioned this, but you thought I said U-boot...but it really is U-Boot). Perhaps grep your patches next time.
Ah, I see. It looks like I missed that bit, and will take care of it in the next revision.
files or copy devicetree files from Linux kernel which are hard tomaintain and can usually get out-of-sync from Linux kernel. Thisoption enables platforms to migrate to devicetree-rebasing repo wherea regular sync will be maintained every major Linux kernel releasecycle. However, platforms can still have some custom u-boot specificbits maintained as part of *-u-boot.dtsi files.I'm a bit nervous about this. It means that boards chose between this dir of the local files. It means there is some effort to switch.
I wonder if we could default to using the rebasing thing, with boards having to 'opt out'? So this should be 'default y' ?
Ideally that should be our migration path going forward once we get enough boards migrated to use rebasing repo. But at this initial stage we have to put some effort on migrating boards to use rebasing subtree, although effort should be just adding (given DT bindings compliance) following to defconfig (see patch #7):
CONFIG_OF_UPSTREAM=y CONFIG_DEFAULT_DEVICE_TREE="amlogic/meson-gxbb-nanopi-k2"
and create a mirrored copy of: ../../../devicetree-rebasing/src/arm64/amlogic/ into dts/arch/arm64/amlogic/ with modifications to add targets to dts/arch/arm64/Makefile.
I am happy to put in that effort but certainly for new board support that would like to import DT from Linux it should be the default. That stands true for the Qcom platform series for which Caleb is currently working on.
choice prompt "Provider of DTB for DT control" depends on OF_CONTROL diff --git a/dts/Makefile b/dts/Makefile index 3437e54033d..8098bf8191a 100644 --- a/dts/Makefile +++ b/dts/Makefile @@ -10,10 +10,20 @@ ifeq ($(DEVICE_TREE),) DEVICE_TREE := unset endif
+ifeq ($(CONFIG_OF_UPSTREAM),y) +ifeq ($(CONFIG_ARM64),y) +DEVICE_TREE_LOC := dts/arch/arm64
dt_dir ?
Okay I will rename it.
Should we move the arm64 DTs to arch/arm64 ?
IMO, the migration path should be to use rebasing subtree via dts/arch/arm64/ and dropping DTs except *-u-boot.dtsi from arch/$(ARCH)/dts. So moving DTs from arch/arm/ to arch/arm64/ seems like a redundant change to me.
What about the subdirs used in Linux?
I hope I have described above regarding how subdirs are mirrored. However, have a look at patch #7 for the amlogic/ subdir example.
-Sumit
+else +DEVICE_TREE_LOC := dts/arch/$(ARCH) +endif +else +DEVICE_TREE_LOC := arch/$(ARCH)/dts +endif
ifneq ($(EXT_DTB),) DTB := $(EXT_DTB)
else -DTB := arch/$(ARCH)/dts/$(DEVICE_TREE).dtb +DTB := $(DEVICE_TREE_LOC)/$(DEVICE_TREE).dtb endif
$(obj)/dt-$(SPL_NAME).dtb: dts/dt.dtb $(objtree)/tools/fdtgrep FORCE @@ -41,7 +51,7 @@ $(DTB): arch-dtbs
PHONY += arch-dtbs arch-dtbs:
$(Q)$(MAKE) $(build)=arch/$(ARCH)/dts dtbs
$(Q)$(MAKE) $(build)=$(DEVICE_TREE_LOC) dtbsifeq ($(CONFIG_SPL_BUILD),y) obj-$(CONFIG_OF_EMBED) := dt-spl.dtb.o @@ -65,4 +75,5 @@ clean-files := dt.dtb.S # Let clean descend into dts directories subdir- += ../arch/arc/dts ../arch/arm/dts ../arch/m68k/dts ../arch/microblaze/dts \ ../arch/mips/dts ../arch/nios2/dts ../arch/powerpc/dts ../arch/riscv/dts \
../arch/sandbox/dts ../arch/sh/dts ../arch/x86/dts ../arch/xtensa/dts
../arch/sandbox/dts ../arch/sh/dts ../arch/x86/dts ../arch/xtensa/dts \./arch/arm64 ./arch/$(ARCH)diff --git a/dts/arch/arm64/Makefile b/dts/arch/arm64/Makefile new file mode 100644 index 00000000000..16e9fea622d --- /dev/null +++ b/dts/arch/arm64/Makefile @@ -0,0 +1,14 @@ +# SPDX-License-Identifier: GPL-2.0+
+include $(srctree)/scripts/Makefile.dts
+targets += $(dtb-y)
+# Add any required device tree compiler flags here +DTC_FLAGS += -a 0x8
+PHONY += dtbs +dtbs: $(addprefix $(obj)/, $(dtb-y))
@:+clean-files := */*.dtb */*.dtbo */*_HS
2.34.1
Regards, Simon
Hi Sumit,
On Wed, Dec 20, 2023 at 12:01 PM Sumit Garg sumit.garg@linaro.org wrote:
Hi Simon,
On Wed, 20 Dec 2023 at 10:17, Simon Glass sjg@chromium.org wrote:
Hi Sumit,
On Thu, 14 Dec 2023 at 06:52, Sumit Garg sumit.garg@linaro.org wrote:
Allow platform owners to mirror devicetree files from devitree-rebasing directory into dts/arch/$(ARCH) (special case for dts/arch/arm64). Then build then along with any *-u-boot.dtsi file present in arch/$(ARCH)/dts directory.
Also add a new Makefile for arm64.
I suppose you are referring to dts/arch/arm64/Makefile which has been added by this patch.
Yes, I just mean that you should mention this in the commit message
This will help easy migration for platforms which currently are compliant with upstream Linux kernel devicetree files.
Signed-off-by: Sumit Garg sumit.garg@linaro.org
dts/Kconfig | 11 +++++++++++ dts/Makefile | 17 ++++++++++++++--- dts/arch/arm64/Makefile | 14 ++++++++++++++ 3 files changed, 39 insertions(+), 3 deletions(-) create mode 100644 dts/arch/arm64/Makefile
diff --git a/dts/Kconfig b/dts/Kconfig index 00c0aeff893..96396f12b67 100644 --- a/dts/Kconfig +++ b/dts/Kconfig @@ -85,6 +85,17 @@ config OF_LIVE enables a live tree which is available after relocation, and can be adjusted as needed.
+config OF_UPSTREAM
bool "Enable use of devicetree imported from Linux kernel release"helpTraditionally, U-boot platforms used to have their custom devicetreeU-Boot
(I think I mentioned this, but you thought I said U-boot...but it really is U-Boot). Perhaps grep your patches next time.
Ah, I see. It looks like I missed that bit, and will take care of it in the next revision.
files or copy devicetree files from Linux kernel which are hard tomaintain and can usually get out-of-sync from Linux kernel. Thisoption enables platforms to migrate to devicetree-rebasing repo wherea regular sync will be maintained every major Linux kernel releasecycle. However, platforms can still have some custom u-boot specificbits maintained as part of *-u-boot.dtsi files.I'm a bit nervous about this. It means that boards chose between this dir of the local files. It means there is some effort to switch.
I wonder if we could default to using the rebasing thing, with boards having to 'opt out'? So this should be 'default y' ?
Ideally that should be our migration path going forward once we get enough boards migrated to use rebasing repo. But at this initial stage we have to put some effort on migrating boards to use rebasing subtree, although effort should be just adding (given DT bindings compliance) following to defconfig (see patch #7):
CONFIG_OF_UPSTREAM=y CONFIG_DEFAULT_DEVICE_TREE="amlogic/meson-gxbb-nanopi-k2"
and create a mirrored copy of: ../../../devicetree-rebasing/src/arm64/amlogic/ into dts/arch/arm64/amlogic/ with modifications to add targets to dts/arch/arm64/Makefile.
I am happy to put in that effort but certainly for new board support that would like to import DT from Linux it should be the default. That stands true for the Qcom platform series for which Caleb is currently working on.
The problem I see is that this is board-by-board, so will never happen. Changing one board (e.g. rockpro64-rk3399) typically involves changing the .dtsi files it includes (e.g. rk3399.dtsi) so it is hard/impossible to do one board without doing all.
So this is why I believe the setting should be on an SoC basis, not on a board basis.
choice prompt "Provider of DTB for DT control" depends on OF_CONTROL diff --git a/dts/Makefile b/dts/Makefile index 3437e54033d..8098bf8191a 100644 --- a/dts/Makefile +++ b/dts/Makefile @@ -10,10 +10,20 @@ ifeq ($(DEVICE_TREE),) DEVICE_TREE := unset endif
+ifeq ($(CONFIG_OF_UPSTREAM),y) +ifeq ($(CONFIG_ARM64),y) +DEVICE_TREE_LOC := dts/arch/arm64
dt_dir ?
Okay I will rename it.
Should we move the arm64 DTs to arch/arm64 ?
IMO, the migration path should be to use rebasing subtree via dts/arch/arm64/ and dropping DTs except *-u-boot.dtsi from arch/$(ARCH)/dts. So moving DTs from arch/arm/ to arch/arm64/ seems like a redundant change to me.
I can see that argument, but having two different directory structures would be confusing.
What about the subdirs used in Linux?
I hope I have described above regarding how subdirs are mirrored. However, have a look at patch #7 for the amlogic/ subdir example.
OK
Regards, Simon
On Tue, 26 Dec 2023 at 15:17, Simon Glass sjg@chromium.org wrote:
Hi Sumit,
On Wed, Dec 20, 2023 at 12:01 PM Sumit Garg sumit.garg@linaro.org wrote:
Hi Simon,
On Wed, 20 Dec 2023 at 10:17, Simon Glass sjg@chromium.org wrote:
Hi Sumit,
On Thu, 14 Dec 2023 at 06:52, Sumit Garg sumit.garg@linaro.org wrote:
Allow platform owners to mirror devicetree files from devitree-rebasing directory into dts/arch/$(ARCH) (special case for dts/arch/arm64). Then build then along with any *-u-boot.dtsi file present in arch/$(ARCH)/dts directory.
Also add a new Makefile for arm64.
I suppose you are referring to dts/arch/arm64/Makefile which has been added by this patch.
Yes, I just mean that you should mention this in the commit message
Okay, I will append the commit message.
This will help easy migration for platforms which currently are compliant with upstream Linux kernel devicetree files.
Signed-off-by: Sumit Garg sumit.garg@linaro.org
dts/Kconfig | 11 +++++++++++ dts/Makefile | 17 ++++++++++++++--- dts/arch/arm64/Makefile | 14 ++++++++++++++ 3 files changed, 39 insertions(+), 3 deletions(-) create mode 100644 dts/arch/arm64/Makefile
diff --git a/dts/Kconfig b/dts/Kconfig index 00c0aeff893..96396f12b67 100644 --- a/dts/Kconfig +++ b/dts/Kconfig @@ -85,6 +85,17 @@ config OF_LIVE enables a live tree which is available after relocation, and can be adjusted as needed.
+config OF_UPSTREAM
bool "Enable use of devicetree imported from Linux kernel release"helpTraditionally, U-boot platforms used to have their custom devicetreeU-Boot
(I think I mentioned this, but you thought I said U-boot...but it really is U-Boot). Perhaps grep your patches next time.
Ah, I see. It looks like I missed that bit, and will take care of it in the next revision.
files or copy devicetree files from Linux kernel which are hard tomaintain and can usually get out-of-sync from Linux kernel. Thisoption enables platforms to migrate to devicetree-rebasing repo wherea regular sync will be maintained every major Linux kernel releasecycle. However, platforms can still have some custom u-boot specificbits maintained as part of *-u-boot.dtsi files.I'm a bit nervous about this. It means that boards chose between this dir of the local files. It means there is some effort to switch.
I wonder if we could default to using the rebasing thing, with boards having to 'opt out'? So this should be 'default y' ?
Ideally that should be our migration path going forward once we get enough boards migrated to use rebasing repo. But at this initial stage we have to put some effort on migrating boards to use rebasing subtree, although effort should be just adding (given DT bindings compliance) following to defconfig (see patch #7):
CONFIG_OF_UPSTREAM=y CONFIG_DEFAULT_DEVICE_TREE="amlogic/meson-gxbb-nanopi-k2"
and create a mirrored copy of: ../../../devicetree-rebasing/src/arm64/amlogic/ into dts/arch/arm64/amlogic/ with modifications to add targets to dts/arch/arm64/Makefile.
I am happy to put in that effort but certainly for new board support that would like to import DT from Linux it should be the default. That stands true for the Qcom platform series for which Caleb is currently working on.
The problem I see is that this is board-by-board, so will never happen. Changing one board (e.g. rockpro64-rk3399) typically involves changing the .dtsi files it includes (e.g. rk3399.dtsi) so it is hard/impossible to do one board without doing all.
So this is why I believe the setting should be on an SoC basis, not on a board basis.
Sure, I will enable OF_UPSTREAM on a per SoC basis.
choice prompt "Provider of DTB for DT control" depends on OF_CONTROL diff --git a/dts/Makefile b/dts/Makefile index 3437e54033d..8098bf8191a 100644 --- a/dts/Makefile +++ b/dts/Makefile @@ -10,10 +10,20 @@ ifeq ($(DEVICE_TREE),) DEVICE_TREE := unset endif
+ifeq ($(CONFIG_OF_UPSTREAM),y) +ifeq ($(CONFIG_ARM64),y) +DEVICE_TREE_LOC := dts/arch/arm64
dt_dir ?
Okay I will rename it.
Should we move the arm64 DTs to arch/arm64 ?
IMO, the migration path should be to use rebasing subtree via dts/arch/arm64/ and dropping DTs except *-u-boot.dtsi from arch/$(ARCH)/dts. So moving DTs from arch/arm/ to arch/arm64/ seems like a redundant change to me.
I can see that argument, but having two different directory structures would be confusing.
I can see your point but U-Boot arch arm64 code is also contained in arch/arm/. However, I would suggest first migrating to DT rebasing and then we can do a move for the leftovers (*-u-boot.dtsi and such). A double move won't add much value.
-Sumit
What about the subdirs used in Linux?
I hope I have described above regarding how subdirs are mirrored. However, have a look at patch #7 for the amlogic/ subdir example.
OK
Regards, Simon
Hi Sumit,
On Tue, Dec 26, 2023 at 10:20 AM Sumit Garg sumit.garg@linaro.org wrote:
On Tue, 26 Dec 2023 at 15:17, Simon Glass sjg@chromium.org wrote:
Hi Sumit,
On Wed, Dec 20, 2023 at 12:01 PM Sumit Garg sumit.garg@linaro.org wrote:
Hi Simon,
On Wed, 20 Dec 2023 at 10:17, Simon Glass sjg@chromium.org wrote:
Hi Sumit,
On Thu, 14 Dec 2023 at 06:52, Sumit Garg sumit.garg@linaro.org wrote:
Allow platform owners to mirror devicetree files from devitree-rebasing directory into dts/arch/$(ARCH) (special case for dts/arch/arm64). Then build then along with any *-u-boot.dtsi file present in arch/$(ARCH)/dts directory.
Also add a new Makefile for arm64.
I suppose you are referring to dts/arch/arm64/Makefile which has been added by this patch.
Yes, I just mean that you should mention this in the commit message
Okay, I will append the commit message.
This will help easy migration for platforms which currently are compliant with upstream Linux kernel devicetree files.
Signed-off-by: Sumit Garg sumit.garg@linaro.org
dts/Kconfig | 11 +++++++++++ dts/Makefile | 17 ++++++++++++++--- dts/arch/arm64/Makefile | 14 ++++++++++++++ 3 files changed, 39 insertions(+), 3 deletions(-) create mode 100644 dts/arch/arm64/Makefile
diff --git a/dts/Kconfig b/dts/Kconfig index 00c0aeff893..96396f12b67 100644 --- a/dts/Kconfig +++ b/dts/Kconfig @@ -85,6 +85,17 @@ config OF_LIVE enables a live tree which is available after relocation, and can be adjusted as needed.
+config OF_UPSTREAM
bool "Enable use of devicetree imported from Linux kernel release"helpTraditionally, U-boot platforms used to have their custom devicetreeU-Boot
(I think I mentioned this, but you thought I said U-boot...but it really is U-Boot). Perhaps grep your patches next time.
Ah, I see. It looks like I missed that bit, and will take care of it in the next revision.
files or copy devicetree files from Linux kernel which are hard tomaintain and can usually get out-of-sync from Linux kernel. Thisoption enables platforms to migrate to devicetree-rebasing repo wherea regular sync will be maintained every major Linux kernel releasecycle. However, platforms can still have some custom u-boot specificbits maintained as part of *-u-boot.dtsi files.I'm a bit nervous about this. It means that boards chose between this dir of the local files. It means there is some effort to switch.
I wonder if we could default to using the rebasing thing, with boards having to 'opt out'? So this should be 'default y' ?
Ideally that should be our migration path going forward once we get enough boards migrated to use rebasing repo. But at this initial stage we have to put some effort on migrating boards to use rebasing subtree, although effort should be just adding (given DT bindings compliance) following to defconfig (see patch #7):
CONFIG_OF_UPSTREAM=y CONFIG_DEFAULT_DEVICE_TREE="amlogic/meson-gxbb-nanopi-k2"
and create a mirrored copy of: ../../../devicetree-rebasing/src/arm64/amlogic/ into dts/arch/arm64/amlogic/ with modifications to add targets to dts/arch/arm64/Makefile.
I am happy to put in that effort but certainly for new board support that would like to import DT from Linux it should be the default. That stands true for the Qcom platform series for which Caleb is currently working on.
The problem I see is that this is board-by-board, so will never happen. Changing one board (e.g. rockpro64-rk3399) typically involves changing the .dtsi files it includes (e.g. rk3399.dtsi) so it is hard/impossible to do one board without doing all.
So this is why I believe the setting should be on an SoC basis, not on a board basis.
Sure, I will enable OF_UPSTREAM on a per SoC basis.
choice prompt "Provider of DTB for DT control" depends on OF_CONTROL diff --git a/dts/Makefile b/dts/Makefile index 3437e54033d..8098bf8191a 100644 --- a/dts/Makefile +++ b/dts/Makefile @@ -10,10 +10,20 @@ ifeq ($(DEVICE_TREE),) DEVICE_TREE := unset endif
+ifeq ($(CONFIG_OF_UPSTREAM),y) +ifeq ($(CONFIG_ARM64),y) +DEVICE_TREE_LOC := dts/arch/arm64
dt_dir ?
Okay I will rename it.
Should we move the arm64 DTs to arch/arm64 ?
IMO, the migration path should be to use rebasing subtree via dts/arch/arm64/ and dropping DTs except *-u-boot.dtsi from arch/$(ARCH)/dts. So moving DTs from arch/arm/ to arch/arm64/ seems like a redundant change to me.
I can see that argument, but having two different directory structures would be confusing.
I can see your point but U-Boot arch arm64 code is also contained in arch/arm/. However, I would suggest first migrating to DT rebasing and then we can do a move for the leftovers (*-u-boot.dtsi and such). A double move won't add much value.
OK, so long as you are planning to do that next?
Regards, Simon
Encourage SoC/board maintainers to migrate to using devicetree-rebasing subtree and maintain a regular sync with Linux kernel devicetree files and bindings.
Along with that add documentation regarding how to run DT bindings schema checks.
Signed-off-by: Sumit Garg sumit.garg@linaro.org --- doc/develop/devicetree/control.rst | 108 +++++++++++++++++++++++------ 1 file changed, 86 insertions(+), 22 deletions(-)
diff --git a/doc/develop/devicetree/control.rst b/doc/develop/devicetree/control.rst index cbb65c9b177..12ef55ed368 100644 --- a/doc/develop/devicetree/control.rst +++ b/doc/develop/devicetree/control.rst @@ -1,5 +1,6 @@ .. SPDX-License-Identifier: GPL-2.0+ .. sectionauthor:: Copyright 2011 The Chromium OS Authors +.. Copyright 2023 Linaro Ltd.
Devicetree Control in U-Boot ============================ @@ -22,12 +23,11 @@ for three reasons: hierarchical format - It is fairly efficient to read incrementally
-The arch/<arch>/dts directories contains a Makefile for building the devicetree -blob and embedding it in the U-Boot image. This is useful since it allows -U-Boot to configure itself according to what it finds there. If you have -a number of similar boards with different peripherals, you can describe -the features of each board in the devicetree file, and have a single -generic source base. +The U-boot Makefile infrastructure allows for building the devicetree blob +and embedding it in the U-Boot image. This is useful since it allows U-Boot +to configure itself according to what it finds there. If you have a number +of similar boards with different peripherals, you can describe the features +of each board in the devicetree file, and have a single generic source base.
To enable this feature, add CONFIG_OF_CONTROL to your board config file.
@@ -68,8 +68,21 @@ a binary file. U-Boot adds its own `fdtgrep` for creating subsets of the file. Where do I get a devicetree file for my board? ----------------------------------------------
-You may find that the Linux kernel has a suitable file. Look in the -kernel source in arch/<arch>/boot/dts. +Linux kernel Git repository has been the place where devicetree files along +with devicetree bindings are stored and maintained. There is devicetee-rebasing +(dtrepo_) which maintains a forked copy of devicetree files along with bindings +at every Linux kernel major release or intermideate release candidates. + +In order to maintain devicetree files sync, U-boot maintains a Git subtree for +devicetee-rebasing repo as `devicetee-rebasing/` sub-directory. It is regularly +kept updated with every new kernel major release via subtree pull as follows:: + + git subtree pull --prefix devicetree-rebasing \ + git://git.kernel.org/pub/scm/linux/kernel/git/devicetree/devicetree-rebasing.git \ + <release-tag> --squash + +You may find that the `devicetee-rebasing/` sub-directory has a suitable +devicetree file for your board. Look in `devicetree-rebasing/src/<arch>/`.
If not you might find other boards with suitable files that you can modify to your needs. Look in the board directories for files with a @@ -81,18 +94,21 @@ Failing that, you could write one from scratch yourself! Configuration -------------
-Use:: +Traditionally, U-boot placed copies of devicetree source files from Linux +kernel into `arch/<arch>/dts/<name>.dts` which can be selected via::
- #define CONFIG_DEFAULT_DEVICE_TREE "<name>" + #define CONFIG_DEFAULT_DEVICE_TREE "<name>"
-to set the filename of the devicetree source. Then put your devicetree -file into:: +However, it has become combersome over time for each SoC/board maintainer to +keep devicetree files in sync with Linux kernel. Thereby, SoC/board maintainers +are encouraged to migrate to use mirrored copies from `devicetree-rebasing/` +into `dts/arch/<arch>/<vendor>` via::
- arch/<arch>/dts/<name>.dts + #define CONFIG_OF_UPSTREAM=y + #define CONFIG_DEFAULT_DEVICE_TREE "<vendor>/<name>"
-This should include your CPU or SOC's devicetree file, placed in -`arch/<arch>/dts`, and then make any adjustments required using a u-boot-dtsi -file for your board. +This should include your CPU or SOC's devicetree file. On top of that any U-boot +specific tweaks (see: dttweaks_) can be made for your board.
If CONFIG_OF_EMBED is defined, then it will be picked up and built into the U-Boot image (including u-boot.bin). This is suitable for debugging @@ -156,8 +172,9 @@ ways: Adding tweaks for U-Boot ------------------------
-It is strongly recommended that devicetree files in U-Boot are an exact copy of -those in Linux, so that it is easy to sync them up from time to time. +With devicetee-rebasing Git subtree, it is ensured that devicetree files in +U-Boot are an exact copy of those in Linux kernel via mirroring into +`dts/arch/<arch>/<vendor>`.
U-Boot is of course a very different project from Linux, e.g. it operates under much more restrictive memory and code-size constraints. Where Linux may use a @@ -170,8 +187,8 @@ constraints are even more extreme and the devicetree is shrunk to remove unwanted nodes, or even turned into C code to avoid access overhead.
U-Boot automatically looks for and includes a file with updates to the standard -devicetree for your board, searching for them in the same directory as the -main file, in this order:: +devicetree for your board, searching for them in `arch/<arch>/dts/` in this +order::
<orig_filename>-u-boot.dtsi <CONFIG_SYS_SOC>-u-boot.dtsi @@ -200,6 +217,52 @@ to specify a list of .dtsi files that will also be included when building .dtb files.
+Devicetree bindings schema checks +--------------------------------- + +With devicetee-rebasing Git subtree, the devicetree bindings are also regularly +synced with Linux kernel as `devicetree-rebasing/Bindings/` sub-directory. This +allows U-boot to run devicetree bindings schema checks which will bring +compliance to U-boot core/drivers regarding usage of devicetree. + +Dependencies +~~~~~~~~~~~~ + +The DT schema project must be installed in order to validate the DT schema +binding documents and validate DTS files using the DT schema. The DT schema +project can be installed with pip:: + + pip3 install dtschema + +Note that 'dtschema' installation requires 'swig' and Python development files +installed first. On Debian/Ubuntu systems:: + + apt install swig python3-dev + +Several executables (dt-doc-validate, dt-mk-schema, dt-validate) will be +installed. Ensure they are in your PATH (~/.local/bin by default). + +Recommended is also to install yamllint (used by dtschema when present). + +Running checks +~~~~~~~~~~~~~~ + +In order to perform validation of DTB files, use the ``dtbs_check`` target:: + + make dtbs_check + +It is also possible to run checks with a subset of matching schema files by +setting the ``DT_SCHEMA_FILES`` variable to 1 or more specific schema files or +patterns (partial match of a fixed string). Each file or pattern should be +separated by ':'. + +:: + + make dtbs_check DT_SCHEMA_FILES=trivial-devices.yaml:rtc.yaml + make dtbs_check DT_SCHEMA_FILES=/gpio/ + make dtbs_check DT_SCHEMA_FILES=trivial-devices.yaml + + Relocation, SPL and TPL -----------------------
@@ -261,8 +324,9 @@ used it before Linux (e.g. snow). The two projects developed in parallel and there are still some differences in the bindings for certain boards. While there has been discussion of having a separate repository for devicetree files, in practice the Linux kernel Git repository has become the place where -these are stored, with U-Boot taking copies and adding tweaks with u-boot.dtsi -files. +these are stored, with U-Boot taking copies via devicetree-rebasing repo +(see: dtrepo_) and adding tweaks with u-boot.dtsi files.
.. _dtspec: https://www.devicetree.org/specifications/ .. _dtlist: https://www.spinics.net/lists/devicetree-compiler/ +.. _dtrepo: https://git.kernel.org/pub/scm/linux/kernel/git/devicetree/devicetree-rebasi...
Hi Sumit,
On Thu, 14 Dec 2023 at 06:52, Sumit Garg sumit.garg@linaro.org wrote:
Encourage SoC/board maintainers to migrate to using devicetree-rebasing subtree and maintain a regular sync with Linux kernel devicetree files and bindings.
Along with that add documentation regarding how to run DT bindings schema checks.
Signed-off-by: Sumit Garg sumit.garg@linaro.org
doc/develop/devicetree/control.rst | 108 +++++++++++++++++++++++------ 1 file changed, 86 insertions(+), 22 deletions(-)
diff --git a/doc/develop/devicetree/control.rst b/doc/develop/devicetree/control.rst index cbb65c9b177..12ef55ed368 100644 --- a/doc/develop/devicetree/control.rst +++ b/doc/develop/devicetree/control.rst @@ -1,5 +1,6 @@ .. SPDX-License-Identifier: GPL-2.0+ .. sectionauthor:: Copyright 2011 The Chromium OS Authors +.. Copyright 2023 Linaro Ltd.
Devicetree Control in U-Boot
@@ -22,12 +23,11 @@ for three reasons: hierarchical format
- It is fairly efficient to read incrementally
-The arch/<arch>/dts directories contains a Makefile for building the devicetree -blob and embedding it in the U-Boot image. This is useful since it allows -U-Boot to configure itself according to what it finds there. If you have -a number of similar boards with different peripherals, you can describe -the features of each board in the devicetree file, and have a single -generic source base. +The U-boot Makefile infrastructure allows for building the devicetree blob +and embedding it in the U-Boot image. This is useful since it allows U-Boot +to configure itself according to what it finds there. If you have a number +of similar boards with different peripherals, you can describe the features +of each board in the devicetree file, and have a single generic source base.
To enable this feature, add CONFIG_OF_CONTROL to your board config file.
@@ -68,8 +68,21 @@ a binary file. U-Boot adds its own `fdtgrep` for creating subsets of the file. Where do I get a devicetree file for my board?
-You may find that the Linux kernel has a suitable file. Look in the -kernel source in arch/<arch>/boot/dts. +Linux kernel Git repository has been the place where devicetree files along +with devicetree bindings are stored and maintained. There is devicetee-rebasing +(dtrepo_) which maintains a forked copy of devicetree files along with bindings +at every Linux kernel major release or intermideate release candidates.
+In order to maintain devicetree files sync, U-boot maintains a Git subtree for +devicetee-rebasing repo as `devicetee-rebasing/` sub-directory. It is regularly +kept updated with every new kernel major release via subtree pull as follows::
- git subtree pull --prefix devicetree-rebasing \
git://git.kernel.org/pub/scm/linux/kernel/git/devicetree/devicetree-rebasing.git \<release-tag> --squash+You may find that the `devicetee-rebasing/` sub-directory has a suitable +devicetree file for your board. Look in `devicetree-rebasing/src/<arch>/`.
If not you might find other boards with suitable files that you can modify to your needs. Look in the board directories for files with a @@ -81,18 +94,21 @@ Failing that, you could write one from scratch yourself! Configuration
-Use:: +Traditionally, U-boot placed copies of devicetree source files from Linux +kernel into `arch/<arch>/dts/<name>.dts` which can be selected via::
- #define CONFIG_DEFAULT_DEVICE_TREE "<name>"
- #define CONFIG_DEFAULT_DEVICE_TREE "<name>"
-to set the filename of the devicetree source. Then put your devicetree -file into:: +However, it has become combersome over time for each SoC/board maintainer to +keep devicetree files in sync with Linux kernel. Thereby, SoC/board maintainers +are encouraged to migrate to use mirrored copies from `devicetree-rebasing/` +into `dts/arch/<arch>/<vendor>` via::
- arch/<arch>/dts/<name>.dts
- #define CONFIG_OF_UPSTREAM=y
- #define CONFIG_DEFAULT_DEVICE_TREE "<vendor>/<name>"
-This should include your CPU or SOC's devicetree file, placed in -`arch/<arch>/dts`, and then make any adjustments required using a u-boot-dtsi -file for your board. +This should include your CPU or SOC's devicetree file. On top of that any U-boot +specific tweaks (see: dttweaks_) can be made for your board.
If CONFIG_OF_EMBED is defined, then it will be picked up and built into the U-Boot image (including u-boot.bin). This is suitable for debugging @@ -156,8 +172,9 @@ ways: Adding tweaks for U-Boot
-It is strongly recommended that devicetree files in U-Boot are an exact copy of -those in Linux, so that it is easy to sync them up from time to time. +With devicetee-rebasing Git subtree, it is ensured that devicetree files in +U-Boot are an exact copy of those in Linux kernel via mirroring into +`dts/arch/<arch>/<vendor>`.
U-Boot is of course a very different project from Linux, e.g. it operates under much more restrictive memory and code-size constraints. Where Linux may use a @@ -170,8 +187,8 @@ constraints are even more extreme and the devicetree is shrunk to remove unwanted nodes, or even turned into C code to avoid access overhead.
U-Boot automatically looks for and includes a file with updates to the standard -devicetree for your board, searching for them in the same directory as the -main file, in this order:: +devicetree for your board, searching for them in `arch/<arch>/dts/` in this +order::
<orig_filename>-u-boot.dtsi <CONFIG_SYS_SOC>-u-boot.dtsi@@ -200,6 +217,52 @@ to specify a list of .dtsi files that will also be included when building .dtb files.
+Devicetree bindings schema checks +---------------------------------
+With devicetee-rebasing Git subtree, the devicetree bindings are also regularly +synced with Linux kernel as `devicetree-rebasing/Bindings/` sub-directory. This +allows U-boot to run devicetree bindings schema checks which will bring +compliance to U-boot core/drivers regarding usage of devicetree.
+Dependencies +~~~~~~~~~~~~
+The DT schema project must be installed in order to validate the DT schema +binding documents and validate DTS files using the DT schema. The DT schema +project can be installed with pip::
- pip3 install dtschema
+Note that 'dtschema' installation requires 'swig' and Python development files +installed first. On Debian/Ubuntu systems::
- apt install swig python3-dev
+Several executables (dt-doc-validate, dt-mk-schema, dt-validate) will be +installed. Ensure they are in your PATH (~/.local/bin by default).
+Recommended is also to install yamllint (used by dtschema when present).
+Running checks +~~~~~~~~~~~~~~
+In order to perform validation of DTB files, use the ``dtbs_check`` target::
- make dtbs_check
+It is also possible to run checks with a subset of matching schema files by +setting the ``DT_SCHEMA_FILES`` variable to 1 or more specific schema files or +patterns (partial match of a fixed string). Each file or pattern should be +separated by ':'.
+::
- make dtbs_check DT_SCHEMA_FILES=trivial-devices.yaml:rtc.yaml
- make dtbs_check DT_SCHEMA_FILES=/gpio/
- make dtbs_check DT_SCHEMA_FILES=trivial-devices.yaml
Relocation, SPL and TPL
@@ -261,8 +324,9 @@ used it before Linux (e.g. snow). The two projects developed in parallel and there are still some differences in the bindings for certain boards. While there has been discussion of having a separate repository for devicetree files, in practice the Linux kernel Git repository has become the place where -these are stored, with U-Boot taking copies and adding tweaks with u-boot.dtsi -files. +these are stored, with U-Boot taking copies via devicetree-rebasing repo +(see: dtrepo_) and adding tweaks with u-boot.dtsi files.
.. _dtspec: https://www.devicetree.org/specifications/ .. _dtlist: https://www.spinics.net/lists/devicetree-compiler/
+.. _dtrepo: https://git.kernel.org/pub/scm/linux/kernel/git/devicetree/devicetree-rebasi...
2.34.1
OK, ignore my comment about docs.
Regards, Simon
Signed-off-by: Sumit Garg sumit.garg@linaro.org --- MAINTAINERS | 6 ++++++ 1 file changed, 6 insertions(+)
diff --git a/MAINTAINERS b/MAINTAINERS index 969514468cb..253092c345c 100644 --- a/MAINTAINERS +++ b/MAINTAINERS @@ -951,6 +951,12 @@ F: cmd/cyclic.c F: common/cyclic.c F: include/cyclic.h
+DEVICETREE REBASING SUBTREE +M: Sumit Garg sumit.garg@linaro.org +S: Maintained +F: devicetree-rebasing/ +F: dts/arch/ + DFU M: Lukasz Majewski lukma@denx.de M: Mattijs Korpershoek mkorpershoek@baylibre.com
On Thu, 14 Dec 2023 at 06:52, Sumit Garg sumit.garg@linaro.org wrote:
Signed-off-by: Sumit Garg sumit.garg@linaro.org
MAINTAINERS | 6 ++++++ 1 file changed, 6 insertions(+)
diff --git a/MAINTAINERS b/MAINTAINERS index 969514468cb..253092c345c 100644 --- a/MAINTAINERS +++ b/MAINTAINERS @@ -951,6 +951,12 @@ F: cmd/cyclic.c F: common/cyclic.c F: include/cyclic.h
+DEVICETREE REBASING SUBTREE +M: Sumit Garg sumit.garg@linaro.org +S: Maintained +F: devicetree-rebasing/ +F: dts/arch/
DFU M: Lukasz Majewski lukma@denx.de M: Mattijs Korpershoek mkorpershoek@baylibre.com -- 2.34.1
Reviewed-by: Simon Glass sjg@chromium.org
Although there were still some variations in board DTS files based on meson-gxbb SoC but I think those were minor differences from upstream and shouldn't impact boot on these devices.
So switch to upstream DT via mirroring amlogic/ directory from devicetree-rebasing/src/arm64/amlogic/ directory. And thereby directly building DTB from there including *-u-boot.dtsi files from arch/$(ARCH)/dts/ directory.
Signed-off-by: Sumit Garg sumit.garg@linaro.org --- configs/nanopi-k2_defconfig | 3 ++- configs/odroid-c2_defconfig | 3 ++- configs/p200_defconfig | 3 ++- configs/p201_defconfig | 3 ++- configs/videostrong-kii-pro_defconfig | 3 ++- configs/wetek-hub_defconfig | 3 ++- configs/wetek-play2_defconfig | 3 ++- dts/arch/arm64/Makefile | 9 +++++++++ dts/arch/arm64/amlogic | 1 + 9 files changed, 24 insertions(+), 7 deletions(-) create mode 120000 dts/arch/arm64/amlogic
diff --git a/configs/nanopi-k2_defconfig b/configs/nanopi-k2_defconfig index 41dbf7981f8..3db296916e9 100644 --- a/configs/nanopi-k2_defconfig +++ b/configs/nanopi-k2_defconfig @@ -6,7 +6,8 @@ CONFIG_HAS_CUSTOM_SYS_INIT_SP_ADDR=y CONFIG_CUSTOM_SYS_INIT_SP_ADDR=0x20000000 CONFIG_ENV_SIZE=0x2000 CONFIG_DM_GPIO=y -CONFIG_DEFAULT_DEVICE_TREE="meson-gxbb-nanopi-k2" +CONFIG_OF_UPSTREAM=y +CONFIG_DEFAULT_DEVICE_TREE="amlogic/meson-gxbb-nanopi-k2" CONFIG_OF_LIBFDT_OVERLAY=y CONFIG_DM_RESET=y CONFIG_DEBUG_UART_BASE=0xc81004c0 diff --git a/configs/odroid-c2_defconfig b/configs/odroid-c2_defconfig index 5f9f323e06e..65857ff478c 100644 --- a/configs/odroid-c2_defconfig +++ b/configs/odroid-c2_defconfig @@ -6,7 +6,8 @@ CONFIG_HAS_CUSTOM_SYS_INIT_SP_ADDR=y CONFIG_CUSTOM_SYS_INIT_SP_ADDR=0x20000000 CONFIG_ENV_SIZE=0x2000 CONFIG_DM_GPIO=y -CONFIG_DEFAULT_DEVICE_TREE="meson-gxbb-odroidc2" +CONFIG_OF_UPSTREAM=y +CONFIG_DEFAULT_DEVICE_TREE="amlogic/meson-gxbb-odroidc2" CONFIG_OF_LIBFDT_OVERLAY=y CONFIG_DM_RESET=y CONFIG_DEBUG_UART_BASE=0xc81004c0 diff --git a/configs/p200_defconfig b/configs/p200_defconfig index cd579ef5f14..c1792db51fd 100644 --- a/configs/p200_defconfig +++ b/configs/p200_defconfig @@ -6,7 +6,8 @@ CONFIG_HAS_CUSTOM_SYS_INIT_SP_ADDR=y CONFIG_CUSTOM_SYS_INIT_SP_ADDR=0x20000000 CONFIG_ENV_SIZE=0x2000 CONFIG_DM_GPIO=y -CONFIG_DEFAULT_DEVICE_TREE="meson-gxbb-p200" +CONFIG_OF_UPSTREAM=y +CONFIG_DEFAULT_DEVICE_TREE="amlogic/meson-gxbb-p200" CONFIG_OF_LIBFDT_OVERLAY=y CONFIG_DM_RESET=y CONFIG_DEBUG_UART_BASE=0xc81004c0 diff --git a/configs/p201_defconfig b/configs/p201_defconfig index b2f0a0ccdb4..202e1da5bcc 100644 --- a/configs/p201_defconfig +++ b/configs/p201_defconfig @@ -7,7 +7,8 @@ CONFIG_HAS_CUSTOM_SYS_INIT_SP_ADDR=y CONFIG_CUSTOM_SYS_INIT_SP_ADDR=0x20000000 CONFIG_ENV_SIZE=0x2000 CONFIG_DM_GPIO=y -CONFIG_DEFAULT_DEVICE_TREE="meson-gxbb-p201" +CONFIG_OF_UPSTREAM=y +CONFIG_DEFAULT_DEVICE_TREE="amlogic/meson-gxbb-p201" CONFIG_OF_LIBFDT_OVERLAY=y CONFIG_DM_RESET=y CONFIG_DEBUG_UART_BASE=0xc81004c0 diff --git a/configs/videostrong-kii-pro_defconfig b/configs/videostrong-kii-pro_defconfig index 3eda8f14a21..d09333d3b96 100644 --- a/configs/videostrong-kii-pro_defconfig +++ b/configs/videostrong-kii-pro_defconfig @@ -6,7 +6,8 @@ CONFIG_HAS_CUSTOM_SYS_INIT_SP_ADDR=y CONFIG_CUSTOM_SYS_INIT_SP_ADDR=0x20000000 CONFIG_ENV_SIZE=0x2000 CONFIG_DM_GPIO=y -CONFIG_DEFAULT_DEVICE_TREE="meson-gxbb-kii-pro" +CONFIG_OF_UPSTREAM=y +CONFIG_DEFAULT_DEVICE_TREE="amlogic/meson-gxbb-kii-pro" CONFIG_OF_LIBFDT_OVERLAY=y CONFIG_DM_RESET=y CONFIG_DEBUG_UART_BASE=0xc81004c0 diff --git a/configs/wetek-hub_defconfig b/configs/wetek-hub_defconfig index fd92b041e73..73f3d4aad5d 100644 --- a/configs/wetek-hub_defconfig +++ b/configs/wetek-hub_defconfig @@ -6,7 +6,8 @@ CONFIG_HAS_CUSTOM_SYS_INIT_SP_ADDR=y CONFIG_CUSTOM_SYS_INIT_SP_ADDR=0x20000000 CONFIG_ENV_SIZE=0x2000 CONFIG_DM_GPIO=y -CONFIG_DEFAULT_DEVICE_TREE="meson-gxbb-wetek-hub" +CONFIG_OF_UPSTREAM=y +CONFIG_DEFAULT_DEVICE_TREE="amlogic/meson-gxbb-wetek-hub" CONFIG_OF_LIBFDT_OVERLAY=y CONFIG_DM_RESET=y CONFIG_DEBUG_UART_BASE=0xc81004c0 diff --git a/configs/wetek-play2_defconfig b/configs/wetek-play2_defconfig index b887419a6ba..26f57b4214a 100644 --- a/configs/wetek-play2_defconfig +++ b/configs/wetek-play2_defconfig @@ -6,7 +6,8 @@ CONFIG_HAS_CUSTOM_SYS_INIT_SP_ADDR=y CONFIG_CUSTOM_SYS_INIT_SP_ADDR=0x20000000 CONFIG_ENV_SIZE=0x2000 CONFIG_DM_GPIO=y -CONFIG_DEFAULT_DEVICE_TREE="meson-gxbb-wetek-play2" +CONFIG_OF_UPSTREAM=y +CONFIG_DEFAULT_DEVICE_TREE="amlogic/meson-gxbb-wetek-play2" CONFIG_OF_LIBFDT_OVERLAY=y CONFIG_DM_RESET=y CONFIG_DEBUG_UART_BASE=0xc81004c0 diff --git a/dts/arch/arm64/Makefile b/dts/arch/arm64/Makefile index 16e9fea622d..d548584cf5c 100644 --- a/dts/arch/arm64/Makefile +++ b/dts/arch/arm64/Makefile @@ -1,5 +1,14 @@ # SPDX-License-Identifier: GPL-2.0+
+dtb-$(CONFIG_ARCH_MESON) += \ + amlogic/meson-gxbb-kii-pro.dtb \ + amlogic/meson-gxbb-nanopi-k2.dtb \ + amlogic/meson-gxbb-odroidc2.dtb \ + amlogic/meson-gxbb-p200.dtb \ + amlogic/meson-gxbb-p201.dtb \ + amlogic/meson-gxbb-wetek-hub.dtb \ + amlogic/meson-gxbb-wetek-play2.dtb + include $(srctree)/scripts/Makefile.dts
targets += $(dtb-y) diff --git a/dts/arch/arm64/amlogic b/dts/arch/arm64/amlogic new file mode 120000 index 00000000000..73f7c3e7bd0 --- /dev/null +++ b/dts/arch/arm64/amlogic @@ -0,0 +1 @@ +../../../devicetree-rebasing/src/arm64/amlogic/ \ No newline at end of file
On 14/12/2023 14:51, Sumit Garg wrote:
Although there were still some variations in board DTS files based on meson-gxbb SoC but I think those were minor differences from upstream and shouldn't impact boot on these devices.
So switch to upstream DT via mirroring amlogic/ directory from devicetree-rebasing/src/arm64/amlogic/ directory. And thereby directly building DTB from there including *-u-boot.dtsi files from arch/$(ARCH)/dts/ directory.
Signed-off-by: Sumit Garg sumit.garg@linaro.org
configs/nanopi-k2_defconfig | 3 ++- configs/odroid-c2_defconfig | 3 ++- configs/p200_defconfig | 3 ++- configs/p201_defconfig | 3 ++- configs/videostrong-kii-pro_defconfig | 3 ++- configs/wetek-hub_defconfig | 3 ++- configs/wetek-play2_defconfig | 3 ++- dts/arch/arm64/Makefile | 9 +++++++++ dts/arch/arm64/amlogic | 1 + 9 files changed, 24 insertions(+), 7 deletions(-) create mode 120000 dts/arch/arm64/amlogic
diff --git a/configs/nanopi-k2_defconfig b/configs/nanopi-k2_defconfig index 41dbf7981f8..3db296916e9 100644 --- a/configs/nanopi-k2_defconfig +++ b/configs/nanopi-k2_defconfig @@ -6,7 +6,8 @@ CONFIG_HAS_CUSTOM_SYS_INIT_SP_ADDR=y CONFIG_CUSTOM_SYS_INIT_SP_ADDR=0x20000000 CONFIG_ENV_SIZE=0x2000 CONFIG_DM_GPIO=y -CONFIG_DEFAULT_DEVICE_TREE="meson-gxbb-nanopi-k2" +CONFIG_OF_UPSTREAM=y +CONFIG_DEFAULT_DEVICE_TREE="amlogic/meson-gxbb-nanopi-k2" CONFIG_OF_LIBFDT_OVERLAY=y CONFIG_DM_RESET=y CONFIG_DEBUG_UART_BASE=0xc81004c0 diff --git a/configs/odroid-c2_defconfig b/configs/odroid-c2_defconfig index 5f9f323e06e..65857ff478c 100644 --- a/configs/odroid-c2_defconfig +++ b/configs/odroid-c2_defconfig @@ -6,7 +6,8 @@ CONFIG_HAS_CUSTOM_SYS_INIT_SP_ADDR=y CONFIG_CUSTOM_SYS_INIT_SP_ADDR=0x20000000 CONFIG_ENV_SIZE=0x2000 CONFIG_DM_GPIO=y -CONFIG_DEFAULT_DEVICE_TREE="meson-gxbb-odroidc2" +CONFIG_OF_UPSTREAM=y +CONFIG_DEFAULT_DEVICE_TREE="amlogic/meson-gxbb-odroidc2" CONFIG_OF_LIBFDT_OVERLAY=y CONFIG_DM_RESET=y CONFIG_DEBUG_UART_BASE=0xc81004c0 diff --git a/configs/p200_defconfig b/configs/p200_defconfig index cd579ef5f14..c1792db51fd 100644 --- a/configs/p200_defconfig +++ b/configs/p200_defconfig @@ -6,7 +6,8 @@ CONFIG_HAS_CUSTOM_SYS_INIT_SP_ADDR=y CONFIG_CUSTOM_SYS_INIT_SP_ADDR=0x20000000 CONFIG_ENV_SIZE=0x2000 CONFIG_DM_GPIO=y -CONFIG_DEFAULT_DEVICE_TREE="meson-gxbb-p200" +CONFIG_OF_UPSTREAM=y +CONFIG_DEFAULT_DEVICE_TREE="amlogic/meson-gxbb-p200" CONFIG_OF_LIBFDT_OVERLAY=y CONFIG_DM_RESET=y CONFIG_DEBUG_UART_BASE=0xc81004c0 diff --git a/configs/p201_defconfig b/configs/p201_defconfig index b2f0a0ccdb4..202e1da5bcc 100644 --- a/configs/p201_defconfig +++ b/configs/p201_defconfig @@ -7,7 +7,8 @@ CONFIG_HAS_CUSTOM_SYS_INIT_SP_ADDR=y CONFIG_CUSTOM_SYS_INIT_SP_ADDR=0x20000000 CONFIG_ENV_SIZE=0x2000 CONFIG_DM_GPIO=y -CONFIG_DEFAULT_DEVICE_TREE="meson-gxbb-p201" +CONFIG_OF_UPSTREAM=y +CONFIG_DEFAULT_DEVICE_TREE="amlogic/meson-gxbb-p201" CONFIG_OF_LIBFDT_OVERLAY=y CONFIG_DM_RESET=y CONFIG_DEBUG_UART_BASE=0xc81004c0 diff --git a/configs/videostrong-kii-pro_defconfig b/configs/videostrong-kii-pro_defconfig index 3eda8f14a21..d09333d3b96 100644 --- a/configs/videostrong-kii-pro_defconfig +++ b/configs/videostrong-kii-pro_defconfig @@ -6,7 +6,8 @@ CONFIG_HAS_CUSTOM_SYS_INIT_SP_ADDR=y CONFIG_CUSTOM_SYS_INIT_SP_ADDR=0x20000000 CONFIG_ENV_SIZE=0x2000 CONFIG_DM_GPIO=y -CONFIG_DEFAULT_DEVICE_TREE="meson-gxbb-kii-pro" +CONFIG_OF_UPSTREAM=y +CONFIG_DEFAULT_DEVICE_TREE="amlogic/meson-gxbb-kii-pro" CONFIG_OF_LIBFDT_OVERLAY=y CONFIG_DM_RESET=y CONFIG_DEBUG_UART_BASE=0xc81004c0 diff --git a/configs/wetek-hub_defconfig b/configs/wetek-hub_defconfig index fd92b041e73..73f3d4aad5d 100644 --- a/configs/wetek-hub_defconfig +++ b/configs/wetek-hub_defconfig @@ -6,7 +6,8 @@ CONFIG_HAS_CUSTOM_SYS_INIT_SP_ADDR=y CONFIG_CUSTOM_SYS_INIT_SP_ADDR=0x20000000 CONFIG_ENV_SIZE=0x2000 CONFIG_DM_GPIO=y -CONFIG_DEFAULT_DEVICE_TREE="meson-gxbb-wetek-hub" +CONFIG_OF_UPSTREAM=y +CONFIG_DEFAULT_DEVICE_TREE="amlogic/meson-gxbb-wetek-hub" CONFIG_OF_LIBFDT_OVERLAY=y CONFIG_DM_RESET=y CONFIG_DEBUG_UART_BASE=0xc81004c0 diff --git a/configs/wetek-play2_defconfig b/configs/wetek-play2_defconfig index b887419a6ba..26f57b4214a 100644 --- a/configs/wetek-play2_defconfig +++ b/configs/wetek-play2_defconfig @@ -6,7 +6,8 @@ CONFIG_HAS_CUSTOM_SYS_INIT_SP_ADDR=y CONFIG_CUSTOM_SYS_INIT_SP_ADDR=0x20000000 CONFIG_ENV_SIZE=0x2000 CONFIG_DM_GPIO=y -CONFIG_DEFAULT_DEVICE_TREE="meson-gxbb-wetek-play2" +CONFIG_OF_UPSTREAM=y +CONFIG_DEFAULT_DEVICE_TREE="amlogic/meson-gxbb-wetek-play2" CONFIG_OF_LIBFDT_OVERLAY=y CONFIG_DM_RESET=y CONFIG_DEBUG_UART_BASE=0xc81004c0 diff --git a/dts/arch/arm64/Makefile b/dts/arch/arm64/Makefile index 16e9fea622d..d548584cf5c 100644 --- a/dts/arch/arm64/Makefile +++ b/dts/arch/arm64/Makefile @@ -1,5 +1,14 @@ # SPDX-License-Identifier: GPL-2.0+
+dtb-$(CONFIG_ARCH_MESON) += \
amlogic/meson-gxbb-kii-pro.dtb \
amlogic/meson-gxbb-nanopi-k2.dtb \
amlogic/meson-gxbb-odroidc2.dtb \
amlogic/meson-gxbb-p200.dtb \
amlogic/meson-gxbb-p201.dtb \
amlogic/meson-gxbb-wetek-hub.dtb \
amlogic/meson-gxbb-wetek-play2.dtb
include $(srctree)/scripts/Makefile.dts
targets += $(dtb-y)
diff --git a/dts/arch/arm64/amlogic b/dts/arch/arm64/amlogic new file mode 120000 index 00000000000..73f7c3e7bd0 --- /dev/null +++ b/dts/arch/arm64/amlogic @@ -0,0 +1 @@ +../../../devicetree-rebasing/src/arm64/amlogic/ \ No newline at end of file
Reviewed-by: Neil Armstrong neil.armstrong@linaro.org
Note: with https://lore.kernel.org/all/8c32e92f-810f-434b-ba77-3074490458bd@linaro.org/ merged it could be be extended to GXL/GXM aswell
Thanks, Neil
On Wed, 20 Dec 2023 at 16:23, neil.armstrong@linaro.org wrote:
On 14/12/2023 14:51, Sumit Garg wrote:
Although there were still some variations in board DTS files based on meson-gxbb SoC but I think those were minor differences from upstream and shouldn't impact boot on these devices.
So switch to upstream DT via mirroring amlogic/ directory from devicetree-rebasing/src/arm64/amlogic/ directory. And thereby directly building DTB from there including *-u-boot.dtsi files from arch/$(ARCH)/dts/ directory.
Signed-off-by: Sumit Garg sumit.garg@linaro.org
configs/nanopi-k2_defconfig | 3 ++- configs/odroid-c2_defconfig | 3 ++- configs/p200_defconfig | 3 ++- configs/p201_defconfig | 3 ++- configs/videostrong-kii-pro_defconfig | 3 ++- configs/wetek-hub_defconfig | 3 ++- configs/wetek-play2_defconfig | 3 ++- dts/arch/arm64/Makefile | 9 +++++++++ dts/arch/arm64/amlogic | 1 + 9 files changed, 24 insertions(+), 7 deletions(-) create mode 120000 dts/arch/arm64/amlogic
diff --git a/configs/nanopi-k2_defconfig b/configs/nanopi-k2_defconfig index 41dbf7981f8..3db296916e9 100644 --- a/configs/nanopi-k2_defconfig +++ b/configs/nanopi-k2_defconfig @@ -6,7 +6,8 @@ CONFIG_HAS_CUSTOM_SYS_INIT_SP_ADDR=y CONFIG_CUSTOM_SYS_INIT_SP_ADDR=0x20000000 CONFIG_ENV_SIZE=0x2000 CONFIG_DM_GPIO=y -CONFIG_DEFAULT_DEVICE_TREE="meson-gxbb-nanopi-k2" +CONFIG_OF_UPSTREAM=y +CONFIG_DEFAULT_DEVICE_TREE="amlogic/meson-gxbb-nanopi-k2" CONFIG_OF_LIBFDT_OVERLAY=y CONFIG_DM_RESET=y CONFIG_DEBUG_UART_BASE=0xc81004c0 diff --git a/configs/odroid-c2_defconfig b/configs/odroid-c2_defconfig index 5f9f323e06e..65857ff478c 100644 --- a/configs/odroid-c2_defconfig +++ b/configs/odroid-c2_defconfig @@ -6,7 +6,8 @@ CONFIG_HAS_CUSTOM_SYS_INIT_SP_ADDR=y CONFIG_CUSTOM_SYS_INIT_SP_ADDR=0x20000000 CONFIG_ENV_SIZE=0x2000 CONFIG_DM_GPIO=y -CONFIG_DEFAULT_DEVICE_TREE="meson-gxbb-odroidc2" +CONFIG_OF_UPSTREAM=y +CONFIG_DEFAULT_DEVICE_TREE="amlogic/meson-gxbb-odroidc2" CONFIG_OF_LIBFDT_OVERLAY=y CONFIG_DM_RESET=y CONFIG_DEBUG_UART_BASE=0xc81004c0 diff --git a/configs/p200_defconfig b/configs/p200_defconfig index cd579ef5f14..c1792db51fd 100644 --- a/configs/p200_defconfig +++ b/configs/p200_defconfig @@ -6,7 +6,8 @@ CONFIG_HAS_CUSTOM_SYS_INIT_SP_ADDR=y CONFIG_CUSTOM_SYS_INIT_SP_ADDR=0x20000000 CONFIG_ENV_SIZE=0x2000 CONFIG_DM_GPIO=y -CONFIG_DEFAULT_DEVICE_TREE="meson-gxbb-p200" +CONFIG_OF_UPSTREAM=y +CONFIG_DEFAULT_DEVICE_TREE="amlogic/meson-gxbb-p200" CONFIG_OF_LIBFDT_OVERLAY=y CONFIG_DM_RESET=y CONFIG_DEBUG_UART_BASE=0xc81004c0 diff --git a/configs/p201_defconfig b/configs/p201_defconfig index b2f0a0ccdb4..202e1da5bcc 100644 --- a/configs/p201_defconfig +++ b/configs/p201_defconfig @@ -7,7 +7,8 @@ CONFIG_HAS_CUSTOM_SYS_INIT_SP_ADDR=y CONFIG_CUSTOM_SYS_INIT_SP_ADDR=0x20000000 CONFIG_ENV_SIZE=0x2000 CONFIG_DM_GPIO=y -CONFIG_DEFAULT_DEVICE_TREE="meson-gxbb-p201" +CONFIG_OF_UPSTREAM=y +CONFIG_DEFAULT_DEVICE_TREE="amlogic/meson-gxbb-p201" CONFIG_OF_LIBFDT_OVERLAY=y CONFIG_DM_RESET=y CONFIG_DEBUG_UART_BASE=0xc81004c0 diff --git a/configs/videostrong-kii-pro_defconfig b/configs/videostrong-kii-pro_defconfig index 3eda8f14a21..d09333d3b96 100644 --- a/configs/videostrong-kii-pro_defconfig +++ b/configs/videostrong-kii-pro_defconfig @@ -6,7 +6,8 @@ CONFIG_HAS_CUSTOM_SYS_INIT_SP_ADDR=y CONFIG_CUSTOM_SYS_INIT_SP_ADDR=0x20000000 CONFIG_ENV_SIZE=0x2000 CONFIG_DM_GPIO=y -CONFIG_DEFAULT_DEVICE_TREE="meson-gxbb-kii-pro" +CONFIG_OF_UPSTREAM=y +CONFIG_DEFAULT_DEVICE_TREE="amlogic/meson-gxbb-kii-pro" CONFIG_OF_LIBFDT_OVERLAY=y CONFIG_DM_RESET=y CONFIG_DEBUG_UART_BASE=0xc81004c0 diff --git a/configs/wetek-hub_defconfig b/configs/wetek-hub_defconfig index fd92b041e73..73f3d4aad5d 100644 --- a/configs/wetek-hub_defconfig +++ b/configs/wetek-hub_defconfig @@ -6,7 +6,8 @@ CONFIG_HAS_CUSTOM_SYS_INIT_SP_ADDR=y CONFIG_CUSTOM_SYS_INIT_SP_ADDR=0x20000000 CONFIG_ENV_SIZE=0x2000 CONFIG_DM_GPIO=y -CONFIG_DEFAULT_DEVICE_TREE="meson-gxbb-wetek-hub" +CONFIG_OF_UPSTREAM=y +CONFIG_DEFAULT_DEVICE_TREE="amlogic/meson-gxbb-wetek-hub" CONFIG_OF_LIBFDT_OVERLAY=y CONFIG_DM_RESET=y CONFIG_DEBUG_UART_BASE=0xc81004c0 diff --git a/configs/wetek-play2_defconfig b/configs/wetek-play2_defconfig index b887419a6ba..26f57b4214a 100644 --- a/configs/wetek-play2_defconfig +++ b/configs/wetek-play2_defconfig @@ -6,7 +6,8 @@ CONFIG_HAS_CUSTOM_SYS_INIT_SP_ADDR=y CONFIG_CUSTOM_SYS_INIT_SP_ADDR=0x20000000 CONFIG_ENV_SIZE=0x2000 CONFIG_DM_GPIO=y -CONFIG_DEFAULT_DEVICE_TREE="meson-gxbb-wetek-play2" +CONFIG_OF_UPSTREAM=y +CONFIG_DEFAULT_DEVICE_TREE="amlogic/meson-gxbb-wetek-play2" CONFIG_OF_LIBFDT_OVERLAY=y CONFIG_DM_RESET=y CONFIG_DEBUG_UART_BASE=0xc81004c0 diff --git a/dts/arch/arm64/Makefile b/dts/arch/arm64/Makefile index 16e9fea622d..d548584cf5c 100644 --- a/dts/arch/arm64/Makefile +++ b/dts/arch/arm64/Makefile @@ -1,5 +1,14 @@ # SPDX-License-Identifier: GPL-2.0+
+dtb-$(CONFIG_ARCH_MESON) += \
amlogic/meson-gxbb-kii-pro.dtb \amlogic/meson-gxbb-nanopi-k2.dtb \amlogic/meson-gxbb-odroidc2.dtb \amlogic/meson-gxbb-p200.dtb \amlogic/meson-gxbb-p201.dtb \amlogic/meson-gxbb-wetek-hub.dtb \amlogic/meson-gxbb-wetek-play2.dtbinclude $(srctree)/scripts/Makefile.dts
targets += $(dtb-y)
diff --git a/dts/arch/arm64/amlogic b/dts/arch/arm64/amlogic new file mode 120000 index 00000000000..73f7c3e7bd0 --- /dev/null +++ b/dts/arch/arm64/amlogic @@ -0,0 +1 @@ +../../../devicetree-rebasing/src/arm64/amlogic/ \ No newline at end of file
Reviewed-by: Neil Armstrong neil.armstrong@linaro.org
Thanks.
Note: with https://lore.kernel.org/all/8c32e92f-810f-434b-ba77-3074490458bd@linaro.org/ merged it could be be extended to GXL/GXM aswell
Sure, I will convert GXL/GXM too once your PR is merged and this series lands.
-Sumit
Thanks, Neil
Since meson-gxbb based boards switched to using upstream DT, so drop redundant files from arch/arm/dts directory. Only *-u-boot.dtsi files kept in arch/arm/dts directory for these boards.
Signed-off-by: Sumit Garg sumit.garg@linaro.org --- arch/arm/dts/Makefile | 8 - arch/arm/dts/meson-gxbb-kii-pro.dts | 140 ---- arch/arm/dts/meson-gxbb-nanopi-k2.dts | 415 ------------ arch/arm/dts/meson-gxbb-odroidc2.dts | 418 ------------ arch/arm/dts/meson-gxbb-p200.dts | 100 --- arch/arm/dts/meson-gxbb-p201.dts | 26 - arch/arm/dts/meson-gxbb-p20x.dtsi | 250 ------- arch/arm/dts/meson-gxbb-wetek-hub.dts | 58 -- arch/arm/dts/meson-gxbb-wetek-play2.dts | 119 ---- arch/arm/dts/meson-gxbb-wetek.dtsi | 292 -------- arch/arm/dts/meson-gxbb.dtsi | 856 ------------------------ 11 files changed, 2682 deletions(-) delete mode 100644 arch/arm/dts/meson-gxbb-kii-pro.dts delete mode 100644 arch/arm/dts/meson-gxbb-nanopi-k2.dts delete mode 100644 arch/arm/dts/meson-gxbb-odroidc2.dts delete mode 100644 arch/arm/dts/meson-gxbb-p200.dts delete mode 100644 arch/arm/dts/meson-gxbb-p201.dts delete mode 100644 arch/arm/dts/meson-gxbb-p20x.dtsi delete mode 100644 arch/arm/dts/meson-gxbb-wetek-hub.dts delete mode 100644 arch/arm/dts/meson-gxbb-wetek-play2.dts delete mode 100644 arch/arm/dts/meson-gxbb-wetek.dtsi delete mode 100644 arch/arm/dts/meson-gxbb.dtsi
diff --git a/arch/arm/dts/Makefile b/arch/arm/dts/Makefile index 5fc888680b3..45bd1166029 100644 --- a/arch/arm/dts/Makefile +++ b/arch/arm/dts/Makefile @@ -212,14 +212,6 @@ dtb-$(CONFIG_ARCH_MESON) += \ meson-a1-ad401.dtb \ meson-axg-s400.dtb \ meson-axg-jethome-jethub-j100.dtb \ - meson-gxbb-kii-pro.dtb \ - meson-gxbb-nanopi-k2.dtb \ - meson-gxbb-odroidc2.dtb \ - meson-gxbb-nanopi-k2.dtb \ - meson-gxbb-p200.dtb \ - meson-gxbb-p201.dtb \ - meson-gxbb-wetek-hub.dtb \ - meson-gxbb-wetek-play2.dtb \ meson-gxl-s805x-libretech-ac.dtb \ meson-gxl-s905d-libretech-pc.dtb \ meson-gxl-s905w-jethome-jethub-j80.dtb \ diff --git a/arch/arm/dts/meson-gxbb-kii-pro.dts b/arch/arm/dts/meson-gxbb-kii-pro.dts deleted file mode 100644 index e238f1f1012..00000000000 --- a/arch/arm/dts/meson-gxbb-kii-pro.dts +++ /dev/null @@ -1,140 +0,0 @@ -// SPDX-License-Identifier: (GPL-2.0+ OR MIT) -/* - * Copyright (c) 2019 Mohammad Rasim mohammad.rasim96@gmail.com - */ - -/dts-v1/; - -#include "meson-gxbb-p20x.dtsi" -#include <dt-bindings/gpio/gpio.h> -#include <dt-bindings/input/input.h> -#include <dt-bindings/leds/common.h> -#include <dt-bindings/sound/meson-aiu.h> - -/ { - compatible = "videostrong,kii-pro", "amlogic,meson-gxbb"; - model = "Videostrong KII Pro"; - - spdif_dit: audio-codec-0 { - #sound-dai-cells = <0>; - compatible = "linux,spdif-dit"; - status = "okay"; - sound-name-prefix = "DIT"; - }; - - leds { - compatible = "gpio-leds"; - led { - gpios = <&gpio_ao GPIOAO_13 GPIO_ACTIVE_LOW>; - color = <LED_COLOR_ID_RED>; - function = LED_FUNCTION_STATUS; - default-state = "off"; - }; - }; - - gpio-keys-polled { - compatible = "gpio-keys-polled"; - poll-interval = <20>; - - button-reset { - label = "reset"; - linux,code = <KEY_POWER>; - gpios = <&gpio_ao GPIOAO_3 GPIO_ACTIVE_HIGH>; - }; - }; - - sound { - compatible = "amlogic,gx-sound-card"; - model = "KII-PRO"; - assigned-clocks = <&clkc CLKID_MPLL0>, - <&clkc CLKID_MPLL1>, - <&clkc CLKID_MPLL2>; - assigned-clock-parents = <0>, <0>, <0>; - assigned-clock-rates = <294912000>, - <270950400>, - <393216000>; - - dai-link-0 { - sound-dai = <&aiu AIU_CPU CPU_I2S_FIFO>; - }; - - dai-link-1 { - sound-dai = <&aiu AIU_CPU CPU_SPDIF_FIFO>; - }; - - dai-link-2 { - sound-dai = <&aiu AIU_CPU CPU_I2S_ENCODER>; - dai-format = "i2s"; - mclk-fs = <256>; - - codec-0 { - sound-dai = <&aiu AIU_HDMI CTRL_I2S>; - }; - }; - - dai-link-3 { - sound-dai = <&aiu AIU_CPU CPU_SPDIF_ENCODER>; - - codec-0 { - sound-dai = <&spdif_dit>; - }; - }; - - dai-link-4 { - sound-dai = <&aiu AIU_HDMI CTRL_OUT>; - - codec-0 { - sound-dai = <&hdmi_tx>; - }; - }; - }; -}; - -&aiu { - status = "okay"; - pinctrl-0 = <&spdif_out_y_pins>; - pinctrl-names = "default"; -}; - -ðmac { - status = "okay"; - pinctrl-0 = <ð_rmii_pins>; - pinctrl-names = "default"; - - phy-handle = <ð_phy0>; - phy-mode = "rmii"; - - mdio { - compatible = "snps,dwmac-mdio"; - #address-cells = <1>; - #size-cells = <0>; - - eth_phy0: ethernet-phy@0 { - /* IC Plus IP101GR (0x02430c54) */ - reg = <0>; - reset-assert-us = <10000>; - reset-deassert-us = <10000>; - reset-gpios = <&gpio GPIOZ_14 GPIO_ACTIVE_LOW>; - }; - }; -}; - -&ir { - linux,rc-map-name = "rc-videostrong-kii-pro"; -}; - -&uart_A { - status = "okay"; - pinctrl-0 = <&uart_a_pins>, <&uart_a_cts_rts_pins>; - pinctrl-names = "default"; - uart-has-rtscts; - - bluetooth { - compatible = "brcm,bcm4335a0"; - shutdown-gpios = <&gpio GPIOX_20 GPIO_ACTIVE_HIGH>; - host-wakeup-gpios = <&gpio GPIOX_21 GPIO_ACTIVE_HIGH>; - max-speed = <2000000>; - clocks = <&wifi32k>; - clock-names = "lpo"; - }; -}; diff --git a/arch/arm/dts/meson-gxbb-nanopi-k2.dts b/arch/arm/dts/meson-gxbb-nanopi-k2.dts deleted file mode 100644 index 7273eed5292..00000000000 --- a/arch/arm/dts/meson-gxbb-nanopi-k2.dts +++ /dev/null @@ -1,415 +0,0 @@ -// SPDX-License-Identifier: (GPL-2.0+ OR MIT) -/* - * Copyright (c) 2017 Andreas Färber - */ - -/dts-v1/; - -#include "meson-gxbb.dtsi" -#include <dt-bindings/gpio/gpio.h> -#include <dt-bindings/sound/meson-aiu.h> - -/ { - compatible = "friendlyarm,nanopi-k2", "amlogic,meson-gxbb"; - model = "FriendlyARM NanoPi K2"; - - aliases { - serial0 = &uart_AO; - ethernet0 = ðmac; - }; - - chosen { - stdout-path = "serial0:115200n8"; - }; - - memory@0 { - device_type = "memory"; - reg = <0x0 0x0 0x0 0x80000000>; - }; - - leds { - compatible = "gpio-leds"; - - led-stat { - label = "nanopi-k2:blue:stat"; - gpios = <&gpio_ao GPIOAO_13 GPIO_ACTIVE_HIGH>; - default-state = "on"; - panic-indicator; - }; - }; - - vdd_5v: regulator-vdd-5v { - compatible = "regulator-fixed"; - regulator-name = "VDD_5V"; - regulator-min-microvolt = <5000000>; - regulator-max-microvolt = <5000000>; - }; - - vddio_ao18: regulator-vddio-ao18 { - compatible = "regulator-fixed"; - regulator-name = "VDDIO_AO18"; - regulator-min-microvolt = <1800000>; - regulator-max-microvolt = <1800000>; - }; - - vddio_ao3v3: regulator-vddio-ao3v3 { - compatible = "regulator-fixed"; - regulator-name = "VDDIO_AO3.3V"; - regulator-min-microvolt = <3300000>; - regulator-max-microvolt = <3300000>; - }; - - vddio_tf: regulator-vddio-tf { - compatible = "regulator-gpio"; - - regulator-name = "VDDIO_TF"; - regulator-min-microvolt = <1800000>; - regulator-max-microvolt = <3300000>; - - gpios = <&gpio_ao GPIOAO_2 GPIO_ACTIVE_HIGH>; - gpios-states = <0>; - - states = <3300000 0>, - <1800000 1>; - - regulator-settling-time-up-us = <100>; - regulator-settling-time-down-us = <5000>; - }; - - wifi_32k: wifi-32k { - compatible = "pwm-clock"; - #clock-cells = <0>; - clock-frequency = <32768>; - pwms = <&pwm_ef 0 30518 0>; /* PWM_E at 32.768KHz */ - }; - - sdio_pwrseq: sdio-pwrseq { - compatible = "mmc-pwrseq-simple"; - reset-gpios = <&gpio GPIOX_6 GPIO_ACTIVE_LOW>; - clocks = <&wifi_32k>; - clock-names = "ext_clock"; - }; - - vcc1v8: regulator-vcc1v8 { - compatible = "regulator-fixed"; - regulator-name = "VCC1.8V"; - regulator-min-microvolt = <1800000>; - regulator-max-microvolt = <1800000>; - }; - - vcc3v3: regulator-vcc3v3 { - compatible = "regulator-fixed"; - regulator-name = "VCC3.3V"; - regulator-min-microvolt = <3300000>; - regulator-max-microvolt = <3300000>; - }; - - emmc_pwrseq: emmc-pwrseq { - compatible = "mmc-pwrseq-emmc"; - reset-gpios = <&gpio BOOT_9 GPIO_ACTIVE_LOW>; - }; - - /* CVBS is available on CON1 pin 36, disabled by default */ - cvbs-connector { - compatible = "composite-video-connector"; - status = "disabled"; - - port { - cvbs_connector_in: endpoint { - remote-endpoint = <&cvbs_vdac_out>; - }; - }; - }; - - hdmi-connector { - compatible = "hdmi-connector"; - type = "a"; - - port { - hdmi_connector_in: endpoint { - remote-endpoint = <&hdmi_tx_tmds_out>; - }; - }; - }; - - sound { - compatible = "amlogic,gx-sound-card"; - model = "NANOPI-K2"; - assigned-clocks = <&clkc CLKID_MPLL0>, - <&clkc CLKID_MPLL1>, - <&clkc CLKID_MPLL2>; - assigned-clock-parents = <0>, <0>, <0>; - assigned-clock-rates = <294912000>, - <270950400>, - <393216000>; - status = "okay"; - - dai-link-0 { - sound-dai = <&aiu AIU_CPU CPU_I2S_FIFO>; - }; - - dai-link-1 { - sound-dai = <&aiu AIU_CPU CPU_I2S_ENCODER>; - dai-format = "i2s"; - mclk-fs = <256>; - - codec-0 { - sound-dai = <&aiu AIU_HDMI CTRL_I2S>; - }; - }; - - dai-link-2 { - sound-dai = <&aiu AIU_HDMI CTRL_OUT>; - - codec-0 { - sound-dai = <&hdmi_tx>; - }; - }; - }; -}; - -&aiu { - status = "okay"; -}; - -&cec_AO { - status = "okay"; - pinctrl-0 = <&ao_cec_pins>; - pinctrl-names = "default"; - hdmi-phandle = <&hdmi_tx>; -}; - -&cvbs_vdac_port { - cvbs_vdac_out: endpoint { - remote-endpoint = <&cvbs_connector_in>; - }; -}; - -ðmac { - status = "okay"; - pinctrl-0 = <ð_rgmii_pins>; - pinctrl-names = "default"; - - phy-handle = <ð_phy0>; - phy-mode = "rgmii"; - - amlogic,tx-delay-ns = <2>; - - mdio { - compatible = "snps,dwmac-mdio"; - #address-cells = <1>; - #size-cells = <0>; - - eth_phy0: ethernet-phy@0 { - /* Realtek RTL8211F (0x001cc916) */ - reg = <0>; - - reset-assert-us = <10000>; - reset-deassert-us = <80000>; - reset-gpios = <&gpio GPIOZ_14 GPIO_ACTIVE_LOW>; - - interrupt-parent = <&gpio_intc>; - /* MAC_INTR on GPIOZ_15 */ - interrupts = <29 IRQ_TYPE_LEVEL_LOW>; - }; - }; -}; - -&hdmi_tx { - status = "okay"; - pinctrl-0 = <&hdmi_hpd_pins>, <&hdmi_i2c_pins>; - pinctrl-names = "default"; -}; - -&hdmi_tx_tmds_port { - hdmi_tx_tmds_out: endpoint { - remote-endpoint = <&hdmi_connector_in>; - }; -}; - -&ir { - status = "okay"; - pinctrl-0 = <&remote_input_ao_pins>; - pinctrl-names = "default"; -}; - -&gpio_ao { - gpio-line-names = "UART TX", "UART RX", "Power Control", "Power Key In", - "VCCK En", "CON1 Header Pin31", - "I2S Header Pin6", "IR In", "I2S Header Pin7", - "I2S Header Pin3", "I2S Header Pin4", - "I2S Header Pin5", "HDMI CEC", "SYS LED", - /* GPIO_TEST_N */ - ""; -}; - -&gpio { - gpio-line-names = /* Bank GPIOZ */ - "Eth MDIO", "Eth MDC", "Eth RGMII RX Clk", - "Eth RX DV", "Eth RX D0", "Eth RX D1", "Eth RX D2", - "Eth RX D3", "Eth RGMII TX Clk", "Eth TX En", - "Eth TX D0", "Eth TX D1", "Eth TX D2", "Eth TX D3", - "Eth PHY nRESET", "Eth PHY Intc", - /* Bank GPIOH */ - "HDMI HPD", "HDMI DDC SDA", "HDMI DDC SCL", - "CON1 Header Pin33", - /* Bank BOOT */ - "eMMC D0", "eMMC D1", "eMMC D2", "eMMC D3", "eMMC D4", - "eMMC D5", "eMMC D6", "eMMC D7", "eMMC Clk", - "eMMC Reset", "eMMC CMD", - "", "", "", "", "eMMC DS", - "", "", - /* Bank CARD */ - "SDCard D1", "SDCard D0", "SDCard CLK", "SDCard CMD", - "SDCard D3", "SDCard D2", "SDCard Det", - /* Bank GPIODV */ - "", "", "", "", "", "", "", "", "", "", "", "", "", - "", "", "", "", "", "", "", "", "", "", "", - "I2C A SDA", "I2C A SCK", "I2C B SDA", "I2C B SCK", - "VDDEE Regulator", "VCCK Regulator", - /* Bank GPIOY */ - "CON1 Header Pin7", "CON1 Header Pin11", - "CON1 Header Pin13", "CON1 Header Pin15", - "CON1 Header Pin18", "CON1 Header Pin19", - "CON1 Header Pin22", "CON1 Header Pin21", - "CON1 Header Pin24", "CON1 Header Pin23", - "CON1 Header Pin26", "CON1 Header Pin29", - "CON1 Header Pin32", "CON1 Header Pin8", - "CON1 Header Pin10", "CON1 Header Pin16", - "CON1 Header Pin12", - /* Bank GPIOX */ - "WIFI SDIO D0", "WIFI SDIO D1", "WIFI SDIO D2", - "WIFI SDIO D3", "WIFI SDIO CLK", "WIFI SDIO CMD", - "WIFI Power Enable", "WIFI WAKE HOST", - "Bluetooth PCM DOUT", "Bluetooth PCM DIN", - "Bluetooth PCM SYNC", "Bluetooth PCM CLK", - "Bluetooth UART TX", "Bluetooth UART RX", - "Bluetooth UART CTS", "Bluetooth UART RTS", - "", "", "", "WIFI 32K", "Bluetooth Enable", - "Bluetooth WAKE HOST", "", - /* Bank GPIOCLK */ - "", "CON1 Header Pin35", "", ""; -}; - -&pwm_ef { - status = "okay"; - pinctrl-0 = <&pwm_e_pins>; - pinctrl-names = "default"; - clocks = <&clkc CLKID_FCLK_DIV4>; - clock-names = "clkin0"; -}; - -&saradc { - status = "okay"; - vref-supply = <&vddio_ao18>; -}; - -/* SDIO */ -&sd_emmc_a { - status = "okay"; - pinctrl-0 = <&sdio_pins>, <&sdio_irq_pins>; - pinctrl-1 = <&sdio_clk_gate_pins>; - pinctrl-names = "default", "clk-gate"; - #address-cells = <1>; - #size-cells = <0>; - - bus-width = <4>; - cap-sd-highspeed; - max-frequency = <50000000>; - - non-removable; - disable-wp; - - /* WiFi firmware requires power to be kept while in suspend */ - keep-power-in-suspend; - - mmc-pwrseq = <&sdio_pwrseq>; - - vmmc-supply = <&vddio_ao3v3>; - vqmmc-supply = <&vddio_ao18>; - - brcmf: wifi@1 { - compatible = "brcm,bcm4329-fmac"; - reg = <1>; - }; -}; - -/* SD */ -&sd_emmc_b { - status = "okay"; - pinctrl-0 = <&sdcard_pins>; - pinctrl-1 = <&sdcard_clk_gate_pins>; - pinctrl-names = "default", "clk-gate"; - - bus-width = <4>; - cap-sd-highspeed; - sd-uhs-sdr12; - sd-uhs-sdr25; - sd-uhs-sdr50; - sd-uhs-ddr50; - max-frequency = <100000000>; - disable-wp; - - cd-gpios = <&gpio CARD_6 GPIO_ACTIVE_LOW>; - - vmmc-supply = <&vddio_ao3v3>; - vqmmc-supply = <&vddio_tf>; -}; - -/* eMMC */ -&sd_emmc_c { - status = "disabled"; - pinctrl-0 = <&emmc_pins>, <&emmc_ds_pins>; - pinctrl-1 = <&emmc_clk_gate_pins>; - pinctrl-names = "default", "clk-gate"; - - bus-width = <8>; - max-frequency = <200000000>; - non-removable; - disable-wp; - cap-mmc-highspeed; - mmc-ddr-1_8v; - mmc-hs200-1_8v; - - mmc-pwrseq = <&emmc_pwrseq>; - vmmc-supply = <&vcc3v3>; - vqmmc-supply = <&vcc1v8>; -}; - -/* DBG_UART */ -&uart_AO { - status = "okay"; - pinctrl-0 = <&uart_ao_a_pins>; - pinctrl-names = "default"; -}; - -/* Bluetooth on AP6212 */ -&uart_A { - status = "disabled"; - pinctrl-0 = <&uart_a_pins>, <&uart_a_cts_rts_pins>; - pinctrl-names = "default"; -}; - -/* 40-pin CON1 */ -&uart_C { - status = "disabled"; - pinctrl-0 = <&uart_c_pins>; - pinctrl-names = "default"; -}; - -&usb0_phy { - status = "okay"; - phy-supply = <&vdd_5v>; -}; - -&usb1_phy { - status = "okay"; -}; - -&usb0 { - status = "okay"; -}; - -&usb1 { - status = "okay"; -}; diff --git a/arch/arm/dts/meson-gxbb-odroidc2.dts b/arch/arm/dts/meson-gxbb-odroidc2.dts deleted file mode 100644 index 201596247fd..00000000000 --- a/arch/arm/dts/meson-gxbb-odroidc2.dts +++ /dev/null @@ -1,418 +0,0 @@ -// SPDX-License-Identifier: (GPL-2.0+ OR MIT) -/* - * Copyright (c) 2016 Andreas Färber - * Copyright (c) 2016 BayLibre, Inc. - * Author: Kevin Hilman khilman@kernel.org - */ - -/dts-v1/; - -#include "meson-gxbb.dtsi" -#include <dt-bindings/gpio/gpio.h> -#include <dt-bindings/sound/meson-aiu.h> - -/ { - compatible = "hardkernel,odroid-c2", "amlogic,meson-gxbb"; - model = "Hardkernel ODROID-C2"; - - aliases { - serial0 = &uart_AO; - ethernet0 = ðmac; - }; - - chosen { - stdout-path = "serial0:115200n8"; - }; - - memory@0 { - device_type = "memory"; - reg = <0x0 0x0 0x0 0x80000000>; - }; - - usb_otg_pwr: regulator-usb-pwrs { - compatible = "regulator-fixed"; - - regulator-name = "USB_OTG_PWR"; - - regulator-min-microvolt = <5000000>; - regulator-max-microvolt = <5000000>; - - /* - * signal name from schematics: PWREN - */ - gpio = <&gpio_ao GPIOAO_5 GPIO_ACTIVE_HIGH>; - enable-active-high; - /* - * signal name from schematics: USB_POWER - */ - vin-supply = <&p5v0>; - }; - - leds { - compatible = "gpio-leds"; - led-blue { - label = "c2:blue:alive"; - gpios = <&gpio_ao GPIOAO_13 GPIO_ACTIVE_LOW>; - linux,default-trigger = "heartbeat"; - default-state = "off"; - }; - }; - - p5v0: regulator-p5v0 { - compatible = "regulator-fixed"; - - regulator-name = "P5V0"; - regulator-min-microvolt = <5000000>; - regulator-max-microvolt = <5000000>; - regulator-always-on; - }; - - hdmi_p5v0: regulator-hdmi_p5v0 { - compatible = "regulator-fixed"; - regulator-name = "HDMI_P5V0"; - regulator-min-microvolt = <5000000>; - regulator-max-microvolt = <5000000>; - /* AP2331SA-7 */ - vin-supply = <&p5v0>; - }; - - tflash_vdd: regulator-tflash_vdd { - compatible = "regulator-fixed"; - - regulator-name = "TFLASH_VDD"; - regulator-min-microvolt = <3300000>; - regulator-max-microvolt = <3300000>; - - /* - * signal name from schematics: TFLASH_VDD_EN - */ - gpio = <&gpio GPIOY_12 GPIO_ACTIVE_HIGH>; - enable-active-high; - /* U16 RT9179GB */ - vin-supply = <&vddio_ao3v3>; - }; - - tf_io: gpio-regulator-tf_io { - compatible = "regulator-gpio"; - - regulator-name = "TF_IO"; - regulator-min-microvolt = <1800000>; - regulator-max-microvolt = <3300000>; - - /* - * signal name from schematics: TF_3V3N_1V8_EN - */ - gpios = <&gpio_ao GPIOAO_3 GPIO_ACTIVE_HIGH>; - gpios-states = <0>; - - states = <3300000 0>, - <1800000 1>; - /* U12/U13 RT9179GB */ - vin-supply = <&vddio_ao3v3>; - }; - - vcc1v8: regulator-vcc1v8 { - compatible = "regulator-fixed"; - regulator-name = "VCC1V8"; - regulator-min-microvolt = <1800000>; - regulator-max-microvolt = <1800000>; - regulator-always-on; - /* U18 RT9179GB */ - vin-supply = <&vddio_ao3v3>; - }; - - vcc3v3: regulator-vcc3v3 { - compatible = "regulator-fixed"; - regulator-name = "VCC3V3"; - regulator-min-microvolt = <3300000>; - regulator-max-microvolt = <3300000>; - }; - - vddio_ao1v8: regulator-vddio-ao1v8 { - compatible = "regulator-fixed"; - regulator-name = "VDDIO_AO1V8"; - regulator-min-microvolt = <1800000>; - regulator-max-microvolt = <1800000>; - regulator-always-on; - /* U17 RT9179GB */ - vin-supply = <&p5v0>; - }; - - vddio_ao3v3: regulator-vddio-ao3v3 { - compatible = "regulator-fixed"; - regulator-name = "VDDIO_AO3V3"; - regulator-min-microvolt = <3300000>; - regulator-max-microvolt = <3300000>; - regulator-always-on; - /* U11 MP2161GJ-C499 */ - vin-supply = <&p5v0>; - }; - - ddr3_1v5: regulator-ddr3_1v5 { - compatible = "regulator-fixed"; - regulator-name = "DDR3_1V5"; - regulator-min-microvolt = <1500000>; - regulator-max-microvolt = <1500000>; - regulator-always-on; - /* U15 MP2161GJ-C499 */ - vin-supply = <&p5v0>; - }; - - emmc_pwrseq: emmc-pwrseq { - compatible = "mmc-pwrseq-emmc"; - reset-gpios = <&gpio BOOT_9 GPIO_ACTIVE_LOW>; - }; - - hdmi-connector { - compatible = "hdmi-connector"; - type = "a"; - - port { - hdmi_connector_in: endpoint { - remote-endpoint = <&hdmi_tx_tmds_out>; - }; - }; - }; - - sound { - compatible = "amlogic,gx-sound-card"; - model = "ODROID-C2"; - assigned-clocks = <&clkc CLKID_MPLL0>, - <&clkc CLKID_MPLL1>, - <&clkc CLKID_MPLL2>; - assigned-clock-parents = <0>, <0>, <0>; - assigned-clock-rates = <294912000>, - <270950400>, - <393216000>; - status = "okay"; - - dai-link-0 { - sound-dai = <&aiu AIU_CPU CPU_I2S_FIFO>; - }; - - dai-link-1 { - sound-dai = <&aiu AIU_CPU CPU_I2S_ENCODER>; - dai-format = "i2s"; - mclk-fs = <256>; - - codec-0 { - sound-dai = <&aiu AIU_HDMI CTRL_I2S>; - }; - }; - - dai-link-2 { - sound-dai = <&aiu AIU_HDMI CTRL_OUT>; - - codec-0 { - sound-dai = <&hdmi_tx>; - }; - }; - }; -}; - -&aiu { - status = "okay"; -}; - -&cec_AO { - status = "okay"; - pinctrl-0 = <&ao_cec_pins>; - pinctrl-names = "default"; - hdmi-phandle = <&hdmi_tx>; -}; - -ðmac { - status = "okay"; - pinctrl-0 = <ð_rgmii_pins>; - pinctrl-names = "default"; - phy-handle = <ð_phy0>; - phy-mode = "rgmii"; - - amlogic,tx-delay-ns = <2>; - - mdio { - compatible = "snps,dwmac-mdio"; - #address-cells = <1>; - #size-cells = <0>; - - eth_phy0: ethernet-phy@0 { - /* Realtek RTL8211F (0x001cc916) */ - reg = <0>; - - reset-assert-us = <10000>; - reset-deassert-us = <80000>; - reset-gpios = <&gpio GPIOZ_14 GPIO_ACTIVE_LOW>; - - interrupt-parent = <&gpio_intc>; - /* MAC_INTR on GPIOZ_15 */ - interrupts = <29 IRQ_TYPE_LEVEL_LOW>; - }; - }; -}; - -&gpio_ao { - /* - * WARNING: The USB Hub on the Odroid-C2 needs a reset signal - * to be turned high in order to be detected by the USB Controller - * This signal should be handled by a USB specific power sequence - * in order to reset the Hub when USB bus is powered down. - */ - hog-0 { - gpio-hog; - gpios = <GPIOAO_4 GPIO_ACTIVE_HIGH>; - output-high; - line-name = "usb-hub-reset"; - }; -}; - -&hdmi_tx { - status = "okay"; - pinctrl-0 = <&hdmi_hpd_pins>, <&hdmi_i2c_pins>; - pinctrl-names = "default"; - hdmi-supply = <&hdmi_p5v0>; -}; - -&hdmi_tx_tmds_port { - hdmi_tx_tmds_out: endpoint { - remote-endpoint = <&hdmi_connector_in>; - }; -}; - -&i2c_A { - status = "okay"; - pinctrl-0 = <&i2c_a_pins>; - pinctrl-names = "default"; -}; - -&ir { - status = "okay"; - pinctrl-0 = <&remote_input_ao_pins>; - pinctrl-names = "default"; - linux,rc-map-name = "rc-odroid"; -}; - -&gpio_ao { - gpio-line-names = "UART TX", "UART RX", "VCCK En", "TF 3V3/1V8 En", - "USB HUB nRESET", "USB OTG Power En", - "J7 Header Pin2", "IR In", "J7 Header Pin4", - "J7 Header Pin6", "J7 Header Pin5", "J7 Header Pin7", - "HDMI CEC", "SYS LED", - /* GPIO_TEST_N */ - ""; -}; - -&gpio { - gpio-line-names = /* Bank GPIOZ */ - "Eth MDIO", "Eth MDC", "Eth RGMII RX Clk", - "Eth RX DV", "Eth RX D0", "Eth RX D1", "Eth RX D2", - "Eth RX D3", "Eth RGMII TX Clk", "Eth TX En", - "Eth TX D0", "Eth TX D1", "Eth TX D2", "Eth TX D3", - "Eth PHY nRESET", "Eth PHY Intc", - /* Bank GPIOH */ - "HDMI HPD", "HDMI DDC SDA", "HDMI DDC SCL", "", - /* Bank BOOT */ - "eMMC D0", "eMMC D1", "eMMC D2", "eMMC D3", "eMMC D4", - "eMMC D5", "eMMC D6", "eMMC D7", "eMMC Clk", - "eMMC Reset", "eMMC CMD", - "", "", "", "", "", "", "", - /* Bank CARD */ - "SDCard D1", "SDCard D0", "SDCard CLK", "SDCard CMD", - "SDCard D3", "SDCard D2", "SDCard Det", - /* Bank GPIODV */ - "", "", "", "", "", "", "", "", "", "", "", "", "", - "", "", "", "", "", "", "", "", "", "", "", - "I2C A SDA", "I2C A SCK", "I2C B SDA", "I2C B SCK", - "PWM D", "PWM B", - /* Bank GPIOY */ - "Revision Bit0", "Revision Bit1", "", - "J2 Header Pin35", "", "", "", "J2 Header Pin36", - "J2 Header Pin31", "", "", "", "TF VDD En", - "J2 Header Pin32", "J2 Header Pin26", "", "", - /* Bank GPIOX */ - "J2 Header Pin29", "J2 Header Pin24", - "J2 Header Pin23", "J2 Header Pin22", - "J2 Header Pin21", "J2 Header Pin18", - "J2 Header Pin33", "J2 Header Pin19", - "J2 Header Pin16", "J2 Header Pin15", - "J2 Header Pin12", "J2 Header Pin13", - "J2 Header Pin8", "J2 Header Pin10", - "", "", "", "", "", - "J2 Header Pin11", "", "J2 Header Pin7", "", - /* Bank GPIOCLK */ - "", "", "", ""; -}; - -&saradc { - status = "okay"; - vref-supply = <&vcc1v8>; -}; - -&scpi_clocks { - status = "disabled"; -}; - -/* SD */ -&sd_emmc_b { - status = "okay"; - pinctrl-0 = <&sdcard_pins>; - pinctrl-1 = <&sdcard_clk_gate_pins>; - pinctrl-names = "default", "clk-gate"; - - bus-width = <4>; - cap-sd-highspeed; - sd-uhs-sdr12; - sd-uhs-sdr25; - sd-uhs-sdr50; - sd-uhs-ddr50; - max-frequency = <100000000>; - disable-wp; - - cd-gpios = <&gpio CARD_6 GPIO_ACTIVE_LOW>; - - vmmc-supply = <&tflash_vdd>; - vqmmc-supply = <&tf_io>; -}; - -/* eMMC */ -&sd_emmc_c { - status = "okay"; - pinctrl-0 = <&emmc_pins>, <&emmc_ds_pins>; - pinctrl-1 = <&emmc_clk_gate_pins>; - pinctrl-names = "default", "clk-gate"; - - bus-width = <8>; - max-frequency = <200000000>; - non-removable; - disable-wp; - cap-mmc-highspeed; - mmc-ddr-1_8v; - mmc-hs200-1_8v; - - mmc-pwrseq = <&emmc_pwrseq>; - vmmc-supply = <&vcc3v3>; - vqmmc-supply = <&vcc1v8>; -}; - -&uart_AO { - status = "okay"; - pinctrl-0 = <&uart_ao_a_pins>; - pinctrl-names = "default"; -}; - -&usb0_phy { - status = "disabled"; - phy-supply = <&usb_otg_pwr>; -}; - -&usb1_phy { - status = "okay"; - phy-supply = <&usb_otg_pwr>; -}; - -&usb0 { - status = "disabled"; -}; - -&usb1 { - status = "okay"; -}; diff --git a/arch/arm/dts/meson-gxbb-p200.dts b/arch/arm/dts/meson-gxbb-p200.dts deleted file mode 100644 index 3c93d1898b4..00000000000 --- a/arch/arm/dts/meson-gxbb-p200.dts +++ /dev/null @@ -1,100 +0,0 @@ -// SPDX-License-Identifier: (GPL-2.0+ OR MIT) -/* - * Copyright (c) 2016 Andreas Färber - * Copyright (c) 2016 BayLibre, Inc. - * Author: Kevin Hilman khilman@kernel.org - */ - -/dts-v1/; - -#include "meson-gxbb-p20x.dtsi" -#include <dt-bindings/input/input.h> - -/ { - compatible = "amlogic,p200", "amlogic,meson-gxbb"; - model = "Amlogic Meson GXBB P200 Development Board"; - - avdd18_usb_adc: regulator-avdd18_usb_adc { - compatible = "regulator-fixed"; - regulator-name = "AVDD18_USB_ADC"; - regulator-min-microvolt = <1800000>; - regulator-max-microvolt = <1800000>; - }; - - adc_keys { - compatible = "adc-keys"; - io-channels = <&saradc 0>; - io-channel-names = "buttons"; - keyup-threshold-microvolt = <1800000>; - - button-home { - label = "Home"; - linux,code = <KEY_HOME>; - press-threshold-microvolt = <900000>; /* 50% */ - }; - - button-esc { - label = "Esc"; - linux,code = <KEY_ESC>; - press-threshold-microvolt = <684000>; /* 38% */ - }; - - button-up { - label = "Volume Up"; - linux,code = <KEY_VOLUMEUP>; - press-threshold-microvolt = <468000>; /* 26% */ - }; - - button-down { - label = "Volume Down"; - linux,code = <KEY_VOLUMEDOWN>; - press-threshold-microvolt = <252000>; /* 14% */ - }; - - button-menu { - label = "Menu"; - linux,code = <KEY_MENU>; - press-threshold-microvolt = <0>; /* 0% */ - }; - }; -}; - -ðmac { - status = "okay"; - pinctrl-0 = <ð_rgmii_pins>; - pinctrl-names = "default"; - phy-handle = <ð_phy0>; - phy-mode = "rgmii"; - - amlogic,tx-delay-ns = <2>; - - mdio { - compatible = "snps,dwmac-mdio"; - #address-cells = <1>; - #size-cells = <0>; - - eth_phy0: ethernet-phy@3 { - /* Micrel KSZ9031 (0x00221620) */ - reg = <3>; - - reset-assert-us = <10000>; - reset-deassert-us = <30000>; - reset-gpios = <&gpio GPIOZ_14 GPIO_ACTIVE_LOW>; - - interrupt-parent = <&gpio_intc>; - /* MAC_INTR on GPIOZ_15 */ - interrupts = <29 IRQ_TYPE_LEVEL_LOW>; - }; - }; -}; - -&i2c_B { - status = "okay"; - pinctrl-0 = <&i2c_b_pins>; - pinctrl-names = "default"; -}; - -&saradc { - status = "okay"; - vref-supply = <&avdd18_usb_adc>; -}; diff --git a/arch/arm/dts/meson-gxbb-p201.dts b/arch/arm/dts/meson-gxbb-p201.dts deleted file mode 100644 index 150a82f3b2d..00000000000 --- a/arch/arm/dts/meson-gxbb-p201.dts +++ /dev/null @@ -1,26 +0,0 @@ -// SPDX-License-Identifier: (GPL-2.0+ OR MIT) -/* - * Copyright (c) 2016 Andreas Färber - * Copyright (c) 2016 BayLibre, Inc. - * Author: Kevin Hilman khilman@kernel.org - */ - -/dts-v1/; - -#include "meson-gxbb-p20x.dtsi" - -/ { - compatible = "amlogic,p201", "amlogic,meson-gxbb"; - model = "Amlogic Meson GXBB P201 Development Board"; -}; - -ðmac { - status = "okay"; - pinctrl-0 = <ð_rmii_pins>; - pinctrl-names = "default"; - phy-mode = "rmii"; - - snps,reset-gpio = <&gpio GPIOZ_14 0>; - snps,reset-delays-us = <0>, <10000>, <1000000>; - snps,reset-active-low; -}; diff --git a/arch/arm/dts/meson-gxbb-p20x.dtsi b/arch/arm/dts/meson-gxbb-p20x.dtsi deleted file mode 100644 index e803a466fe4..00000000000 --- a/arch/arm/dts/meson-gxbb-p20x.dtsi +++ /dev/null @@ -1,250 +0,0 @@ -// SPDX-License-Identifier: (GPL-2.0+ OR MIT) -/* - * Copyright (c) 2016 Andreas Färber - * Copyright (c) 2016 BayLibre, Inc. - * Author: Kevin Hilman khilman@kernel.org - */ - -#include "meson-gxbb.dtsi" - -/ { - aliases { - serial0 = &uart_AO; - ethernet0 = ðmac; - }; - - chosen { - stdout-path = "serial0:115200n8"; - }; - - memory@0 { - device_type = "memory"; - reg = <0x0 0x0 0x0 0x40000000>; - }; - - usb_pwr: regulator-usb-pwrs { - compatible = "regulator-fixed"; - - regulator-name = "USB_PWR"; - - regulator-min-microvolt = <5000000>; - regulator-max-microvolt = <5000000>; - - /* signal name in schematic: USB_PWR_EN */ - gpio = <&gpio GPIODV_24 GPIO_ACTIVE_HIGH>; - enable-active-high; - }; - - vddio_card: gpio-regulator { - compatible = "regulator-gpio"; - - regulator-name = "VDDIO_CARD"; - regulator-min-microvolt = <1800000>; - regulator-max-microvolt = <3300000>; - - gpios = <&gpio_ao GPIOAO_5 GPIO_ACTIVE_HIGH>; - gpios-states = <1>; - - /* Based on P200 schematics, signal CARD_1.8V/3.3V_CTR */ - states = <1800000 0>, - <3300000 1>; - - regulator-settling-time-up-us = <10000>; - regulator-settling-time-down-us = <150000>; - }; - - vddio_boot: regulator-vddio_boot { - compatible = "regulator-fixed"; - regulator-name = "VDDIO_BOOT"; - regulator-min-microvolt = <1800000>; - regulator-max-microvolt = <1800000>; - }; - - vddao_3v3: regulator-vddao_3v3 { - compatible = "regulator-fixed"; - regulator-name = "VDDAO_3V3"; - regulator-min-microvolt = <3300000>; - regulator-max-microvolt = <3300000>; - }; - - vcc_3v3: regulator-vcc_3v3 { - compatible = "regulator-fixed"; - regulator-name = "VCC_3V3"; - regulator-min-microvolt = <3300000>; - regulator-max-microvolt = <3300000>; - }; - - emmc_pwrseq: emmc-pwrseq { - compatible = "mmc-pwrseq-emmc"; - reset-gpios = <&gpio BOOT_9 GPIO_ACTIVE_LOW>; - }; - - wifi32k: wifi32k { - compatible = "pwm-clock"; - #clock-cells = <0>; - clock-frequency = <32768>; - pwms = <&pwm_ef 0 30518 0>; /* PWM_E at 32.768KHz */ - }; - - sdio_pwrseq: sdio-pwrseq { - compatible = "mmc-pwrseq-simple"; - reset-gpios = <&gpio GPIOX_6 GPIO_ACTIVE_LOW>; - clocks = <&wifi32k>; - clock-names = "ext_clock"; - }; - - cvbs_connector: cvbs-connector { - compatible = "composite-video-connector"; - - port { - cvbs_connector_in: endpoint { - remote-endpoint = <&cvbs_vdac_out>; - }; - }; - }; - - hdmi-connector { - compatible = "hdmi-connector"; - type = "a"; - - port { - hdmi_connector_in: endpoint { - remote-endpoint = <&hdmi_tx_tmds_out>; - }; - }; - }; -}; - -&cec_AO { - status = "okay"; - pinctrl-0 = <&ao_cec_pins>; - pinctrl-names = "default"; - hdmi-phandle = <&hdmi_tx>; -}; - -&cvbs_vdac_port { - cvbs_vdac_out: endpoint { - remote-endpoint = <&cvbs_connector_in>; - }; -}; - -&hdmi_tx { - status = "okay"; - pinctrl-0 = <&hdmi_hpd_pins>, <&hdmi_i2c_pins>; - pinctrl-names = "default"; -}; - -&hdmi_tx_tmds_port { - hdmi_tx_tmds_out: endpoint { - remote-endpoint = <&hdmi_connector_in>; - }; -}; - -&ir { - status = "okay"; - pinctrl-0 = <&remote_input_ao_pins>; - pinctrl-names = "default"; -}; - -&pwm_ef { - status = "okay"; - pinctrl-0 = <&pwm_e_pins>; - pinctrl-names = "default"; - clocks = <&clkc CLKID_FCLK_DIV4>; - clock-names = "clkin0"; -}; - -/* Wireless SDIO Module */ -&sd_emmc_a { - status = "okay"; - pinctrl-0 = <&sdio_pins>; - pinctrl-1 = <&sdio_clk_gate_pins>; - pinctrl-names = "default", "clk-gate"; - #address-cells = <1>; - #size-cells = <0>; - - bus-width = <4>; - cap-sd-highspeed; - max-frequency = <50000000>; - - non-removable; - disable-wp; - - /* WiFi firmware requires power to be kept while in suspend */ - keep-power-in-suspend; - - mmc-pwrseq = <&sdio_pwrseq>; - - vmmc-supply = <&vddao_3v3>; - vqmmc-supply = <&vddio_boot>; - - brcmf: wifi@1 { - reg = <1>; - compatible = "brcm,bcm4329-fmac"; - }; -}; - -/* SD card */ -&sd_emmc_b { - status = "okay"; - pinctrl-0 = <&sdcard_pins>; - pinctrl-1 = <&sdcard_clk_gate_pins>; - pinctrl-names = "default", "clk-gate"; - - bus-width = <4>; - cap-sd-highspeed; - sd-uhs-sdr12; - sd-uhs-sdr25; - sd-uhs-sdr50; - max-frequency = <100000000>; - disable-wp; - - cd-gpios = <&gpio CARD_6 GPIO_ACTIVE_LOW>; - - vmmc-supply = <&vddao_3v3>; - vqmmc-supply = <&vddio_card>; -}; - -/* eMMC */ -&sd_emmc_c { - status = "okay"; - pinctrl-0 = <&emmc_pins>, <&emmc_ds_pins>; - pinctrl-1 = <&emmc_clk_gate_pins>; - pinctrl-names = "default", "clk-gate"; - - bus-width = <8>; - cap-mmc-highspeed; - max-frequency = <200000000>; - non-removable; - disable-wp; - mmc-ddr-1_8v; - mmc-hs200-1_8v; - - mmc-pwrseq = <&emmc_pwrseq>; - vmmc-supply = <&vcc_3v3>; - vqmmc-supply = <&vddio_boot>; -}; - -/* This UART is brought out to the DB9 connector */ -&uart_AO { - status = "okay"; - pinctrl-0 = <&uart_ao_a_pins>; - pinctrl-names = "default"; -}; - -&usb0_phy { - status = "okay"; - phy-supply = <&usb_pwr>; -}; - -&usb1_phy { - status = "okay"; -}; - -&usb0 { - status = "okay"; -}; - -&usb1 { - status = "okay"; -}; diff --git a/arch/arm/dts/meson-gxbb-wetek-hub.dts b/arch/arm/dts/meson-gxbb-wetek-hub.dts deleted file mode 100644 index 58733017eda..00000000000 --- a/arch/arm/dts/meson-gxbb-wetek-hub.dts +++ /dev/null @@ -1,58 +0,0 @@ -// SPDX-License-Identifier: (GPL-2.0+ OR MIT) -/* - * Copyright (c) 2016 BayLibre, Inc. - * Author: Neil Armstrong narmstrong@baylibre.com - */ - -/dts-v1/; - -#include "meson-gxbb-wetek.dtsi" -#include <dt-bindings/sound/meson-aiu.h> - -/ { - compatible = "wetek,hub", "amlogic,meson-gxbb"; - model = "WeTek Hub"; - - sound { - compatible = "amlogic,gx-sound-card"; - model = "WETEK-HUB"; - assigned-clocks = <&clkc CLKID_MPLL0>, - <&clkc CLKID_MPLL1>, - <&clkc CLKID_MPLL2>; - assigned-clock-parents = <0>, <0>, <0>; - assigned-clock-rates = <294912000>, - <270950400>, - <393216000>; - status = "okay"; - - dai-link-0 { - sound-dai = <&aiu AIU_CPU CPU_I2S_FIFO>; - }; - - dai-link-1 { - sound-dai = <&aiu AIU_CPU CPU_I2S_ENCODER>; - dai-format = "i2s"; - mclk-fs = <256>; - - codec-0 { - sound-dai = <&aiu AIU_HDMI CTRL_I2S>; - }; - }; - - dai-link-2 { - sound-dai = <&aiu AIU_HDMI CTRL_OUT>; - - codec-0 { - sound-dai = <&hdmi_tx>; - }; - }; - }; -}; - -&aiu { - status = "okay"; -}; - -&ir { - linux,rc-map-name = "rc-wetek-hub"; -}; diff --git a/arch/arm/dts/meson-gxbb-wetek-play2.dts b/arch/arm/dts/meson-gxbb-wetek-play2.dts deleted file mode 100644 index 505ffcd8eb7..00000000000 --- a/arch/arm/dts/meson-gxbb-wetek-play2.dts +++ /dev/null @@ -1,119 +0,0 @@ -// SPDX-License-Identifier: (GPL-2.0+ OR MIT) -/* - * Copyright (c) 2016 BayLibre, Inc. - * Author: Neil Armstrong narmstrong@baylibre.com - */ - -/dts-v1/; - -#include "meson-gxbb-wetek.dtsi" -#include <dt-bindings/input/input.h> -#include <dt-bindings/sound/meson-aiu.h> - -/ { - compatible = "wetek,play2", "amlogic,meson-gxbb"; - model = "WeTek Play 2"; - - spdif_dit: audio-codec-0 { - #sound-dai-cells = <0>; - compatible = "linux,spdif-dit"; - status = "okay"; - sound-name-prefix = "DIT"; - }; - - leds { - led-wifi { - label = "wetek-play:wifi-status"; - gpios = <&gpio GPIODV_26 GPIO_ACTIVE_HIGH>; - default-state = "off"; - }; - - led-ethernet { - label = "wetek-play:ethernet-status"; - gpios = <&gpio GPIODV_27 GPIO_ACTIVE_HIGH>; - default-state = "off"; - }; - }; - - gpio-keys-polled { - compatible = "gpio-keys-polled"; - poll-interval = <100>; - - button { - label = "reset"; - linux,code = <KEY_RESTART>; - gpios = <&gpio_ao GPIOAO_3 GPIO_ACTIVE_LOW>; - }; - }; - - sound { - compatible = "amlogic,gx-sound-card"; - model = "WETEK-PLAY2"; - assigned-clocks = <&clkc CLKID_MPLL0>, - <&clkc CLKID_MPLL1>, - <&clkc CLKID_MPLL2>; - assigned-clock-parents = <0>, <0>, <0>; - assigned-clock-rates = <294912000>, - <270950400>, - <393216000>; - status = "okay"; - - dai-link-0 { - sound-dai = <&aiu AIU_CPU CPU_I2S_FIFO>; - }; - - dai-link-1 { - sound-dai = <&aiu AIU_CPU CPU_SPDIF_FIFO>; - }; - - dai-link-2 { - sound-dai = <&aiu AIU_CPU CPU_I2S_ENCODER>; - dai-format = "i2s"; - mclk-fs = <256>; - - codec-0 { - sound-dai = <&aiu AIU_HDMI CTRL_I2S>; - }; - }; - - dai-link-3 { - sound-dai = <&aiu AIU_CPU CPU_SPDIF_ENCODER>; - - codec-0 { - sound-dai = <&spdif_dit>; - }; - }; - - dai-link-4 { - sound-dai = <&aiu AIU_HDMI CTRL_OUT>; - - codec-0 { - sound-dai = <&hdmi_tx>; - }; - }; - }; -}; - -&aiu { - status = "okay"; - pinctrl-0 = <&spdif_out_y_pins>; - pinctrl-names = "default"; -}; - -&i2c_A { - status = "okay"; - pinctrl-0 = <&i2c_a_pins>; - pinctrl-names = "default"; -}; - -&usb1_phy { - status = "okay"; -}; - -&usb1 { - status = "okay"; -}; - -&ir { - linux,rc-map-name = "rc-wetek-play2"; -}; diff --git a/arch/arm/dts/meson-gxbb-wetek.dtsi b/arch/arm/dts/meson-gxbb-wetek.dtsi deleted file mode 100644 index 94dafb95530..00000000000 --- a/arch/arm/dts/meson-gxbb-wetek.dtsi +++ /dev/null @@ -1,292 +0,0 @@ -// SPDX-License-Identifier: (GPL-2.0+ OR MIT) -/* - * Copyright (c) 2016 Andreas Färber - * Copyright (c) 2016 BayLibre, Inc. - * Author: Kevin Hilman khilman@kernel.org - */ - -#include "meson-gxbb.dtsi" -#include <dt-bindings/gpio/gpio.h> -#include <dt-bindings/leds/common.h> - -/ { - aliases { - serial0 = &uart_AO; - ethernet0 = ðmac; - }; - - chosen { - stdout-path = "serial0:115200n8"; - }; - - memory@0 { - device_type = "memory"; - reg = <0x0 0x0 0x0 0x40000000>; - }; - - leds { - compatible = "gpio-leds"; - - led-power { - /* red in suspend or power-off */ - color = <LED_COLOR_ID_BLUE>; - function = LED_FUNCTION_POWER; - gpios = <&gpio_ao GPIOAO_13 GPIO_ACTIVE_HIGH>; - default-state = "on"; - panic-indicator; - }; - }; - - usb_pwr: regulator-usb-pwrs { - compatible = "regulator-fixed"; - - regulator-name = "USB_PWR"; - - regulator-min-microvolt = <5000000>; - regulator-max-microvolt = <5000000>; - - gpio = <&gpio GPIODV_24 GPIO_ACTIVE_HIGH>; - enable-active-high; - }; - - vddio_boot: regulator-vddio_boot { - compatible = "regulator-fixed"; - regulator-name = "VDDIO_BOOT"; - regulator-min-microvolt = <1800000>; - regulator-max-microvolt = <1800000>; - }; - - vddao_3v3: regulator-vddao_3v3 { - compatible = "regulator-fixed"; - regulator-name = "VDDAO_3V3"; - regulator-min-microvolt = <3300000>; - regulator-max-microvolt = <3300000>; - }; - - vddio_ao18: regulator-vddio_ao18 { - compatible = "regulator-fixed"; - regulator-name = "VDDIO_AO18"; - regulator-min-microvolt = <1800000>; - regulator-max-microvolt = <1800000>; - regulator-always-on; - }; - - vcc_3v3: regulator-vcc_3v3 { - compatible = "regulator-fixed"; - regulator-name = "VCC_3V3"; - regulator-min-microvolt = <3300000>; - regulator-max-microvolt = <3300000>; - }; - - emmc_pwrseq: emmc-pwrseq { - compatible = "mmc-pwrseq-emmc"; - reset-gpios = <&gpio BOOT_9 GPIO_ACTIVE_LOW>; - }; - - wifi32k: wifi32k { - compatible = "pwm-clock"; - #clock-cells = <0>; - clock-frequency = <32768>; - pwms = <&pwm_ef 0 30518 0>; /* PWM_E at 32.768KHz */ - }; - - sdio_pwrseq: sdio-pwrseq { - compatible = "mmc-pwrseq-simple"; - reset-gpios = <&gpio GPIOX_6 GPIO_ACTIVE_LOW>; - clocks = <&wifi32k>; - clock-names = "ext_clock"; - }; - - cvbs-connector { - compatible = "composite-video-connector"; - - port { - cvbs_connector_in: endpoint { - remote-endpoint = <&cvbs_vdac_out>; - }; - }; - }; - - hdmi-connector { - compatible = "hdmi-connector"; - type = "a"; - - port { - hdmi_connector_in: endpoint { - remote-endpoint = <&hdmi_tx_tmds_out>; - }; - }; - }; -}; - -&cec_AO { - status = "okay"; - pinctrl-0 = <&ao_cec_pins>; - pinctrl-names = "default"; - hdmi-phandle = <&hdmi_tx>; -}; - -&cvbs_vdac_port { - cvbs_vdac_out: endpoint { - remote-endpoint = <&cvbs_connector_in>; - }; -}; - -ðmac { - status = "okay"; - pinctrl-0 = <ð_rgmii_pins>; - pinctrl-names = "default"; - - phy-handle = <ð_phy0>; - phy-mode = "rgmii"; - - amlogic,tx-delay-ns = <2>; - - mdio { - compatible = "snps,dwmac-mdio"; - #address-cells = <1>; - #size-cells = <0>; - - eth_phy0: ethernet-phy@0 { - /* Realtek RTL8211F (0x001cc916) */ - reg = <0>; - - reset-assert-us = <10000>; - reset-deassert-us = <80000>; - reset-gpios = <&gpio GPIOZ_14 GPIO_ACTIVE_LOW>; - - interrupt-parent = <&gpio_intc>; - /* MAC_INTR on GPIOZ_15 */ - interrupts = <29 IRQ_TYPE_LEVEL_LOW>; - }; - }; -}; - -&hdmi_tx { - status = "okay"; - pinctrl-0 = <&hdmi_hpd_pins>, <&hdmi_i2c_pins>; - pinctrl-names = "default"; - hdmi-supply = <&vddio_ao18>; -}; - -&hdmi_tx_tmds_port { - hdmi_tx_tmds_out: endpoint { - remote-endpoint = <&hdmi_connector_in>; - }; -}; - -&ir { - status = "okay"; - pinctrl-0 = <&remote_input_ao_pins>; - pinctrl-names = "default"; -}; - -&pwm_ef { - status = "okay"; - pinctrl-0 = <&pwm_e_pins>; - pinctrl-names = "default"; - clocks = <&clkc CLKID_FCLK_DIV4>; - clock-names = "clkin0"; -}; - -&saradc { - status = "okay"; - vref-supply = <&vddio_ao18>; -}; - -/* Wireless SDIO Module */ -&sd_emmc_a { - status = "okay"; - pinctrl-0 = <&sdio_pins>; - pinctrl-1 = <&sdio_clk_gate_pins>; - pinctrl-names = "default", "clk-gate"; - #address-cells = <1>; - #size-cells = <0>; - - bus-width = <4>; - cap-sd-highspeed; - max-frequency = <50000000>; - - non-removable; - disable-wp; - - /* WiFi firmware requires power to be kept while in suspend */ - keep-power-in-suspend; - - mmc-pwrseq = <&sdio_pwrseq>; - - vmmc-supply = <&vddao_3v3>; - vqmmc-supply = <&vddio_boot>; - - brcmf: wifi@1 { - reg = <1>; - compatible = "brcm,bcm4329-fmac"; - }; -}; - -/* SD card */ -&sd_emmc_b { - status = "okay"; - pinctrl-0 = <&sdcard_pins>; - pinctrl-1 = <&sdcard_clk_gate_pins>; - pinctrl-names = "default", "clk-gate"; - - bus-width = <4>; - cap-sd-highspeed; - max-frequency = <50000000>; - disable-wp; - - cd-gpios = <&gpio CARD_6 GPIO_ACTIVE_LOW>; - - vmmc-supply = <&vddao_3v3>; - vqmmc-supply = <&vcc_3v3>; -}; - -/* eMMC */ -&sd_emmc_c { - status = "okay"; - pinctrl-0 = <&emmc_pins>, <&emmc_ds_pins>; - pinctrl-1 = <&emmc_clk_gate_pins>; - pinctrl-names = "default", "clk-gate"; - - bus-width = <8>; - cap-mmc-highspeed; - max-frequency = <200000000>; - non-removable; - disable-wp; - mmc-ddr-1_8v; - mmc-hs200-1_8v; - - mmc-pwrseq = <&emmc_pwrseq>; - vmmc-supply = <&vcc_3v3>; - vqmmc-supply = <&vddio_boot>; -}; - -/* This is connected to the Bluetooth module: */ -&uart_A { - status = "okay"; - pinctrl-0 = <&uart_a_pins>, <&uart_a_cts_rts_pins>; - pinctrl-names = "default"; - uart-has-rtscts; - - bluetooth { - compatible = "brcm,bcm43438-bt"; - shutdown-gpios = <&gpio GPIOX_20 GPIO_ACTIVE_HIGH>; - }; -}; - -/* This UART is brought out to the DB9 connector */ -&uart_AO { - status = "okay"; - pinctrl-0 = <&uart_ao_a_pins>; - pinctrl-names = "default"; -}; - -&usb0_phy { - status = "okay"; - phy-supply = <&usb_pwr>; -}; - -&usb0 { - status = "okay"; -}; diff --git a/arch/arm/dts/meson-gxbb.dtsi b/arch/arm/dts/meson-gxbb.dtsi deleted file mode 100644 index 7c029f552a2..00000000000 --- a/arch/arm/dts/meson-gxbb.dtsi +++ /dev/null @@ -1,856 +0,0 @@ -// SPDX-License-Identifier: (GPL-2.0+ OR MIT) -/* - * Copyright (c) 2016 Andreas Färber - */ - -#include "meson-gx.dtsi" -#include "meson-gx-mali450.dtsi" -#include <dt-bindings/gpio/meson-gxbb-gpio.h> -#include <dt-bindings/reset/amlogic,meson-gxbb-reset.h> -#include <dt-bindings/clock/gxbb-clkc.h> -#include <dt-bindings/clock/gxbb-aoclkc.h> -#include <dt-bindings/reset/gxbb-aoclkc.h> - -/ { - compatible = "amlogic,meson-gxbb"; - - soc { - usb0_phy: phy@c0000000 { - compatible = "amlogic,meson-gxbb-usb2-phy"; - #phy-cells = <0>; - reg = <0x0 0xc0000000 0x0 0x20>; - resets = <&reset RESET_USB_OTG>; - clocks = <&clkc CLKID_USB>, <&clkc CLKID_USB0>; - clock-names = "usb_general", "usb"; - status = "disabled"; - }; - - usb1_phy: phy@c0000020 { - compatible = "amlogic,meson-gxbb-usb2-phy"; - #phy-cells = <0>; - reg = <0x0 0xc0000020 0x0 0x20>; - resets = <&reset RESET_USB_OTG>; - clocks = <&clkc CLKID_USB>, <&clkc CLKID_USB1>; - clock-names = "usb_general", "usb"; - status = "disabled"; - }; - - usb0: usb@c9000000 { - compatible = "amlogic,meson-gxbb-usb", "snps,dwc2"; - reg = <0x0 0xc9000000 0x0 0x40000>; - interrupts = <GIC_SPI 30 IRQ_TYPE_LEVEL_HIGH>; - clocks = <&clkc CLKID_USB0_DDR_BRIDGE>; - clock-names = "otg"; - phys = <&usb0_phy>; - phy-names = "usb2-phy"; - dr_mode = "host"; - status = "disabled"; - }; - - usb1: usb@c9100000 { - compatible = "amlogic,meson-gxbb-usb", "snps,dwc2"; - reg = <0x0 0xc9100000 0x0 0x40000>; - interrupts = <GIC_SPI 31 IRQ_TYPE_LEVEL_HIGH>; - clocks = <&clkc CLKID_USB1_DDR_BRIDGE>; - clock-names = "otg"; - phys = <&usb1_phy>; - phy-names = "usb2-phy"; - dr_mode = "host"; - status = "disabled"; - }; - }; -}; - -&aiu { - compatible = "amlogic,aiu-gxbb", "amlogic,aiu"; - clocks = <&clkc CLKID_AIU_GLUE>, - <&clkc CLKID_I2S_OUT>, - <&clkc CLKID_AOCLK_GATE>, - <&clkc CLKID_CTS_AMCLK>, - <&clkc CLKID_MIXER_IFACE>, - <&clkc CLKID_IEC958>, - <&clkc CLKID_IEC958_GATE>, - <&clkc CLKID_CTS_MCLK_I958>, - <&clkc CLKID_CTS_I958>; - clock-names = "pclk", - "i2s_pclk", - "i2s_aoclk", - "i2s_mclk", - "i2s_mixer", - "spdif_pclk", - "spdif_aoclk", - "spdif_mclk", - "spdif_mclk_sel"; - resets = <&reset RESET_AIU>; -}; - -&aobus { - pinctrl_aobus: pinctrl@14 { - compatible = "amlogic,meson-gxbb-aobus-pinctrl"; - #address-cells = <2>; - #size-cells = <2>; - ranges; - - gpio_ao: bank@14 { - reg = <0x0 0x00014 0x0 0x8>, - <0x0 0x0002c 0x0 0x4>, - <0x0 0x00024 0x0 0x8>; - reg-names = "mux", "pull", "gpio"; - gpio-controller; - #gpio-cells = <2>; - gpio-ranges = <&pinctrl_aobus 0 0 14>; - }; - - uart_ao_a_pins: uart_ao_a { - mux { - groups = "uart_tx_ao_a", "uart_rx_ao_a"; - function = "uart_ao"; - bias-disable; - }; - }; - - uart_ao_a_cts_rts_pins: uart_ao_a_cts_rts { - mux { - groups = "uart_cts_ao_a", - "uart_rts_ao_a"; - function = "uart_ao"; - bias-disable; - }; - }; - - uart_ao_b_pins: uart_ao_b { - mux { - groups = "uart_tx_ao_b", "uart_rx_ao_b"; - function = "uart_ao_b"; - bias-disable; - }; - }; - - uart_ao_b_cts_rts_pins: uart_ao_b_cts_rts { - mux { - groups = "uart_cts_ao_b", - "uart_rts_ao_b"; - function = "uart_ao_b"; - bias-disable; - }; - }; - - remote_input_ao_pins: remote_input_ao { - mux { - groups = "remote_input_ao"; - function = "remote_input_ao"; - bias-disable; - }; - }; - - i2c_ao_pins: i2c_ao { - mux { - groups = "i2c_sck_ao", - "i2c_sda_ao"; - function = "i2c_ao"; - bias-disable; - }; - }; - - pwm_ao_a_3_pins: pwm_ao_a_3 { - mux { - groups = "pwm_ao_a_3"; - function = "pwm_ao_a_3"; - bias-disable; - }; - }; - - pwm_ao_a_6_pins: pwm_ao_a_6 { - mux { - groups = "pwm_ao_a_6"; - function = "pwm_ao_a_6"; - bias-disable; - }; - }; - - pwm_ao_a_12_pins: pwm_ao_a_12 { - mux { - groups = "pwm_ao_a_12"; - function = "pwm_ao_a_12"; - bias-disable; - }; - }; - - pwm_ao_b_pins: pwm_ao_b { - mux { - groups = "pwm_ao_b"; - function = "pwm_ao_b"; - bias-disable; - }; - }; - - i2s_am_clk_pins: i2s_am_clk { - mux { - groups = "i2s_am_clk"; - function = "i2s_out_ao"; - bias-disable; - }; - }; - - i2s_out_ao_clk_pins: i2s_out_ao_clk { - mux { - groups = "i2s_out_ao_clk"; - function = "i2s_out_ao"; - bias-disable; - }; - }; - - i2s_out_lr_clk_pins: i2s_out_lr_clk { - mux { - groups = "i2s_out_lr_clk"; - function = "i2s_out_ao"; - bias-disable; - }; - }; - - i2s_out_ch01_ao_pins: i2s_out_ch01_ao { - mux { - groups = "i2s_out_ch01_ao"; - function = "i2s_out_ao"; - bias-disable; - }; - }; - - i2s_out_ch23_ao_pins: i2s_out_ch23_ao { - mux { - groups = "i2s_out_ch23_ao"; - function = "i2s_out_ao"; - bias-disable; - }; - }; - - i2s_out_ch45_ao_pins: i2s_out_ch45_ao { - mux { - groups = "i2s_out_ch45_ao"; - function = "i2s_out_ao"; - bias-disable; - }; - }; - - spdif_out_ao_6_pins: spdif_out_ao_6 { - mux { - groups = "spdif_out_ao_6"; - function = "spdif_out_ao"; - }; - }; - - spdif_out_ao_13_pins: spdif_out_ao_13 { - mux { - groups = "spdif_out_ao_13"; - function = "spdif_out_ao"; - bias-disable; - }; - }; - - ao_cec_pins: ao_cec { - mux { - groups = "ao_cec"; - function = "cec_ao"; - bias-disable; - }; - }; - - ee_cec_pins: ee_cec { - mux { - groups = "ee_cec"; - function = "cec_ao"; - bias-disable; - }; - }; - }; -}; - -&cbus { - spifc: spi@8c80 { - compatible = "amlogic,meson-gxbb-spifc"; - reg = <0x0 0x08c80 0x0 0x80>; - #address-cells = <1>; - #size-cells = <0>; - clocks = <&clkc CLKID_SPI>; - status = "disabled"; - }; -}; - -&cec_AO { - clocks = <&clkc_AO CLKID_AO_CEC_32K>; - clock-names = "core"; -}; - -&clkc_AO { - compatible = "amlogic,meson-gxbb-aoclkc", "amlogic,meson-gx-aoclkc"; - clocks = <&xtal>, <&clkc CLKID_CLK81>; - clock-names = "xtal", "mpeg-clk"; -}; - -&efuse { - clocks = <&clkc CLKID_EFUSE>; -}; - -ðmac { - clocks = <&clkc CLKID_ETH>, - <&clkc CLKID_FCLK_DIV2>, - <&clkc CLKID_MPLL2>, - <&clkc CLKID_FCLK_DIV2>; - clock-names = "stmmaceth", "clkin0", "clkin1", "timing-adjustment"; -}; - -&gpio_intc { - compatible = "amlogic,meson-gpio-intc", - "amlogic,meson-gxbb-gpio-intc"; - status = "okay"; -}; - -&hdmi_tx { - compatible = "amlogic,meson-gxbb-dw-hdmi", "amlogic,meson-gx-dw-hdmi"; - resets = <&reset RESET_HDMITX_CAPB3>, - <&reset RESET_HDMI_SYSTEM_RESET>, - <&reset RESET_HDMI_TX>; - reset-names = "hdmitx_apb", "hdmitx", "hdmitx_phy"; - clocks = <&clkc CLKID_HDMI_PCLK>, - <&clkc CLKID_CLK81>, - <&clkc CLKID_GCLK_VENCI_INT0>; - clock-names = "isfr", "iahb", "venci"; -}; - -&sysctrl { - clkc: clock-controller { - compatible = "amlogic,gxbb-clkc"; - #clock-cells = <1>; - clocks = <&xtal>; - clock-names = "xtal"; - }; -}; - -&hwrng { - clocks = <&clkc CLKID_RNG0>; - clock-names = "core"; -}; - -&i2c_A { - clocks = <&clkc CLKID_I2C>; -}; - -&i2c_AO { - clocks = <&clkc CLKID_AO_I2C>; -}; - -&i2c_B { - clocks = <&clkc CLKID_I2C>; -}; - -&i2c_C { - clocks = <&clkc CLKID_I2C>; -}; - -&mali { - compatible = "amlogic,meson-gxbb-mali", "arm,mali-450"; - - clocks = <&clkc CLKID_CLK81>, <&clkc CLKID_MALI>; - clock-names = "bus", "core"; - - assigned-clocks = <&clkc CLKID_GP0_PLL>; - assigned-clock-rates = <744000000>; -}; - -&periphs { - pinctrl_periphs: pinctrl@4b0 { - compatible = "amlogic,meson-gxbb-periphs-pinctrl"; - #address-cells = <2>; - #size-cells = <2>; - ranges; - - gpio: bank@4b0 { - reg = <0x0 0x004b0 0x0 0x28>, - <0x0 0x004e8 0x0 0x14>, - <0x0 0x00520 0x0 0x14>, - <0x0 0x00430 0x0 0x40>; - reg-names = "mux", "pull", "pull-enable", "gpio"; - gpio-controller; - #gpio-cells = <2>; - gpio-ranges = <&pinctrl_periphs 0 0 119>; - }; - - emmc_pins: emmc { - mux-0 { - groups = "emmc_nand_d07", - "emmc_cmd"; - function = "emmc"; - bias-pull-up; - }; - - mux-1 { - groups = "emmc_clk"; - function = "emmc"; - bias-disable; - }; - }; - - emmc_ds_pins: emmc-ds { - mux { - groups = "emmc_ds"; - function = "emmc"; - bias-pull-down; - }; - }; - - emmc_clk_gate_pins: emmc_clk_gate { - mux { - groups = "BOOT_8"; - function = "gpio_periphs"; - bias-pull-down; - }; - }; - - nor_pins: nor { - mux { - groups = "nor_d", - "nor_q", - "nor_c", - "nor_cs"; - function = "nor"; - bias-disable; - }; - }; - - spi_pins: spi-pins { - mux { - groups = "spi_miso", - "spi_mosi", - "spi_sclk"; - function = "spi"; - bias-disable; - }; - }; - - spi_ss0_pins: spi-ss0 { - mux { - groups = "spi_ss0"; - function = "spi"; - bias-disable; - }; - }; - - sdcard_pins: sdcard { - mux-0 { - groups = "sdcard_d0", - "sdcard_d1", - "sdcard_d2", - "sdcard_d3", - "sdcard_cmd"; - function = "sdcard"; - bias-pull-up; - }; - - mux-1 { - groups = "sdcard_clk"; - function = "sdcard"; - bias-disable; - }; - }; - - sdcard_clk_gate_pins: sdcard_clk_gate { - mux { - groups = "CARD_2"; - function = "gpio_periphs"; - bias-pull-down; - }; - }; - - sdio_pins: sdio { - mux-0 { - groups = "sdio_d0", - "sdio_d1", - "sdio_d2", - "sdio_d3", - "sdio_cmd"; - function = "sdio"; - bias-pull-up; - }; - - mux-1 { - groups = "sdio_clk"; - function = "sdio"; - bias-disable; - }; - }; - - sdio_clk_gate_pins: sdio_clk_gate { - mux { - groups = "GPIOX_4"; - function = "gpio_periphs"; - bias-pull-down; - }; - }; - - sdio_irq_pins: sdio_irq { - mux { - groups = "sdio_irq"; - function = "sdio"; - bias-disable; - }; - }; - - uart_a_pins: uart_a { - mux { - groups = "uart_tx_a", - "uart_rx_a"; - function = "uart_a"; - bias-disable; - }; - }; - - uart_a_cts_rts_pins: uart_a_cts_rts { - mux { - groups = "uart_cts_a", - "uart_rts_a"; - function = "uart_a"; - bias-disable; - }; - }; - - uart_b_pins: uart_b { - mux { - groups = "uart_tx_b", - "uart_rx_b"; - function = "uart_b"; - bias-disable; - }; - }; - - uart_b_cts_rts_pins: uart_b_cts_rts { - mux { - groups = "uart_cts_b", - "uart_rts_b"; - function = "uart_b"; - bias-disable; - }; - }; - - uart_c_pins: uart_c { - mux { - groups = "uart_tx_c", - "uart_rx_c"; - function = "uart_c"; - bias-disable; - }; - }; - - uart_c_cts_rts_pins: uart_c_cts_rts { - mux { - groups = "uart_cts_c", - "uart_rts_c"; - function = "uart_c"; - bias-disable; - }; - }; - - i2c_a_pins: i2c_a { - mux { - groups = "i2c_sck_a", - "i2c_sda_a"; - function = "i2c_a"; - bias-disable; - }; - }; - - i2c_b_pins: i2c_b { - mux { - groups = "i2c_sck_b", - "i2c_sda_b"; - function = "i2c_b"; - bias-disable; - }; - }; - - i2c_c_pins: i2c_c { - mux { - groups = "i2c_sck_c", - "i2c_sda_c"; - function = "i2c_c"; - bias-disable; - }; - }; - - eth_rgmii_pins: eth-rgmii { - mux { - groups = "eth_mdio", - "eth_mdc", - "eth_clk_rx_clk", - "eth_rx_dv", - "eth_rxd0", - "eth_rxd1", - "eth_rxd2", - "eth_rxd3", - "eth_rgmii_tx_clk", - "eth_tx_en", - "eth_txd0", - "eth_txd1", - "eth_txd2", - "eth_txd3"; - function = "eth"; - bias-disable; - }; - }; - - eth_rmii_pins: eth-rmii { - mux { - groups = "eth_mdio", - "eth_mdc", - "eth_clk_rx_clk", - "eth_rx_dv", - "eth_rxd0", - "eth_rxd1", - "eth_tx_en", - "eth_txd0", - "eth_txd1"; - function = "eth"; - bias-disable; - }; - }; - - pwm_a_x_pins: pwm_a_x { - mux { - groups = "pwm_a_x"; - function = "pwm_a_x"; - bias-disable; - }; - }; - - pwm_a_y_pins: pwm_a_y { - mux { - groups = "pwm_a_y"; - function = "pwm_a_y"; - bias-disable; - }; - }; - - pwm_b_pins: pwm_b { - mux { - groups = "pwm_b"; - function = "pwm_b"; - bias-disable; - }; - }; - - pwm_d_pins: pwm_d { - mux { - groups = "pwm_d"; - function = "pwm_d"; - bias-disable; - }; - }; - - pwm_e_pins: pwm_e { - mux { - groups = "pwm_e"; - function = "pwm_e"; - bias-disable; - }; - }; - - pwm_f_x_pins: pwm_f_x { - mux { - groups = "pwm_f_x"; - function = "pwm_f_x"; - bias-disable; - }; - }; - - pwm_f_y_pins: pwm_f_y { - mux { - groups = "pwm_f_y"; - function = "pwm_f_y"; - bias-disable; - }; - }; - - hdmi_hpd_pins: hdmi_hpd { - mux { - groups = "hdmi_hpd"; - function = "hdmi_hpd"; - bias-disable; - }; - }; - - hdmi_i2c_pins: hdmi_i2c { - mux { - groups = "hdmi_sda", "hdmi_scl"; - function = "hdmi_i2c"; - bias-disable; - }; - }; - - i2sout_ch23_y_pins: i2sout_ch23_y { - mux { - groups = "i2sout_ch23_y"; - function = "i2s_out"; - bias-disable; - }; - }; - - i2sout_ch45_y_pins: i2sout_ch45_y { - mux { - groups = "i2sout_ch45_y"; - function = "i2s_out"; - bias-disable; - }; - }; - - i2sout_ch67_y_pins: i2sout_ch67_y { - mux { - groups = "i2sout_ch67_y"; - function = "i2s_out"; - bias-disable; - }; - }; - - spdif_out_y_pins: spdif_out_y { - mux { - groups = "spdif_out_y"; - function = "spdif_out"; - bias-disable; - }; - }; - }; -}; - -&pwrc { - resets = <&reset RESET_VIU>, - <&reset RESET_VENC>, - <&reset RESET_VCBUS>, - <&reset RESET_BT656>, - <&reset RESET_DVIN_RESET>, - <&reset RESET_RDMA>, - <&reset RESET_VENCI>, - <&reset RESET_VENCP>, - <&reset RESET_VDAC>, - <&reset RESET_VDI6>, - <&reset RESET_VENCL>, - <&reset RESET_VID_LOCK>; - reset-names = "viu", "venc", "vcbus", "bt656", - "dvin", "rdma", "venci", "vencp", - "vdac", "vdi6", "vencl", "vid_lock"; - clocks = <&clkc CLKID_VPU>, - <&clkc CLKID_VAPB>; - clock-names = "vpu", "vapb"; - /* - * VPU clocking is provided by two identical clock paths - * VPU_0 and VPU_1 muxed to a single clock by a glitch - * free mux to safely change frequency while running. - * Same for VAPB but with a final gate after the glitch free mux. - */ - assigned-clocks = <&clkc CLKID_VPU_0_SEL>, - <&clkc CLKID_VPU_0>, - <&clkc CLKID_VPU>, /* Glitch free mux */ - <&clkc CLKID_VAPB_0_SEL>, - <&clkc CLKID_VAPB_0>, - <&clkc CLKID_VAPB_SEL>; /* Glitch free mux */ - assigned-clock-parents = <&clkc CLKID_FCLK_DIV3>, - <0>, /* Do Nothing */ - <&clkc CLKID_VPU_0>, - <&clkc CLKID_FCLK_DIV4>, - <0>, /* Do Nothing */ - <&clkc CLKID_VAPB_0>; - assigned-clock-rates = <0>, /* Do Nothing */ - <666666666>, - <0>, /* Do Nothing */ - <0>, /* Do Nothing */ - <250000000>, - <0>; /* Do Nothing */ -}; - -&saradc { - compatible = "amlogic,meson-gxbb-saradc", "amlogic,meson-saradc"; - clocks = <&xtal>, - <&clkc CLKID_SAR_ADC>, - <&clkc CLKID_SAR_ADC_CLK>, - <&clkc CLKID_SAR_ADC_SEL>; - clock-names = "clkin", "core", "adc_clk", "adc_sel"; -}; - -&sd_emmc_a { - clocks = <&clkc CLKID_SD_EMMC_A>, - <&clkc CLKID_SD_EMMC_A_CLK0>, - <&clkc CLKID_FCLK_DIV2>; - clock-names = "core", "clkin0", "clkin1"; - resets = <&reset RESET_SD_EMMC_A>; -}; - -&sd_emmc_b { - clocks = <&clkc CLKID_SD_EMMC_B>, - <&clkc CLKID_SD_EMMC_B_CLK0>, - <&clkc CLKID_FCLK_DIV2>; - clock-names = "core", "clkin0", "clkin1"; - resets = <&reset RESET_SD_EMMC_B>; -}; - -&sd_emmc_c { - clocks = <&clkc CLKID_SD_EMMC_C>, - <&clkc CLKID_SD_EMMC_C_CLK0>, - <&clkc CLKID_FCLK_DIV2>; - clock-names = "core", "clkin0", "clkin1"; - resets = <&reset RESET_SD_EMMC_C>; -}; - -&simplefb_hdmi { - clocks = <&clkc CLKID_HDMI_PCLK>, - <&clkc CLKID_CLK81>, - <&clkc CLKID_GCLK_VENCI_INT0>; -}; - -&spicc { - clocks = <&clkc CLKID_SPICC>; - clock-names = "core"; - resets = <&reset RESET_PERIPHS_SPICC>; - num-cs = <1>; -}; - -&spifc { - clocks = <&clkc CLKID_SPI>; -}; - -&uart_A { - clocks = <&xtal>, <&clkc CLKID_UART0>, <&xtal>; - clock-names = "xtal", "pclk", "baud"; -}; - -&uart_AO { - clocks = <&xtal>, <&clkc_AO CLKID_AO_UART1>, <&xtal>; - clock-names = "xtal", "pclk", "baud"; -}; - -&uart_AO_B { - clocks = <&xtal>, <&clkc_AO CLKID_AO_UART2>, <&xtal>; - clock-names = "xtal", "pclk", "baud"; -}; - -&uart_B { - clocks = <&xtal>, <&clkc CLKID_UART1>, <&xtal>; - clock-names = "xtal", "pclk", "baud"; -}; - -&uart_C { - clocks = <&xtal>, <&clkc CLKID_UART2>, <&xtal>; - clock-names = "xtal", "pclk", "baud"; -}; - -&vpu { - compatible = "amlogic,meson-gxbb-vpu", "amlogic,meson-gx-vpu"; - power-domains = <&pwrc PWRC_GXBB_VPU_ID>; -}; - -&vdec { - compatible = "amlogic,gxbb-vdec", "amlogic,gx-vdec"; - clocks = <&clkc CLKID_DOS_PARSER>, - <&clkc CLKID_DOS>, - <&clkc CLKID_VDEC_1>, - <&clkc CLKID_VDEC_HEVC>; - clock-names = "dos_parser", "dos", "vdec_1", "vdec_hevc"; - resets = <&reset RESET_PARSER>; - reset-names = "esparser"; -};
Hi,
On 14/12/2023 14:50, Sumit Garg wrote:
Prerquisite
s/Prerquisite/Prerequisite/
This patch series requires devicetree-rebasing git repo to be added as a subtree to the main U-boot repo via:
$ git subtree add --prefix devicetree-rebasing \ git://git.kernel.org/pub/scm/linux/kernel/git/devicetree/devicetree-rebasing.git \ v6.6-dts --squash
So I think the big question is: when should the subtree be updated ?
Because as we discussed in the previous GH pull request, if a bindings changes was made in the upstream Linux DT, then the subtree update should wait until the u-boot support is merged before updating. This could cause a lot of frustration.
And this could cause a lot of regressions, even more if both Linux and U-boot are not maintained by the same people.
Neil
Background
This effort started while I was reviewing patch series corresponding to Qcom platforms [1] which was about to import modified devicetree source files from Linux kernel. I suppose keeping devicetree files sync with Linux kernel without any DT bindings schema validation has been a pain for U-boot SoC/platform maintainers. There has been past discussions about a single DT repo but that hasn't come up and Linux kernel remained the place where DT source files as well as bindings are placed and maintained.
However, Linux kernel DT maintainers proposed [2] for U-boot to rather use devicetree-rebasing repo [3] which is a forked copy from Linux kernel for DT source files as well as bindings. It is tagged at every Linux kernel major release or intermideate release candidates. So here I have tried to reuse that to bring DT bingings compliance as well as a standard way to maintain a regular sync of DT source files with Linux kernel.
In order to maintain devicetree files sync, U-boot will maintains a Git subtree for devicetee-rebasing repo as `devicetee-rebasing/` sub-directory. It will be regularly updated with every new kernel major release via subtree pull as follows::
$ git subtree pull --prefix devicetree-rebasing \ git://git.kernel.org/pub/scm/linux/kernel/git/devicetree/devicetree-rebasing.git \ <release-tag> --squash
The RFC/prototype for this series has been discussed with Linux DT maintainers as well as U-boot maintainers here [4]. Now we would like to reach out to wider U-boot community to seek feedback.
[1] https://lore.kernel.org/all/CAFA6WYMLUD9cnkr=R0Uur+1UeTMkKjM2zDdMJtXb3nmrLk+... [2] https://lore.kernel.org/all/CAL_JsqKEjv2tSGmT+0ZiO7_qbBfhTycbGnhJhYpKDFzfO9j... [3] https://git.kernel.org/pub/scm/linux/kernel/git/devicetree/devicetree-rebasi... [4] https://github.com/u-boot/u-boot/pull/451
Changes
Traditionally, U-boot placed copies of devicetree source files from Linux kernel into `arch/<arch>/dts/<name>.dts`, which can be selected via:
CONFIG_DEFAULT_DEVICE_TREE "<name>"
SoC/board maintainers are encouraged to migrate to using mirrored copies from `devicetree-rebasing/` into `dts/arch/<arch>/<vendor>` via:
CONFIG_OF_UPSTREAM=y CONFIG_DEFAULT_DEVICE_TREE "<vendor>/<name>"
An example have been shown for Amlogic meson-gxbb SoC and corresponding derived boards via patch #7 and #8.
Devicetree bindings schema checks
With devicetee-rebasing Git subtree, the devicetree bindings are also regularly synced with Linux kernel as `devicetree-rebasing/Bindings/` sub-directory. This allows U-boot to run devicetree bindings schema checks which will bring compliance to U-boot core/drivers regarding usage of devicetree.
Dependencies
The DT schema project must be installed in order to validate the DT schema binding documents and validate DTS files using the DT schema. The DT schema project can be installed with pip:
$ pip3 install dtschema
Note that 'dtschema' installation requires 'swig' and Python development files installed first. On Debian/Ubuntu systems:
$ apt install swig python3-dev
Several executables (dt-doc-validate, dt-mk-schema, dt-validate) will be installed. Ensure they are in your PATH (~/.local/bin by default).
Recommended is also to install yamllint (used by dtschema when present).
Running checks
In order to perform validation of DTB files, use the ``dtbs_check`` target:
$ make dtbs_check
It is also possible to run checks with a subset of matching schema files by setting the ``DT_SCHEMA_FILES`` variable to 1 or more specific schema files or patterns (partial match of a fixed string). Each file or pattern should be separated by ':'.
$ make dtbs_check DT_SCHEMA_FILES=trivial-devices.yaml:rtc.yaml $ make dtbs_check DT_SCHEMA_FILES=/gpio/ $ make dtbs_check DT_SCHEMA_FILES=trivial-devices.yaml
Sumit Garg (8): Azure CI: Exclude devicetree-rebasing subtree for CONFIG checks Makefile: Add support for DT bindings schema checks scripts/Makefile.lib: Statically define *-u-boot.dtsi files location dts: Add alternative location for upstream DTB builds doc: devicetree: Updates for devicetree-rebasing subtree MAINTAINERS: Add myself as devicetree-rebasing maintainer dts: meson-gxbb: Switch to using upstream DT dts: meson-gxbb: Drop redundant devicetree files
.azure-pipelines.yml | 3 +- MAINTAINERS | 6 + Makefile | 20 +- arch/arm/dts/Makefile | 8 - arch/arm/dts/meson-gxbb-kii-pro.dts | 140 ---- arch/arm/dts/meson-gxbb-nanopi-k2.dts | 415 ------------ arch/arm/dts/meson-gxbb-odroidc2.dts | 418 ------------ arch/arm/dts/meson-gxbb-p200.dts | 100 --- arch/arm/dts/meson-gxbb-p201.dts | 26 - arch/arm/dts/meson-gxbb-p20x.dtsi | 250 ------- arch/arm/dts/meson-gxbb-wetek-hub.dts | 58 -- arch/arm/dts/meson-gxbb-wetek-play2.dts | 119 ---- arch/arm/dts/meson-gxbb-wetek.dtsi | 292 -------- arch/arm/dts/meson-gxbb.dtsi | 856 ------------------------ configs/nanopi-k2_defconfig | 3 +- configs/odroid-c2_defconfig | 3 +- configs/p200_defconfig | 3 +- configs/p201_defconfig | 3 +- configs/videostrong-kii-pro_defconfig | 3 +- configs/wetek-hub_defconfig | 3 +- configs/wetek-play2_defconfig | 3 +- doc/develop/devicetree/control.rst | 108 ++- dts/Kconfig | 11 + dts/Makefile | 17 +- dts/arch/arm64/Makefile | 23 + dts/arch/arm64/amlogic | 1 + scripts/Makefile.lib | 42 +- 27 files changed, 204 insertions(+), 2730 deletions(-) delete mode 100644 arch/arm/dts/meson-gxbb-kii-pro.dts delete mode 100644 arch/arm/dts/meson-gxbb-nanopi-k2.dts delete mode 100644 arch/arm/dts/meson-gxbb-odroidc2.dts delete mode 100644 arch/arm/dts/meson-gxbb-p200.dts delete mode 100644 arch/arm/dts/meson-gxbb-p201.dts delete mode 100644 arch/arm/dts/meson-gxbb-p20x.dtsi delete mode 100644 arch/arm/dts/meson-gxbb-wetek-hub.dts delete mode 100644 arch/arm/dts/meson-gxbb-wetek-play2.dts delete mode 100644 arch/arm/dts/meson-gxbb-wetek.dtsi delete mode 100644 arch/arm/dts/meson-gxbb.dtsi create mode 100644 dts/arch/arm64/Makefile create mode 120000 dts/arch/arm64/amlogic
On Thu, Dec 14, 2023 at 03:53:11PM +0100, neil.armstrong@linaro.org wrote:
Hi,
On 14/12/2023 14:50, Sumit Garg wrote:
Prerquisite
s/Prerquisite/Prerequisite/
This patch series requires devicetree-rebasing git repo to be added as a subtree to the main U-boot repo via:
$ git subtree add --prefix devicetree-rebasing \ git://git.kernel.org/pub/scm/linux/kernel/git/devicetree/devicetree-rebasing.git \ v6.6-dts --squash
So I think the big question is: when should the subtree be updated ?
Because as we discussed in the previous GH pull request, if a bindings changes was made in the upstream Linux DT, then the subtree update should wait until the u-boot support is merged before updating. This could cause a lot of frustration.
And this could cause a lot of regressions, even more if both Linux and U-boot are not maintained by the same people.
I think some of the important questions to ask are, how often / likely are the breakages to occur? It seems like these days it's either: - U-Boot had an early version of the binding and we already state we don't support backwards compatibility here. It should be on the maintainer to be proactive in this case. - It's a "the DT was wrong about the hardware, sorry not sorry it's an incompatible DTS change now". This too is hopefully the kind of thing that at least board maintainers will be more actively aware of needing to deal with in U-Boot, if it's really a problem.
So I would plan on grabbing only full kernel releases and in to -next as soon as possible. Our cadences don't match up exactly, but I think do fairly well enough.
On Thu, Dec 14, 2023 at 12:23 PM Tom Rini trini@konsulko.com wrote:
On Thu, Dec 14, 2023 at 03:53:11PM +0100, neil.armstrong@linaro.org wrote:
Hi,
On 14/12/2023 14:50, Sumit Garg wrote:
Prerquisite
s/Prerquisite/Prerequisite/
This patch series requires devicetree-rebasing git repo to be added as a subtree to the main U-boot repo via:
$ git subtree add --prefix devicetree-rebasing \ git://git.kernel.org/pub/scm/linux/kernel/git/devicetree/devicetree-rebasing.git \ v6.6-dts --squash
So I think the big question is: when should the subtree be updated ?
Because as we discussed in the previous GH pull request, if a bindings changes was made in the upstream Linux DT, then the subtree update should wait until the u-boot support is merged before updating. This could cause a lot of frustration.
And this could cause a lot of regressions, even more if both Linux and U-boot are not maintained by the same people.
I think some of the important questions to ask are, how often / likely are the breakages to occur? It seems like these days it's either:
- U-Boot had an early version of the binding and we already state we don't support backwards compatibility here. It should be on the maintainer to be proactive in this case.
- It's a "the DT was wrong about the hardware, sorry not sorry it's an incompatible DTS change now". This too is hopefully the kind of thing that at least board maintainers will be more actively aware of needing to deal with in U-Boot, if it's really a problem.
A common issue in the kernel is with forward compatibility when platforms add new resources from a new provider. Then the kernel expects a driver for the provider and waits for the dependency. Of course, older kernels don't have that provider driver and so the dependency is never met. Not sure if u-boot will have similar issues? At least you should/could know if the provider driver exists or not. (The kernel doesn't because modules.)
Rob
On Thu, Dec 14, 2023 at 01:48:42PM -0600, Rob Herring wrote:
On Thu, Dec 14, 2023 at 12:23 PM Tom Rini trini@konsulko.com wrote:
On Thu, Dec 14, 2023 at 03:53:11PM +0100, neil.armstrong@linaro.org wrote:
Hi,
On 14/12/2023 14:50, Sumit Garg wrote:
Prerquisite
s/Prerquisite/Prerequisite/
This patch series requires devicetree-rebasing git repo to be added as a subtree to the main U-boot repo via:
$ git subtree add --prefix devicetree-rebasing \ git://git.kernel.org/pub/scm/linux/kernel/git/devicetree/devicetree-rebasing.git \ v6.6-dts --squash
So I think the big question is: when should the subtree be updated ?
Because as we discussed in the previous GH pull request, if a bindings changes was made in the upstream Linux DT, then the subtree update should wait until the u-boot support is merged before updating. This could cause a lot of frustration.
And this could cause a lot of regressions, even more if both Linux and U-boot are not maintained by the same people.
I think some of the important questions to ask are, how often / likely are the breakages to occur? It seems like these days it's either:
- U-Boot had an early version of the binding and we already state we don't support backwards compatibility here. It should be on the maintainer to be proactive in this case.
- It's a "the DT was wrong about the hardware, sorry not sorry it's an incompatible DTS change now". This too is hopefully the kind of thing that at least board maintainers will be more actively aware of needing to deal with in U-Boot, if it's really a problem.
A common issue in the kernel is with forward compatibility when platforms add new resources from a new provider. Then the kernel expects a driver for the provider and waits for the dependency. Of course, older kernels don't have that provider driver and so the dependency is never met. Not sure if u-boot will have similar issues? At least you should/could know if the provider driver exists or not. (The kernel doesn't because modules.)
I think we'll be fine, but time will tell. And perhaps the more frequent re-syncing will make any sort of corner cases show up more quickly and be something we can figure out how to resolve going forward really.
On Fri, 15 Dec 2023 at 01:45, Tom Rini trini@konsulko.com wrote:
On Thu, Dec 14, 2023 at 01:48:42PM -0600, Rob Herring wrote:
On Thu, Dec 14, 2023 at 12:23 PM Tom Rini trini@konsulko.com wrote:
On Thu, Dec 14, 2023 at 03:53:11PM +0100, neil.armstrong@linaro.org wrote:
Hi,
On 14/12/2023 14:50, Sumit Garg wrote:
Prerquisite
s/Prerquisite/Prerequisite/
This patch series requires devicetree-rebasing git repo to be added as a subtree to the main U-boot repo via:
$ git subtree add --prefix devicetree-rebasing \ git://git.kernel.org/pub/scm/linux/kernel/git/devicetree/devicetree-rebasing.git \ v6.6-dts --squash
So I think the big question is: when should the subtree be updated ?
Because as we discussed in the previous GH pull request, if a bindings changes was made in the upstream Linux DT, then the subtree update should wait until the u-boot support is merged before updating. This could cause a lot of frustration.
And this could cause a lot of regressions, even more if both Linux and U-boot are not maintained by the same people.
I think some of the important questions to ask are, how often / likely are the breakages to occur? It seems like these days it's either:
- U-Boot had an early version of the binding and we already state we don't support backwards compatibility here. It should be on the maintainer to be proactive in this case.
- It's a "the DT was wrong about the hardware, sorry not sorry it's an incompatible DTS change now". This too is hopefully the kind of thing that at least board maintainers will be more actively aware of needing to deal with in U-Boot, if it's really a problem.
A common issue in the kernel is with forward compatibility when platforms add new resources from a new provider. Then the kernel expects a driver for the provider and waits for the dependency. Of course, older kernels don't have that provider driver and so the dependency is never met. Not sure if u-boot will have similar issues? At least you should/could know if the provider driver exists or not. (The kernel doesn't because modules.)
I think we'll be fine, but time will tell. And perhaps the more frequent re-syncing will make any sort of corner cases show up more quickly and be something we can figure out how to resolve going forward really.
Agree, frequent re-syncing is something we should aim for. However, if required then we can always revisit our approach.
-Sumit
-- Tom
On 14/12/2023 21:15, Tom Rini wrote:
On Thu, Dec 14, 2023 at 01:48:42PM -0600, Rob Herring wrote:
On Thu, Dec 14, 2023 at 12:23 PM Tom Rini trini@konsulko.com wrote:
On Thu, Dec 14, 2023 at 03:53:11PM +0100, neil.armstrong@linaro.org wrote:
Hi,
On 14/12/2023 14:50, Sumit Garg wrote:
Prerquisite
s/Prerquisite/Prerequisite/
This patch series requires devicetree-rebasing git repo to be added as a subtree to the main U-boot repo via:
$ git subtree add --prefix devicetree-rebasing \ git://git.kernel.org/pub/scm/linux/kernel/git/devicetree/devicetree-rebasing.git \ v6.6-dts --squash
So I think the big question is: when should the subtree be updated ?
Because as we discussed in the previous GH pull request, if a bindings changes was made in the upstream Linux DT, then the subtree update should wait until the u-boot support is merged before updating. This could cause a lot of frustration.
And this could cause a lot of regressions, even more if both Linux and U-boot are not maintained by the same people.
I think some of the important questions to ask are, how often / likely are the breakages to occur? It seems like these days it's either:
- U-Boot had an early version of the binding and we already state we don't support backwards compatibility here. It should be on the maintainer to be proactive in this case.
- It's a "the DT was wrong about the hardware, sorry not sorry it's an incompatible DTS change now". This too is hopefully the kind of thing that at least board maintainers will be more actively aware of needing to deal with in U-Boot, if it's really a problem.
A common issue in the kernel is with forward compatibility when platforms add new resources from a new provider. Then the kernel expects a driver for the provider and waits for the dependency. Of course, older kernels don't have that provider driver and so the dependency is never met. Not sure if u-boot will have similar issues? At least you should/could know if the provider driver exists or not. (The kernel doesn't because modules.)
I think we'll be fine, but time will tell. And perhaps the more frequent re-syncing will make any sort of corner cases show up more quickly and be something we can figure out how to resolve going forward really.
Sure, I suppose I'll only switch the stable boards, and keep the in-progress ones with manual sync. And I'll need to make a prerequisite to any breaking DT change to have the corresponding U-Boot change submitted before (and probably other OSes like *BSD*s)
Neil
On 14/12/2023 20:48, Rob Herring wrote:
I think some of the important questions to ask are, how often / likely are the breakages to occur? It seems like these days it's either:
- U-Boot had an early version of the binding and we already state we don't support backwards compatibility here. It should be on the maintainer to be proactive in this case.
- It's a "the DT was wrong about the hardware, sorry not sorry it's an incompatible DTS change now". This too is hopefully the kind of thing that at least board maintainers will be more actively aware of needing to deal with in U-Boot, if it's really a problem.
A common issue in the kernel is with forward compatibility when platforms add new resources from a new provider. Then the kernel expects a driver for the provider and waits for the dependency. Of course, older kernels don't have that provider driver and so the dependency is never met. Not sure if u-boot will have similar issues? At least you should/could know if the provider driver exists or not. (The kernel doesn't because modules.)
If some U-Boot platform decides to aggressively sync with kernel DTS, then probably the kernel subarch maintainer should be aware of it. Mentioned forward compatibility issue is a result of assumption that there are no out-of-tree upstream consumers of our DTS. I am certainly not aware of any such consumer for Samsung. If someone told me (me wearing Samsung hat), hey U-Boot now cares, I would start caring as well.
The usual argument of contributors wanting to break the backward and forward compatibility, is "there is no other OS depending on this" (recent discussion with Johan about order of interrupts: https://lore.kernel.org/all/ZWcPZPX-eT-xHAOv@hovoldconsulting.com/ ). You need to tell the maintainers of that platform, that now they have other OS/firmware/bootloader depending on DTS compatibility.
Best regards, Krzysztof
On Fri, Dec 15, 2023 at 08:50:51AM +0100, Krzysztof Kozlowski wrote:
On 14/12/2023 20:48, Rob Herring wrote:
I think some of the important questions to ask are, how often / likely are the breakages to occur? It seems like these days it's either:
- U-Boot had an early version of the binding and we already state we don't support backwards compatibility here. It should be on the maintainer to be proactive in this case.
- It's a "the DT was wrong about the hardware, sorry not sorry it's an incompatible DTS change now". This too is hopefully the kind of thing that at least board maintainers will be more actively aware of needing to deal with in U-Boot, if it's really a problem.
A common issue in the kernel is with forward compatibility when platforms add new resources from a new provider. Then the kernel expects a driver for the provider and waits for the dependency. Of course, older kernels don't have that provider driver and so the dependency is never met. Not sure if u-boot will have similar issues? At least you should/could know if the provider driver exists or not. (The kernel doesn't because modules.)
If some U-Boot platform decides to aggressively sync with kernel DTS, then probably the kernel subarch maintainer should be aware of it. Mentioned forward compatibility issue is a result of assumption that there are no out-of-tree upstream consumers of our DTS. I am certainly not aware of any such consumer for Samsung. If someone told me (me wearing Samsung hat), hey U-Boot now cares, I would start caring as well.
The usual argument of contributors wanting to break the backward and forward compatibility, is "there is no other OS depending on this" (recent discussion with Johan about order of interrupts: https://lore.kernel.org/all/ZWcPZPX-eT-xHAOv@hovoldconsulting.com/ ). You need to tell the maintainers of that platform, that now they have other OS/firmware/bootloader depending on DTS compatibility.
I think this hints at one of the bigger impacts this might have. Reminding everyone that other projects do use the device trees and have for years. Without rehashing history, BSD does use the trees as-is and for platforms U-Boot supports they are supposed to be re-synced periodically. This series moves us from an ad-hoc method to a defined schedule.
And presumably some of the Samsung platforms will get moved over to this framework, especially the newer ones being submitted recently :)
On Fri, Dec 15, 2023 at 08:37:43AM -0500, Tom Rini wrote:
On Fri, Dec 15, 2023 at 08:50:51AM +0100, Krzysztof Kozlowski wrote:
On 14/12/2023 20:48, Rob Herring wrote:
I think some of the important questions to ask are, how often / likely are the breakages to occur? It seems like these days it's either:
- U-Boot had an early version of the binding and we already state we don't support backwards compatibility here. It should be on the maintainer to be proactive in this case.
- It's a "the DT was wrong about the hardware, sorry not sorry it's an incompatible DTS change now". This too is hopefully the kind of thing that at least board maintainers will be more actively aware of needing to deal with in U-Boot, if it's really a problem.
A common issue in the kernel is with forward compatibility when platforms add new resources from a new provider. Then the kernel expects a driver for the provider and waits for the dependency. Of course, older kernels don't have that provider driver and so the dependency is never met. Not sure if u-boot will have similar issues? At least you should/could know if the provider driver exists or not. (The kernel doesn't because modules.)
If some U-Boot platform decides to aggressively sync with kernel DTS, then probably the kernel subarch maintainer should be aware of it. Mentioned forward compatibility issue is a result of assumption that there are no out-of-tree upstream consumers of our DTS. I am certainly not aware of any such consumer for Samsung. If someone told me (me wearing Samsung hat), hey U-Boot now cares, I would start caring as well.
The usual argument of contributors wanting to break the backward and forward compatibility, is "there is no other OS depending on this" (recent discussion with Johan about order of interrupts: https://lore.kernel.org/all/ZWcPZPX-eT-xHAOv@hovoldconsulting.com/ ). You need to tell the maintainers of that platform, that now they have other OS/firmware/bootloader depending on DTS compatibility.
I think this hints at one of the bigger impacts this might have. Reminding everyone that other projects do use the device trees and have for years.
TBF, we do try to ask these questions as much as possible, usually (for me at least) citing U-Boot or the BSDs as users. It largely seems to me like we are all bark and no bite though, so a project like U-Boot having a defined "schedule" as you suggest below would add more meaning to our questioning.
Without rehashing history, BSD does use the trees as-is and for platforms U-Boot supports they are supposed to be re-synced periodically.
I know this is the theory, but I also know that how well this is implemented varies wildly per-platform. I generally don't pay all that much attention to the various arm platforms, but I do pay attention to what's going on for RISC-V and there appear to be no active maintainers of individual platforms and the architecture maintainers are not aware of the status of the equivalent patches for Linux when they apply patches.
In recent memory, this has lead to the clock indices in the DT differing between U-Boot and Linux for one such platform, which, IMO, is an insidious difference that is hard to spot during review and highly unlikely to crop up while comparing dts files, since the defines were named identically. To be clear, I am not expecting the architecture code maintainers to be aware of the minutiae of the various RISC-V platforms, but rather suggesting they might have an easier time reviewing if both projects' dts files and binding headers were tied together.
That said, automatically synced devicetrees will, as has been pointed out, require the platform maintainers in Linux to be more aware of the affect of what they accept on other users, but it will also require the equivalent maintainers on the U-Boot side to engage too, so that the "upstream" dts files do not change in a way that screws the usecase in U-Boot.
Also, if people send fixes to the U-Boot copies of these devicetrees, would the plan be to request that these are sent to Linux and the fixes pulled in via a resync after each -rc release of Linux (or similar, just throwing some example schedule out there)?
Cheers, Conor.
This series moves us from an ad-hoc method to a defined schedule.
And presumably some of the Samsung platforms will get moved over to this framework, especially the newer ones being submitted recently :)
On Fri, Dec 15, 2023 at 02:45:11PM +0000, Conor Dooley wrote:
On Fri, Dec 15, 2023 at 08:37:43AM -0500, Tom Rini wrote:
On Fri, Dec 15, 2023 at 08:50:51AM +0100, Krzysztof Kozlowski wrote:
On 14/12/2023 20:48, Rob Herring wrote:
I think some of the important questions to ask are, how often / likely are the breakages to occur? It seems like these days it's either:
- U-Boot had an early version of the binding and we already state we don't support backwards compatibility here. It should be on the maintainer to be proactive in this case.
- It's a "the DT was wrong about the hardware, sorry not sorry it's an incompatible DTS change now". This too is hopefully the kind of thing that at least board maintainers will be more actively aware of needing to deal with in U-Boot, if it's really a problem.
A common issue in the kernel is with forward compatibility when platforms add new resources from a new provider. Then the kernel expects a driver for the provider and waits for the dependency. Of course, older kernels don't have that provider driver and so the dependency is never met. Not sure if u-boot will have similar issues? At least you should/could know if the provider driver exists or not. (The kernel doesn't because modules.)
If some U-Boot platform decides to aggressively sync with kernel DTS, then probably the kernel subarch maintainer should be aware of it. Mentioned forward compatibility issue is a result of assumption that there are no out-of-tree upstream consumers of our DTS. I am certainly not aware of any such consumer for Samsung. If someone told me (me wearing Samsung hat), hey U-Boot now cares, I would start caring as well.
The usual argument of contributors wanting to break the backward and forward compatibility, is "there is no other OS depending on this" (recent discussion with Johan about order of interrupts: https://lore.kernel.org/all/ZWcPZPX-eT-xHAOv@hovoldconsulting.com/ ). You need to tell the maintainers of that platform, that now they have other OS/firmware/bootloader depending on DTS compatibility.
I think this hints at one of the bigger impacts this might have. Reminding everyone that other projects do use the device trees and have for years.
TBF, we do try to ask these questions as much as possible, usually (for me at least) citing U-Boot or the BSDs as users. It largely seems to me like we are all bark and no bite though, so a project like U-Boot having a defined "schedule" as you suggest below would add more meaning to our questioning.
Without rehashing history, BSD does use the trees as-is and for platforms U-Boot supports they are supposed to be re-synced periodically.
I know this is the theory, but I also know that how well this is implemented varies wildly per-platform. I generally don't pay all that much attention to the various arm platforms, but I do pay attention to what's going on for RISC-V and there appear to be no active maintainers of individual platforms and the architecture maintainers are not aware of the status of the equivalent patches for Linux when they apply patches.
In recent memory, this has lead to the clock indices in the DT differing between U-Boot and Linux for one such platform, which, IMO, is an insidious difference that is hard to spot during review and highly unlikely to crop up while comparing dts files, since the defines were named identically. To be clear, I am not expecting the architecture code maintainers to be aware of the minutiae of the various RISC-V platforms, but rather suggesting they might have an easier time reviewing if both projects' dts files and binding headers were tied together.
That said, automatically synced devicetrees will, as has been pointed out, require the platform maintainers in Linux to be more aware of the affect of what they accept on other users, but it will also require the equivalent maintainers on the U-Boot side to engage too, so that the "upstream" dts files do not change in a way that screws the usecase in U-Boot.
Yeah, it will hopefully lead to better coordination between maintainers in some places. There are SoCs where the kernel DTS people are the U-Boot DTS people too. All in all, I should probably CC more people than I usually do on these resync patches just to try and head off any tricky changes like you've mentioned above.
Also, if people send fixes to the U-Boot copies of these devicetrees, would the plan be to request that these are sent to Linux and the fixes pulled in via a resync after each -rc release of Linux (or similar, just throwing some example schedule out there)?
The way we've always tried to operate is that changes should be pushed to Linux and resynced down, or at least submitted simultaneously. If there's some specific bugfixes that need to come in out of cycle I _think_ subtree handles cherry picked commits in a reasonable fashion.
On Sat, 16 Dec 2023 at 00:49, Tom Rini trini@konsulko.com wrote:
On Fri, Dec 15, 2023 at 02:45:11PM +0000, Conor Dooley wrote:
On Fri, Dec 15, 2023 at 08:37:43AM -0500, Tom Rini wrote:
On Fri, Dec 15, 2023 at 08:50:51AM +0100, Krzysztof Kozlowski wrote:
On 14/12/2023 20:48, Rob Herring wrote:
I think some of the important questions to ask are, how often / likely are the breakages to occur? It seems like these days it's either:
- U-Boot had an early version of the binding and we already state we don't support backwards compatibility here. It should be on the maintainer to be proactive in this case.
- It's a "the DT was wrong about the hardware, sorry not sorry it's an incompatible DTS change now". This too is hopefully the kind of thing that at least board maintainers will be more actively aware of needing to deal with in U-Boot, if it's really a problem.
A common issue in the kernel is with forward compatibility when platforms add new resources from a new provider. Then the kernel expects a driver for the provider and waits for the dependency. Of course, older kernels don't have that provider driver and so the dependency is never met. Not sure if u-boot will have similar issues? At least you should/could know if the provider driver exists or not. (The kernel doesn't because modules.)
If some U-Boot platform decides to aggressively sync with kernel DTS, then probably the kernel subarch maintainer should be aware of it. Mentioned forward compatibility issue is a result of assumption that there are no out-of-tree upstream consumers of our DTS. I am certainly not aware of any such consumer for Samsung. If someone told me (me wearing Samsung hat), hey U-Boot now cares, I would start caring as well.
The usual argument of contributors wanting to break the backward and forward compatibility, is "there is no other OS depending on this" (recent discussion with Johan about order of interrupts: https://lore.kernel.org/all/ZWcPZPX-eT-xHAOv@hovoldconsulting.com/ ). You need to tell the maintainers of that platform, that now they have other OS/firmware/bootloader depending on DTS compatibility.
I think this hints at one of the bigger impacts this might have. Reminding everyone that other projects do use the device trees and have for years.
TBF, we do try to ask these questions as much as possible, usually (for me at least) citing U-Boot or the BSDs as users. It largely seems to me like we are all bark and no bite though, so a project like U-Boot having a defined "schedule" as you suggest below would add more meaning to our questioning.
Without rehashing history, BSD does use the trees as-is and for platforms U-Boot supports they are supposed to be re-synced periodically.
I know this is the theory, but I also know that how well this is implemented varies wildly per-platform. I generally don't pay all that much attention to the various arm platforms, but I do pay attention to what's going on for RISC-V and there appear to be no active maintainers of individual platforms and the architecture maintainers are not aware of the status of the equivalent patches for Linux when they apply patches.
In recent memory, this has lead to the clock indices in the DT differing between U-Boot and Linux for one such platform, which, IMO, is an insidious difference that is hard to spot during review and highly unlikely to crop up while comparing dts files, since the defines were named identically. To be clear, I am not expecting the architecture code maintainers to be aware of the minutiae of the various RISC-V platforms, but rather suggesting they might have an easier time reviewing if both projects' dts files and binding headers were tied together.
That said, automatically synced devicetrees will, as has been pointed out, require the platform maintainers in Linux to be more aware of the affect of what they accept on other users, but it will also require the equivalent maintainers on the U-Boot side to engage too, so that the "upstream" dts files do not change in a way that screws the usecase in U-Boot.
Yeah, it will hopefully lead to better coordination between maintainers in some places. There are SoCs where the kernel DTS people are the U-Boot DTS people too. All in all, I should probably CC more people than I usually do on these resync patches just to try and head off any tricky changes like you've mentioned above.
Makes sense.
Also, if people send fixes to the U-Boot copies of these devicetrees, would the plan be to request that these are sent to Linux and the fixes pulled in via a resync after each -rc release of Linux (or similar, just throwing some example schedule out there)?
The way we've always tried to operate is that changes should be pushed to Linux and resynced down, or at least submitted simultaneously. If there's some specific bugfixes that need to come in out of cycle I _think_ subtree handles cherry picked commits in a reasonable fashion.
Agree.
-Sumit
-- Tom
On Thu, 14 Dec 2023 at 23:53, Tom Rini trini@konsulko.com wrote:
On Thu, Dec 14, 2023 at 03:53:11PM +0100, neil.armstrong@linaro.org wrote:
Hi,
On 14/12/2023 14:50, Sumit Garg wrote:
Prerquisite
s/Prerquisite/Prerequisite/
Ack.
This patch series requires devicetree-rebasing git repo to be added as a subtree to the main U-boot repo via:
$ git subtree add --prefix devicetree-rebasing \ git://git.kernel.org/pub/scm/linux/kernel/git/devicetree/devicetree-rebasing.git \ v6.6-dts --squash
So I think the big question is: when should the subtree be updated ?
Because as we discussed in the previous GH pull request, if a bindings changes was made in the upstream Linux DT, then the subtree update should wait until the u-boot support is merged before updating. This could cause a lot of frustration.
And this could cause a lot of regressions, even more if both Linux and U-boot are not maintained by the same people.
I think some of the important questions to ask are, how often / likely are the breakages to occur? It seems like these days it's either:
- U-Boot had an early version of the binding and we already state we don't support backwards compatibility here. It should be on the maintainer to be proactive in this case.
- It's a "the DT was wrong about the hardware, sorry not sorry it's an incompatible DTS change now". This too is hopefully the kind of thing that at least board maintainers will be more actively aware of needing to deal with in U-Boot, if it's really a problem.
Agree, also per discussion with Linux DT maintainers, they do care for DT backwards and forward compatibility. I expect the ABI changes to be rare. In case there is an ABI change then it will be great if Linux DT maintainers can ask contributors to CC corresponding U-boot platform maintainers too.
BTW, Rob is already working on a tool to detect ABI changes as he described here [1]. If U-boot platform maintainers have any ideas regarding what would constitute an ABI change then feel free to share those.
[1] https://lore.kernel.org/all/CAL_JsqLo4nXrJ93dDsfp3UYLs08V02aMnbCCnsDj0MBBomc...
So I would plan on grabbing only full kernel releases and in to -next as soon as possible. Our cadences don't match up exactly, but I think do fairly well enough.
I suppose that would give ample time to the U-boot platform/board maintainer to fix any ABI change regression found in the -next branch. That being said we aren't completely immune to changes to devicetree-rebasing subtree. If there is an DT ABI change that will take significant effort to fix in U-boot then we are open to accepting a revert given that it will be fixed before next uprev.
-Sumit
-- Tom
Hi Sumit,
On 12/14/23 14:50, Sumit Garg wrote:
Prerquisite
This patch series requires devicetree-rebasing git repo to be added as a subtree to the main U-boot repo via:
$ git subtree add --prefix devicetree-rebasing \ git://git.kernel.org/pub/scm/linux/kernel/git/devicetree/devicetree-rebasing.git \ v6.6-dts --squash
Background
This effort started while I was reviewing patch series corresponding to Qcom platforms [1] which was about to import modified devicetree source files from Linux kernel. I suppose keeping devicetree files sync with Linux kernel without any DT bindings schema validation has been a pain for U-boot SoC/platform maintainers. There has been past discussions about a single DT repo but that hasn't come up and Linux kernel remained the place where DT source files as well as bindings are placed and maintained.
However, Linux kernel DT maintainers proposed [2] for U-boot to rather use devicetree-rebasing repo [3] which is a forked copy from Linux kernel for DT source files as well as bindings. It is tagged at every Linux kernel major release or intermideate release candidates. So here I have tried to reuse that to bring DT bingings compliance as well as a standard way to maintain a regular sync of DT source files with Linux kernel.
In order to maintain devicetree files sync, U-boot will maintains a Git subtree for devicetee-rebasing repo as `devicetee-rebasing/` sub-directory. It will be regularly updated with every new kernel major release via subtree pull as follows::
$ git subtree pull --prefix devicetree-rebasing \ git://git.kernel.org/pub/scm/linux/kernel/git/devicetree/devicetree-rebasing.git \ <release-tag> --squash
The RFC/prototype for this series has been discussed with Linux DT maintainers as well as U-boot maintainers here [4]. Now we would like to reach out to wider U-boot community to seek feedback.
[1] https://lore.kernel.org/all/CAFA6WYMLUD9cnkr=R0Uur+1UeTMkKjM2zDdMJtXb3nmrLk+... [2] https://lore.kernel.org/all/CAL_JsqKEjv2tSGmT+0ZiO7_qbBfhTycbGnhJhYpKDFzfO9j... [3] https://git.kernel.org/pub/scm/linux/kernel/git/devicetree/devicetree-rebasi... [4] https://github.com/u-boot/u-boot/pull/451
Changes
Traditionally, U-boot placed copies of devicetree source files from Linux kernel into `arch/<arch>/dts/<name>.dts`, which can be selected via:
CONFIG_DEFAULT_DEVICE_TREE "<name>"
SoC/board maintainers are encouraged to migrate to using mirrored copies from `devicetree-rebasing/` into `dts/arch/<arch>/<vendor>` via:
CONFIG_OF_UPSTREAM=y CONFIG_DEFAULT_DEVICE_TREE "<vendor>/<name>"
An example have been shown for Amlogic meson-gxbb SoC and corresponding derived boards via patch #7 and #8.
Devicetree bindings schema checks
With devicetee-rebasing Git subtree, the devicetree bindings are also regularly synced with Linux kernel as `devicetree-rebasing/Bindings/` sub-directory. This allows U-boot to run devicetree bindings schema checks which will bring compliance to U-boot core/drivers regarding usage of devicetree.
Dependencies
The DT schema project must be installed in order to validate the DT schema binding documents and validate DTS files using the DT schema. The DT schema project can be installed with pip:
$ pip3 install dtschema
Note that 'dtschema' installation requires 'swig' and Python development files installed first. On Debian/Ubuntu systems:
$ apt install swig python3-dev
Several executables (dt-doc-validate, dt-mk-schema, dt-validate) will be installed. Ensure they are in your PATH (~/.local/bin by default).
Recommended is also to install yamllint (used by dtschema when present).
Running checks
In order to perform validation of DTB files, use the ``dtbs_check`` target:
$ make dtbs_check
It is also possible to run checks with a subset of matching schema files by setting the ``DT_SCHEMA_FILES`` variable to 1 or more specific schema files or patterns (partial match of a fixed string). Each file or pattern should be separated by ':'.
$ make dtbs_check DT_SCHEMA_FILES=trivial-devices.yaml:rtc.yaml $ make dtbs_check DT_SCHEMA_FILES=/gpio/ $ make dtbs_check DT_SCHEMA_FILES=trivial-devices.yaml
Do you also plan to extend this to cover dt overlay + dt base generation and check it against DT schema.
Thanks, Michal
Hi Michal,
On Wed, 20 Dec 2023 at 16:14, Michal Simek michal.simek@amd.com wrote:
Hi Sumit,
On 12/14/23 14:50, Sumit Garg wrote:
Prerquisite
This patch series requires devicetree-rebasing git repo to be added as a subtree to the main U-boot repo via:
$ git subtree add --prefix devicetree-rebasing \ git://git.kernel.org/pub/scm/linux/kernel/git/devicetree/devicetree-rebasing.git \ v6.6-dts --squash
Background
This effort started while I was reviewing patch series corresponding to Qcom platforms [1] which was about to import modified devicetree source files from Linux kernel. I suppose keeping devicetree files sync with Linux kernel without any DT bindings schema validation has been a pain for U-boot SoC/platform maintainers. There has been past discussions about a single DT repo but that hasn't come up and Linux kernel remained the place where DT source files as well as bindings are placed and maintained.
However, Linux kernel DT maintainers proposed [2] for U-boot to rather use devicetree-rebasing repo [3] which is a forked copy from Linux kernel for DT source files as well as bindings. It is tagged at every Linux kernel major release or intermideate release candidates. So here I have tried to reuse that to bring DT bingings compliance as well as a standard way to maintain a regular sync of DT source files with Linux kernel.
In order to maintain devicetree files sync, U-boot will maintains a Git subtree for devicetee-rebasing repo as `devicetee-rebasing/` sub-directory. It will be regularly updated with every new kernel major release via subtree pull as follows::
$ git subtree pull --prefix devicetree-rebasing \ git://git.kernel.org/pub/scm/linux/kernel/git/devicetree/devicetree-rebasing.git \ <release-tag> --squash
The RFC/prototype for this series has been discussed with Linux DT maintainers as well as U-boot maintainers here [4]. Now we would like to reach out to wider U-boot community to seek feedback.
[1] https://lore.kernel.org/all/CAFA6WYMLUD9cnkr=R0Uur+1UeTMkKjM2zDdMJtXb3nmrLk+... [2] https://lore.kernel.org/all/CAL_JsqKEjv2tSGmT+0ZiO7_qbBfhTycbGnhJhYpKDFzfO9j... [3] https://git.kernel.org/pub/scm/linux/kernel/git/devicetree/devicetree-rebasi... [4] https://github.com/u-boot/u-boot/pull/451
Changes
Traditionally, U-boot placed copies of devicetree source files from Linux kernel into `arch/<arch>/dts/<name>.dts`, which can be selected via:
CONFIG_DEFAULT_DEVICE_TREE "<name>"
SoC/board maintainers are encouraged to migrate to using mirrored copies from `devicetree-rebasing/` into `dts/arch/<arch>/<vendor>` via:
CONFIG_OF_UPSTREAM=y CONFIG_DEFAULT_DEVICE_TREE "<vendor>/<name>"
An example have been shown for Amlogic meson-gxbb SoC and corresponding derived boards via patch #7 and #8.
Devicetree bindings schema checks
With devicetee-rebasing Git subtree, the devicetree bindings are also regularly synced with Linux kernel as `devicetree-rebasing/Bindings/` sub-directory. This allows U-boot to run devicetree bindings schema checks which will bring compliance to U-boot core/drivers regarding usage of devicetree.
Dependencies
The DT schema project must be installed in order to validate the DT schema binding documents and validate DTS files using the DT schema. The DT schema project can be installed with pip:
$ pip3 install dtschema
Note that 'dtschema' installation requires 'swig' and Python development files installed first. On Debian/Ubuntu systems:
$ apt install swig python3-dev
Several executables (dt-doc-validate, dt-mk-schema, dt-validate) will be installed. Ensure they are in your PATH (~/.local/bin by default).
Recommended is also to install yamllint (used by dtschema when present).
Running checks
In order to perform validation of DTB files, use the ``dtbs_check`` target:
$ make dtbs_check
It is also possible to run checks with a subset of matching schema files by setting the ``DT_SCHEMA_FILES`` variable to 1 or more specific schema files or patterns (partial match of a fixed string). Each file or pattern should be separated by ':'.
$ make dtbs_check DT_SCHEMA_FILES=trivial-devices.yaml:rtc.yaml $ make dtbs_check DT_SCHEMA_FILES=/gpio/ $ make dtbs_check DT_SCHEMA_FILES=trivial-devices.yaml
Do you also plan to extend this to cover dt overlay + dt base generation and check it against DT schema.
I suppose here you are referring to DT schema checks for *.dtso -> *.dtbo generation. I don't see corresponding checks enabled in Linux kernel [1]. Probably Rob can share plans over there.
U-Boot tries to follow Linux kernel kbuild framework. However, if needed we can add checks for *.dtbo generation too as a follow up patch.
[1] https://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git/tree/scr...
-Sumit
Thanks, Michal
On Thu, Dec 14, 2023 at 07:20:55PM +0530, Sumit Garg wrote:
Prerquisite
This patch series requires devicetree-rebasing git repo to be added as a subtree to the main U-boot repo via:
$ git subtree add --prefix devicetree-rebasing \ git://git.kernel.org/pub/scm/linux/kernel/git/devicetree/devicetree-rebasing.git \ v6.6-dts --squash
So, I've played with subtree a little and I think this is the right way forward in these cases. If anyone wants to take a look at how this works in practice, take a look at: https://source.denx.de/u-boot/u-boot/-/commits/WIP/u-boot-with-devicetree-re... In that tree I started with the v6.1-dts tag, sync'd all the configs (to have an example of a normal commit) and then did a merge of each tag until v6.6-dts, so provide some history. And git log looks like what I want to see, the squash commit has clear references to what we are getting and I make a merge commit that says what I did. If you pull the tree and checkout the branch, all the code is right there already, nothing further to do. Same with tarball releases. The only thing I don't like is the size growth there, but we'll reclaim some of it when we delete our obsolete bindings, and then obsolete dts files.
Maxim, please switch (back, sorry!) to subtree for the next lwIP patchset and just not in the prerequisite steps what the subtree command is, and make sure the docs have an example of what future re-sync "subtree pull" commands should look like. For CI testing, you'll have to do that to start with and just not include that patch in the ML part.
Hi,
On Thu, Dec 21, 2023 at 3:03 PM Tom Rini trini@konsulko.com wrote:
On Thu, Dec 14, 2023 at 07:20:55PM +0530, Sumit Garg wrote:
Prerquisite
This patch series requires devicetree-rebasing git repo to be added as a subtree to the main U-boot repo via:
$ git subtree add --prefix devicetree-rebasing \ git://git.kernel.org/pub/scm/linux/kernel/git/devicetree/devicetree-rebasing.git \ v6.6-dts --squash
So, I've played with subtree a little and I think this is the right way forward in these cases. If anyone wants to take a look at how this works in practice, take a look at: https://source.denx.de/u-boot/u-boot/-/commits/WIP/u-boot-with-devicetree-re... In that tree I started with the v6.1-dts tag, sync'd all the configs (to have an example of a normal commit) and then did a merge of each tag until v6.6-dts, so provide some history. And git log looks like what I want to see, the squash commit has clear references to what we are getting and I make a merge commit that says what I did. If you pull the tree and checkout the branch, all the code is right there already, nothing further to do. Same with tarball releases. The only thing I don't like is the size growth there, but we'll reclaim some of it when we delete our obsolete bindings, and then obsolete dts files.
I spent a bit of time with subtree as well, as part of reviewing this series, using the instructions Sumit provided. It seems OK to me. We have to accept that it adds code and there will be changes/churn, but it is not too different to accepting patches on those files within U-Boot. We will bring in files which U-Boot doesn't use, but U-Boot does support a good proportion of the boards supported by Linux, so I don't see that as a big cost.
From my experimentation, subtrees seem to have no impact on buildman,
which is great. Am I missing anything?
I still worry about the board-level 'switch' between U-Boot DT and upstream ones. I believe that should be at the SoC level instead.
Maxim, please switch (back, sorry!) to subtree for the next lwIP patchset and just not in the prerequisite steps what the subtree command is, and make sure the docs have an example of what future re-sync "subtree pull" commands should look like. For CI testing, you'll have to do that to start with and just not include that patch in the ML part.
Regards, Simon
On Thu, 21 Dec 2023 at 20:48, Simon Glass sjg@chromium.org wrote:
Hi,
On Thu, Dec 21, 2023 at 3:03 PM Tom Rini trini@konsulko.com wrote:
On Thu, Dec 14, 2023 at 07:20:55PM +0530, Sumit Garg wrote:
Prerquisite
This patch series requires devicetree-rebasing git repo to be added as a subtree to the main U-boot repo via:
$ git subtree add --prefix devicetree-rebasing \ git://git.kernel.org/pub/scm/linux/kernel/git/devicetree/devicetree-rebasing.git \ v6.6-dts --squash
So, I've played with subtree a little and I think this is the right way forward in these cases. If anyone wants to take a look at how this works in practice, take a look at: https://source.denx.de/u-boot/u-boot/-/commits/WIP/u-boot-with-devicetree-re... In that tree I started with the v6.1-dts tag, sync'd all the configs (to have an example of a normal commit) and then did a merge of each tag until v6.6-dts, so provide some history. And git log looks like what I want to see, the squash commit has clear references to what we are getting and I make a merge commit that says what I did. If you pull the tree and checkout the branch, all the code is right there already, nothing further to do. Same with tarball releases. The only thing I don't like is the size growth there, but we'll reclaim some of it when we delete our obsolete bindings, and then obsolete dts files.
I spent a bit of time with subtree as well, as part of reviewing this series, using the instructions Sumit provided. It seems OK to me. We have to accept that it adds code and there will be changes/churn, but it is not too different to accepting patches on those files within U-Boot. We will bring in files which U-Boot doesn't use, but U-Boot does support a good proportion of the boards supported by Linux, so I don't see that as a big cost.
From my experimentation, subtrees seem to have no impact on buildman, which is great. Am I missing anything?
No it shouldn't cause any regression on existing tools/CI/build systems. It is just a version controlled way of importing third party source code as a tarball.
I still worry about the board-level 'switch' between U-Boot DT and upstream ones. I believe that should be at the SoC level instead.
Probably I wasn't clear enough in my earlier replies but this series motivates for a SoC level switch only. Patch #7 is essentially a switch for Amlogic meson-gxbb SoC and its derived boards.
-Sumit
Maxim, please switch (back, sorry!) to subtree for the next lwIP patchset and just not in the prerequisite steps what the subtree command is, and make sure the docs have an example of what future re-sync "subtree pull" commands should look like. For CI testing, you'll have to do that to start with and just not include that patch in the ML part.
Regards, Simon
Hi Sumit,
On Fri, Dec 22, 2023 at 5:34 AM Sumit Garg sumit.garg@linaro.org wrote:
On Thu, 21 Dec 2023 at 20:48, Simon Glass sjg@chromium.org wrote:
Hi,
On Thu, Dec 21, 2023 at 3:03 PM Tom Rini trini@konsulko.com wrote:
On Thu, Dec 14, 2023 at 07:20:55PM +0530, Sumit Garg wrote:
Prerquisite
This patch series requires devicetree-rebasing git repo to be added as a subtree to the main U-boot repo via:
$ git subtree add --prefix devicetree-rebasing \ git://git.kernel.org/pub/scm/linux/kernel/git/devicetree/devicetree-rebasing.git \ v6.6-dts --squash
So, I've played with subtree a little and I think this is the right way forward in these cases. If anyone wants to take a look at how this works in practice, take a look at: https://source.denx.de/u-boot/u-boot/-/commits/WIP/u-boot-with-devicetree-re... In that tree I started with the v6.1-dts tag, sync'd all the configs (to have an example of a normal commit) and then did a merge of each tag until v6.6-dts, so provide some history. And git log looks like what I want to see, the squash commit has clear references to what we are getting and I make a merge commit that says what I did. If you pull the tree and checkout the branch, all the code is right there already, nothing further to do. Same with tarball releases. The only thing I don't like is the size growth there, but we'll reclaim some of it when we delete our obsolete bindings, and then obsolete dts files.
I spent a bit of time with subtree as well, as part of reviewing this series, using the instructions Sumit provided. It seems OK to me. We have to accept that it adds code and there will be changes/churn, but it is not too different to accepting patches on those files within U-Boot. We will bring in files which U-Boot doesn't use, but U-Boot does support a good proportion of the boards supported by Linux, so I don't see that as a big cost.
From my experimentation, subtrees seem to have no impact on buildman, which is great. Am I missing anything?
No it shouldn't cause any regression on existing tools/CI/build systems. It is just a version controlled way of importing third party source code as a tarball.
I still worry about the board-level 'switch' between U-Boot DT and upstream ones. I believe that should be at the SoC level instead.
Probably I wasn't clear enough in my earlier replies but this series motivates for a SoC level switch only. Patch #7 is essentially a switch for Amlogic meson-gxbb SoC and its derived boards.
OK good...but that's not quite what I mean. You have a fragment like this in multiple defconfig files:
+CONFIG_OF_UPSTREAM=y +CONFIG_DEFAULT_DEVICE_TREE="amlogic/meson-gxbb-odroidc2"
instead, OF_UPSTREAM should be enabled via 'imply' for the SoC, in the Kconfig. We should not have to specify the filename like this. It is laborious and error-prone.
Regards, Simon
Hi Simon,
On Tue, 26 Dec 2023 at 15:17, Simon Glass sjg@chromium.org wrote:
Hi Sumit,
On Fri, Dec 22, 2023 at 5:34 AM Sumit Garg sumit.garg@linaro.org wrote:
On Thu, 21 Dec 2023 at 20:48, Simon Glass sjg@chromium.org wrote:
Hi,
On Thu, Dec 21, 2023 at 3:03 PM Tom Rini trini@konsulko.com wrote:
On Thu, Dec 14, 2023 at 07:20:55PM +0530, Sumit Garg wrote:
Prerquisite
This patch series requires devicetree-rebasing git repo to be added as a subtree to the main U-boot repo via:
$ git subtree add --prefix devicetree-rebasing \ git://git.kernel.org/pub/scm/linux/kernel/git/devicetree/devicetree-rebasing.git \ v6.6-dts --squash
So, I've played with subtree a little and I think this is the right way forward in these cases. If anyone wants to take a look at how this works in practice, take a look at: https://source.denx.de/u-boot/u-boot/-/commits/WIP/u-boot-with-devicetree-re... In that tree I started with the v6.1-dts tag, sync'd all the configs (to have an example of a normal commit) and then did a merge of each tag until v6.6-dts, so provide some history. And git log looks like what I want to see, the squash commit has clear references to what we are getting and I make a merge commit that says what I did. If you pull the tree and checkout the branch, all the code is right there already, nothing further to do. Same with tarball releases. The only thing I don't like is the size growth there, but we'll reclaim some of it when we delete our obsolete bindings, and then obsolete dts files.
I spent a bit of time with subtree as well, as part of reviewing this series, using the instructions Sumit provided. It seems OK to me. We have to accept that it adds code and there will be changes/churn, but it is not too different to accepting patches on those files within U-Boot. We will bring in files which U-Boot doesn't use, but U-Boot does support a good proportion of the boards supported by Linux, so I don't see that as a big cost.
From my experimentation, subtrees seem to have no impact on buildman, which is great. Am I missing anything?
No it shouldn't cause any regression on existing tools/CI/build systems. It is just a version controlled way of importing third party source code as a tarball.
I still worry about the board-level 'switch' between U-Boot DT and upstream ones. I believe that should be at the SoC level instead.
Probably I wasn't clear enough in my earlier replies but this series motivates for a SoC level switch only. Patch #7 is essentially a switch for Amlogic meson-gxbb SoC and its derived boards.
OK good...but that's not quite what I mean. You have a fragment like this in multiple defconfig files:
+CONFIG_OF_UPSTREAM=y +CONFIG_DEFAULT_DEVICE_TREE="amlogic/meson-gxbb-odroidc2"
instead, OF_UPSTREAM should be enabled via 'imply' for the SoC, in the Kconfig.
Okay I got your point. It makes sense to me. I will do that for v3.
We should not have to specify the filename like this. It is laborious and error-prone.
The only differentiation in naming here is just silicon vendor prefix addition (amlogic/ in this case). The reason for this being that I just want to mirror the whole silicon vendor directory from DT rebasing rather than mirroring individual DT files. Given this do you have any better alternatives?
-Sumit
Hi Sumit Hi Simon,
On Tue, Dec 26, 2023 at 2:13 AM Sumit Garg sumit.garg@linaro.org wrote:
Hi Simon,
On Tue, 26 Dec 2023 at 15:17, Simon Glass sjg@chromium.org wrote:
Hi Sumit,
On Fri, Dec 22, 2023 at 5:34 AM Sumit Garg sumit.garg@linaro.org wrote:
On Thu, 21 Dec 2023 at 20:48, Simon Glass sjg@chromium.org wrote:
Hi,
On Thu, Dec 21, 2023 at 3:03 PM Tom Rini trini@konsulko.com wrote:
On Thu, Dec 14, 2023 at 07:20:55PM +0530, Sumit Garg wrote:
Prerquisite
This patch series requires devicetree-rebasing git repo to be added as a subtree to the main U-boot repo via:
$ git subtree add --prefix devicetree-rebasing \ git://git.kernel.org/pub/scm/linux/kernel/git/devicetree/devicetree-rebasing.git \ v6.6-dts --squash
So, I've played with subtree a little and I think this is the right way forward in these cases. If anyone wants to take a look at how this works in practice, take a look at: https://source.denx.de/u-boot/u-boot/-/commits/WIP/u-boot-with-devicetree-re... In that tree I started with the v6.1-dts tag, sync'd all the configs (to have an example of a normal commit) and then did a merge of each tag until v6.6-dts, so provide some history. And git log looks like what I want to see, the squash commit has clear references to what we are getting and I make a merge commit that says what I did. If you pull the tree and checkout the branch, all the code is right there already, nothing further to do. Same with tarball releases. The only thing I don't like is the size growth there, but we'll reclaim some of it when we delete our obsolete bindings, and then obsolete dts files.
I spent a bit of time with subtree as well, as part of reviewing this series, using the instructions Sumit provided. It seems OK to me. We have to accept that it adds code and there will be changes/churn, but it is not too different to accepting patches on those files within U-Boot. We will bring in files which U-Boot doesn't use, but U-Boot does support a good proportion of the boards supported by Linux, so I don't see that as a big cost.
From my experimentation, subtrees seem to have no impact on buildman, which is great. Am I missing anything?
No it shouldn't cause any regression on existing tools/CI/build systems. It is just a version controlled way of importing third party source code as a tarball.
I still worry about the board-level 'switch' between U-Boot DT and upstream ones. I believe that should be at the SoC level instead.
Probably I wasn't clear enough in my earlier replies but this series motivates for a SoC level switch only. Patch #7 is essentially a switch for Amlogic meson-gxbb SoC and its derived boards.
OK good...but that's not quite what I mean. You have a fragment like this in multiple defconfig files:
+CONFIG_OF_UPSTREAM=y +CONFIG_DEFAULT_DEVICE_TREE="amlogic/meson-gxbb-odroidc2"
instead, OF_UPSTREAM should be enabled via 'imply' for the SoC, in the Kconfig.
Okay I got your point. It makes sense to me. I will do that for v3.
We should not have to specify the filename like this. It is laborious and error-prone.
The only differentiation in naming here is just silicon vendor prefix addition (amlogic/ in this case). The reason for this being that I just want to mirror the whole silicon vendor directory from DT rebasing rather than mirroring individual DT files. Given this do you have any better alternatives?
So how do we handle the case where the DTS exists in u-boot, but not in Linux? For example, the DTS was developed for u-boot first and has not been accepted in the Linux device tree yet. Can we set in the board defconfig like:
# CONFIG_OF_UPSTREAM is not set
Would that allow the DTS to remain in arch/<architecture>/dts?
Thanks, Tony
Hi Tony,
On Wed, 27 Dec 2023 at 10:11, Tony Dinh mibodhi@gmail.com wrote:
Hi Sumit Hi Simon,
On Tue, Dec 26, 2023 at 2:13 AM Sumit Garg sumit.garg@linaro.org wrote:
Hi Simon,
On Tue, 26 Dec 2023 at 15:17, Simon Glass sjg@chromium.org wrote:
Hi Sumit,
On Fri, Dec 22, 2023 at 5:34 AM Sumit Garg sumit.garg@linaro.org wrote:
On Thu, 21 Dec 2023 at 20:48, Simon Glass sjg@chromium.org wrote:
Hi,
On Thu, Dec 21, 2023 at 3:03 PM Tom Rini trini@konsulko.com wrote:
On Thu, Dec 14, 2023 at 07:20:55PM +0530, Sumit Garg wrote:
> Prerquisite > ----------- > > This patch series requires devicetree-rebasing git repo to be added as a > subtree to the main U-boot repo via: > > $ git subtree add --prefix devicetree-rebasing \ > git://git.kernel.org/pub/scm/linux/kernel/git/devicetree/devicetree-rebasing.git \ > v6.6-dts --squash
So, I've played with subtree a little and I think this is the right way forward in these cases. If anyone wants to take a look at how this works in practice, take a look at: https://source.denx.de/u-boot/u-boot/-/commits/WIP/u-boot-with-devicetree-re... In that tree I started with the v6.1-dts tag, sync'd all the configs (to have an example of a normal commit) and then did a merge of each tag until v6.6-dts, so provide some history. And git log looks like what I want to see, the squash commit has clear references to what we are getting and I make a merge commit that says what I did. If you pull the tree and checkout the branch, all the code is right there already, nothing further to do. Same with tarball releases. The only thing I don't like is the size growth there, but we'll reclaim some of it when we delete our obsolete bindings, and then obsolete dts files.
I spent a bit of time with subtree as well, as part of reviewing this series, using the instructions Sumit provided. It seems OK to me. We have to accept that it adds code and there will be changes/churn, but it is not too different to accepting patches on those files within U-Boot. We will bring in files which U-Boot doesn't use, but U-Boot does support a good proportion of the boards supported by Linux, so I don't see that as a big cost.
From my experimentation, subtrees seem to have no impact on buildman, which is great. Am I missing anything?
No it shouldn't cause any regression on existing tools/CI/build systems. It is just a version controlled way of importing third party source code as a tarball.
I still worry about the board-level 'switch' between U-Boot DT and upstream ones. I believe that should be at the SoC level instead.
Probably I wasn't clear enough in my earlier replies but this series motivates for a SoC level switch only. Patch #7 is essentially a switch for Amlogic meson-gxbb SoC and its derived boards.
OK good...but that's not quite what I mean. You have a fragment like this in multiple defconfig files:
+CONFIG_OF_UPSTREAM=y +CONFIG_DEFAULT_DEVICE_TREE="amlogic/meson-gxbb-odroidc2"
instead, OF_UPSTREAM should be enabled via 'imply' for the SoC, in the Kconfig.
Okay I got your point. It makes sense to me. I will do that for v3.
We should not have to specify the filename like this. It is laborious and error-prone.
The only differentiation in naming here is just silicon vendor prefix addition (amlogic/ in this case). The reason for this being that I just want to mirror the whole silicon vendor directory from DT rebasing rather than mirroring individual DT files. Given this do you have any better alternatives?
So how do we handle the case where the DTS exists in u-boot, but not in Linux? For example, the DTS was developed for u-boot first and has not been accepted in the Linux device tree yet. Can we set in the board defconfig like:
# CONFIG_OF_UPSTREAM is not set
Would that allow the DTS to remain in arch/<architecture>/dts?
Yeah that is expected until DTS becomes available in the DT rebasing tree.
-Sumit
Thanks, Tony
Hi Sumit,
On Tue, Dec 26, 2023 at 10:06 AM Sumit Garg sumit.garg@linaro.org wrote:
Hi Simon,
On Tue, 26 Dec 2023 at 15:17, Simon Glass sjg@chromium.org wrote:
Hi Sumit,
On Fri, Dec 22, 2023 at 5:34 AM Sumit Garg sumit.garg@linaro.org wrote:
On Thu, 21 Dec 2023 at 20:48, Simon Glass sjg@chromium.org wrote:
Hi,
On Thu, Dec 21, 2023 at 3:03 PM Tom Rini trini@konsulko.com wrote:
On Thu, Dec 14, 2023 at 07:20:55PM +0530, Sumit Garg wrote:
Prerquisite
This patch series requires devicetree-rebasing git repo to be added as a subtree to the main U-boot repo via:
$ git subtree add --prefix devicetree-rebasing \ git://git.kernel.org/pub/scm/linux/kernel/git/devicetree/devicetree-rebasing.git \ v6.6-dts --squash
So, I've played with subtree a little and I think this is the right way forward in these cases. If anyone wants to take a look at how this works in practice, take a look at: https://source.denx.de/u-boot/u-boot/-/commits/WIP/u-boot-with-devicetree-re... In that tree I started with the v6.1-dts tag, sync'd all the configs (to have an example of a normal commit) and then did a merge of each tag until v6.6-dts, so provide some history. And git log looks like what I want to see, the squash commit has clear references to what we are getting and I make a merge commit that says what I did. If you pull the tree and checkout the branch, all the code is right there already, nothing further to do. Same with tarball releases. The only thing I don't like is the size growth there, but we'll reclaim some of it when we delete our obsolete bindings, and then obsolete dts files.
I spent a bit of time with subtree as well, as part of reviewing this series, using the instructions Sumit provided. It seems OK to me. We have to accept that it adds code and there will be changes/churn, but it is not too different to accepting patches on those files within U-Boot. We will bring in files which U-Boot doesn't use, but U-Boot does support a good proportion of the boards supported by Linux, so I don't see that as a big cost.
From my experimentation, subtrees seem to have no impact on buildman, which is great. Am I missing anything?
No it shouldn't cause any regression on existing tools/CI/build systems. It is just a version controlled way of importing third party source code as a tarball.
I still worry about the board-level 'switch' between U-Boot DT and upstream ones. I believe that should be at the SoC level instead.
Probably I wasn't clear enough in my earlier replies but this series motivates for a SoC level switch only. Patch #7 is essentially a switch for Amlogic meson-gxbb SoC and its derived boards.
OK good...but that's not quite what I mean. You have a fragment like this in multiple defconfig files:
+CONFIG_OF_UPSTREAM=y +CONFIG_DEFAULT_DEVICE_TREE="amlogic/meson-gxbb-odroidc2"
instead, OF_UPSTREAM should be enabled via 'imply' for the SoC, in the Kconfig.
Okay I got your point. It makes sense to me. I will do that for v3.
We should not have to specify the filename like this. It is laborious and error-prone.
The only differentiation in naming here is just silicon vendor prefix addition (amlogic/ in this case). The reason for this being that I just want to mirror the whole silicon vendor directory from DT rebasing rather than mirroring individual DT files. Given this do you have any better alternatives?
My current opinion is that a better approach would be to move the files first (in the U-Boot tree). That would be easier if we could just copy the Linux arch/xxx/boot/dts Makefiles but for now that is not possible. The Kconfig options for each SoC are similar but there are various differences.
Having a different layout is just a pain and it will get worse, as people add new boards, since they need to know to add the correct directory.
I will see if I can devise a small series to point this in what I consider to be the right direction, in line with Linux, and the U-Boot commit 3284c8b8 ("dts: generate multiple device tree blobs").
Regards, Simon
On Wed, Dec 27, 2023 at 07:56:26AM +0000, Simon Glass wrote:
Hi Sumit,
On Tue, Dec 26, 2023 at 10:06 AM Sumit Garg sumit.garg@linaro.org wrote:
Hi Simon,
On Tue, 26 Dec 2023 at 15:17, Simon Glass sjg@chromium.org wrote:
Hi Sumit,
On Fri, Dec 22, 2023 at 5:34 AM Sumit Garg sumit.garg@linaro.org wrote:
On Thu, 21 Dec 2023 at 20:48, Simon Glass sjg@chromium.org wrote:
Hi,
On Thu, Dec 21, 2023 at 3:03 PM Tom Rini trini@konsulko.com wrote:
On Thu, Dec 14, 2023 at 07:20:55PM +0530, Sumit Garg wrote:
> Prerquisite > ----------- > > This patch series requires devicetree-rebasing git repo to be added as a > subtree to the main U-boot repo via: > > $ git subtree add --prefix devicetree-rebasing \ > git://git.kernel.org/pub/scm/linux/kernel/git/devicetree/devicetree-rebasing.git \ > v6.6-dts --squash
So, I've played with subtree a little and I think this is the right way forward in these cases. If anyone wants to take a look at how this works in practice, take a look at: https://source.denx.de/u-boot/u-boot/-/commits/WIP/u-boot-with-devicetree-re... In that tree I started with the v6.1-dts tag, sync'd all the configs (to have an example of a normal commit) and then did a merge of each tag until v6.6-dts, so provide some history. And git log looks like what I want to see, the squash commit has clear references to what we are getting and I make a merge commit that says what I did. If you pull the tree and checkout the branch, all the code is right there already, nothing further to do. Same with tarball releases. The only thing I don't like is the size growth there, but we'll reclaim some of it when we delete our obsolete bindings, and then obsolete dts files.
I spent a bit of time with subtree as well, as part of reviewing this series, using the instructions Sumit provided. It seems OK to me. We have to accept that it adds code and there will be changes/churn, but it is not too different to accepting patches on those files within U-Boot. We will bring in files which U-Boot doesn't use, but U-Boot does support a good proportion of the boards supported by Linux, so I don't see that as a big cost.
From my experimentation, subtrees seem to have no impact on buildman, which is great. Am I missing anything?
No it shouldn't cause any regression on existing tools/CI/build systems. It is just a version controlled way of importing third party source code as a tarball.
I still worry about the board-level 'switch' between U-Boot DT and upstream ones. I believe that should be at the SoC level instead.
Probably I wasn't clear enough in my earlier replies but this series motivates for a SoC level switch only. Patch #7 is essentially a switch for Amlogic meson-gxbb SoC and its derived boards.
OK good...but that's not quite what I mean. You have a fragment like this in multiple defconfig files:
+CONFIG_OF_UPSTREAM=y +CONFIG_DEFAULT_DEVICE_TREE="amlogic/meson-gxbb-odroidc2"
instead, OF_UPSTREAM should be enabled via 'imply' for the SoC, in the Kconfig.
Okay I got your point. It makes sense to me. I will do that for v3.
We should not have to specify the filename like this. It is laborious and error-prone.
The only differentiation in naming here is just silicon vendor prefix addition (amlogic/ in this case). The reason for this being that I just want to mirror the whole silicon vendor directory from DT rebasing rather than mirroring individual DT files. Given this do you have any better alternatives?
My current opinion is that a better approach would be to move the files first (in the U-Boot tree). That would be easier if we could just copy the Linux arch/xxx/boot/dts Makefiles but for now that is not possible. The Kconfig options for each SoC are similar but there are various differences.
Having a different layout is just a pain and it will get worse, as people add new boards, since they need to know to add the correct directory.
I will see if I can devise a small series to point this in what I consider to be the right direction, in line with Linux, and the U-Boot commit 3284c8b8 ("dts: generate multiple device tree blobs").
I think we should just go with the approach Sumit has already taken, and encourage SoC maintainers to migrate sooner rather than later. There's also nothing stopping people from adding vendor directories under arch/ at that point, and will likely have to happen anyhow for the case of platforms that aren't yet in the devicetree-rebasing tree. I am hopeful it won't be as much of an issue as my general feedback will change from "what kernel release is this dts in?" to "why didn't you set OF_UPSTREAM and use the existing tree?"
Hi Tom,
On Wed, Dec 27, 2023 at 1:37 PM Tom Rini trini@konsulko.com wrote:
On Wed, Dec 27, 2023 at 07:56:26AM +0000, Simon Glass wrote:
Hi Sumit,
On Tue, Dec 26, 2023 at 10:06 AM Sumit Garg sumit.garg@linaro.org wrote:
Hi Simon,
On Tue, 26 Dec 2023 at 15:17, Simon Glass sjg@chromium.org wrote:
Hi Sumit,
On Fri, Dec 22, 2023 at 5:34 AM Sumit Garg sumit.garg@linaro.org wrote:
On Thu, 21 Dec 2023 at 20:48, Simon Glass sjg@chromium.org wrote:
Hi,
On Thu, Dec 21, 2023 at 3:03 PM Tom Rini trini@konsulko.com wrote: > > On Thu, Dec 14, 2023 at 07:20:55PM +0530, Sumit Garg wrote: > > > Prerquisite > > ----------- > > > > This patch series requires devicetree-rebasing git repo to be added as a > > subtree to the main U-boot repo via: > > > > $ git subtree add --prefix devicetree-rebasing \ > > git://git.kernel.org/pub/scm/linux/kernel/git/devicetree/devicetree-rebasing.git \ > > v6.6-dts --squash > > So, I've played with subtree a little and I think this is the right way > forward in these cases. If anyone wants to take a look at how this works > in practice, take a look at: > https://source.denx.de/u-boot/u-boot/-/commits/WIP/u-boot-with-devicetree-re... > In that tree I started with the v6.1-dts tag, sync'd all the configs (to > have an example of a normal commit) and then did a merge of each tag > until v6.6-dts, so provide some history. And git log looks like what I > want to see, the squash commit has clear references to what we are > getting and I make a merge commit that says what I did. If you pull the > tree and checkout the branch, all the code is right there already, > nothing further to do. Same with tarball releases. The only thing I > don't like is the size growth there, but we'll reclaim some of it when > we delete our obsolete bindings, and then obsolete dts files.
I spent a bit of time with subtree as well, as part of reviewing this series, using the instructions Sumit provided. It seems OK to me. We have to accept that it adds code and there will be changes/churn, but it is not too different to accepting patches on those files within U-Boot. We will bring in files which U-Boot doesn't use, but U-Boot does support a good proportion of the boards supported by Linux, so I don't see that as a big cost.
From my experimentation, subtrees seem to have no impact on buildman, which is great. Am I missing anything?
No it shouldn't cause any regression on existing tools/CI/build systems. It is just a version controlled way of importing third party source code as a tarball.
I still worry about the board-level 'switch' between U-Boot DT and upstream ones. I believe that should be at the SoC level instead.
Probably I wasn't clear enough in my earlier replies but this series motivates for a SoC level switch only. Patch #7 is essentially a switch for Amlogic meson-gxbb SoC and its derived boards.
OK good...but that's not quite what I mean. You have a fragment like this in multiple defconfig files:
+CONFIG_OF_UPSTREAM=y +CONFIG_DEFAULT_DEVICE_TREE="amlogic/meson-gxbb-odroidc2"
instead, OF_UPSTREAM should be enabled via 'imply' for the SoC, in the Kconfig.
Okay I got your point. It makes sense to me. I will do that for v3.
We should not have to specify the filename like this. It is laborious and error-prone.
The only differentiation in naming here is just silicon vendor prefix addition (amlogic/ in this case). The reason for this being that I just want to mirror the whole silicon vendor directory from DT rebasing rather than mirroring individual DT files. Given this do you have any better alternatives?
My current opinion is that a better approach would be to move the files first (in the U-Boot tree). That would be easier if we could just copy the Linux arch/xxx/boot/dts Makefiles but for now that is not possible. The Kconfig options for each SoC are similar but there are various differences.
Having a different layout is just a pain and it will get worse, as people add new boards, since they need to know to add the correct directory.
I will see if I can devise a small series to point this in what I consider to be the right direction, in line with Linux, and the U-Boot commit 3284c8b8 ("dts: generate multiple device tree blobs").
I think we should just go with the approach Sumit has already taken, and encourage SoC maintainers to migrate sooner rather than later. There's also nothing stopping people from adding vendor directories under arch/ at that point, and will likely have to happen anyhow for the case of platforms that aren't yet in the devicetree-rebasing tree. I am hopeful it won't be as much of an issue as my general feedback will change from "what kernel release is this dts in?" to "why didn't you set OF_UPSTREAM and use the existing tree?"
OK.
But I do want to see a move to using the same dir structure as Linux.
Regards, Simon
participants (9)
-
Conor Dooley -
Krzysztof Kozlowski -
Michal Simek -
neil.armstrong＠linaro.org -
Rob Herring -
Simon Glass -
Sumit Garg -
Tom Rini -
Tony Dinh