[PATCH v4 00/11] An effort to bring DT bindings compliance within U-Boot

Changes in v4: -------------- - Switched subtree to be imported as dts/upstream sub-directory rather than devicetree-rebasing sub-directory to better suite U-Boot directory structure. - Since we now have v6.7-dts tag available now, so switch subtree to that from its beginning. - Patch #2: Incorporate build fix to adjust Bindings Makefile rules to old U-Boot Kbuild infrastructure. - Patch #3: Incorporate fix to resolve rk3399 migration issue reported by Simon. - Patch #4: New patch to reuse upstream DT includes by U-Boot as per Brian's use-case for TI K3 SoCs. - Patch #5: Added a note to OF_UPSTREAM Kconfig option. - Patch #6: New patch to add script dts/update-dts-subtree.sh as per Rob's comments. - Patch #7: Separate patch to align documentation to use Kconfig symbols instead. - Patch #8: Clarify subtree uprev schedule as a separate documentation section. Also, fixed documentation typos. - Patch #9: Added commit description.
Changes in v3: -------------- - Patch #4: Minor commit message update - Patch #5: Replace CONFIG_* with Kconfig options - Patch #7: Dropped Makefile portion and enabled OF_UPSTREAM for SoC instead. - Patch #1, #3, #6 and #8: Picked up review tags
Changes in v2: -------------- - Patch #1: excluded gitab CI config check and added commit description. - Patch #3: s/UBOOT_DTSI_LOC/u_boot_dtsi_loc/ - Patch #4: s/DEVICE_TREE_LOC/dt_dir/ and s/U-boot/U-Boot/ - Patch #5: s/U-boot/U-Boot/ - Patch #6 and #7: Picked up review tags
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 dts/upstream \ git://git.kernel.org/pub/scm/linux/kernel/git/devicetree/devicetree-rebasing.git \ v6.7-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 `dts/upstream` sub-directory. U-Boot will regularly sync `dts/upstream/` subtree whenever the next window opens with the next available kernel major release. `dts/update-dts-subtree.sh` script provides a wrapper around git subtree pull command, usage from the top level U-Boot source tree, run:
$ ./dts/update-dts-subtree.sh <devicetree-rebasing-release-tag>
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 setting "<name>" when prompted for `DEFAULT_DEVICE_TREE` by Kconfig.
SoC/board maintainers are encouraged to migrate to use synced copies from `dts/upstream/src/<arch>/<vendor>`. To do that enable `OF_UPSTREAM` for the SoC being used via Kconfig and set up "<vendor>/<name>" when prompted for `DEFAULT_DEVICE_TREE` by Kconfig.
An example have been shown for Amlogic meson-gxbb SoC and corresponding derived boards via patch #10 and #11.
Devicetree bindings schema checks ---------------------------------
With devicetee-rebasing Git subtree, the devicetree bindings are also regularly synced with Linux kernel as `dts/upstream/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).
$ apt install yamllint
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 (11): 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 Makefile: Allow upstream DT subtree to provide DT includes dts: Add alternative location for upstream DTB builds dts: Add script to uprev dts/upstream subtree doc: devicetree: Align documentation to use Kconfig options 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 +- .gitlab-ci.yml | 3 +- MAINTAINERS | 5 + Makefile | 23 +- arch/arm/dts/Makefile | 8 - arch/arm/dts/meson-gxbb-kii-pro.dts | 140 ---- arch/arm/dts/meson-gxbb-nanopi-k2.dts | 426 ------------ arch/arm/dts/meson-gxbb-odroidc2.dts | 414 ----------- 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 | 870 ------------------------ arch/arm/mach-meson/Kconfig | 1 + configs/nanopi-k2_defconfig | 2 +- configs/odroid-c2_defconfig | 2 +- configs/p200_defconfig | 2 +- configs/p201_defconfig | 2 +- configs/videostrong-kii-pro_defconfig | 2 +- configs/wetek-hub_defconfig | 2 +- configs/wetek-play2_defconfig | 2 +- doc/develop/devicetree/control.rst | 158 +++-- dts/Kconfig | 16 + dts/Makefile | 17 +- dts/update-dts-subtree.sh | 24 + dts/upstream/Bindings/Makefile | 6 +- dts/upstream/src/arm64/Makefile | 14 + scripts/Makefile.lib | 49 +- 30 files changed, 256 insertions(+), 2780 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 100755 dts/update-dts-subtree.sh create mode 100644 dts/upstream/src/arm64/Makefile

Since devicetree-rebasing is an external repo with its own coding style, exclude it from Azure and gitlab CI CONFIG checks.
Reviewed-by: Tom Rini trini@konsulko.com Reviewed-by: Ilias Apalodimas ilias.apalodimas@linaro.org Reviewed-by: Simon Glass sjg@chromium.org Signed-off-by: Sumit Garg sumit.garg@linaro.org ---
Changes in v4: - Switched subtree to be imported as dts/upstream sub-directory rather than devicetree-rebasing sub-directory to better suite U-Boot directory structure.
Changes in v3: - Picked up review tags
Changes in v2: - excluded gitab CI config check and added commit description.
.azure-pipelines.yml | 3 ++- .gitlab-ci.yml | 3 ++- 2 files changed, 4 insertions(+), 2 deletions(-)
diff --git a/.azure-pipelines.yml b/.azure-pipelines.yml index b9d6aa98a0b..97c88bc2a5e 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/ :^dts/upstream/ && + exit 1 || exit 0
- job: docs displayName: 'Build documentation' diff --git a/.gitlab-ci.yml b/.gitlab-ci.yml index fbf99f0322a..6362f2857c5 100644 --- a/.gitlab-ci.yml +++ b/.gitlab-ci.yml @@ -161,7 +161,8 @@ check for new CONFIG symbols outside Kconfig: # have no matches. - 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/ :^dts/upstream/ && + exit 1 || exit 0
# build documentation docs:

This adds the build infrastructure for checking DT binding schema documents and validating dtb files using the binding schema. Here we use devicetree-rebasing subtree to provide the DT bindings. Along with that adapt dts/upstream/Bindings/Makefile to align with old U-Boot Kbuild infrastructure.
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.
Reviewed-by: Simon Glass sjg@chromium.org Tested-by: Simon Glass sjg@chromium.org Signed-off-by: Sumit Garg sumit.garg@linaro.org ---
Changes in v4: - Switched subtree to be imported as dts/upstream sub-directory rather than devicetree-rebasing sub-directory to better suite U-Boot directory structure. - Incorporate build fix to adjust Bindings Makefile rules to old U-Boot Kbuild infrastructure.
Changes in v3: - None
Changes in v2: - None
Makefile | 20 ++++++++++++++++++-- dts/upstream/Bindings/Makefile | 6 +++--- scripts/Makefile.lib | 17 +++++++++++++++-- 3 files changed, 36 insertions(+), 7 deletions(-)
diff --git a/Makefile b/Makefile index a519397ef71..69cffb16ee2 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 := dts/upstream/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/dts/upstream/Bindings/Makefile b/dts/upstream/Bindings/Makefile index 3e886194b04..e799963a599 100644 --- a/dts/upstream/Bindings/Makefile +++ b/dts/upstream/Bindings/Makefile @@ -47,9 +47,9 @@ quiet_cmd_mk_schema = SCHEMA $@ rm -f $$f
define rule_chkdt - $(if $(DT_SCHEMA_LINT),$(call cmd,yamllint),) - $(call cmd,chk_bindings) - $(call cmd,mk_schema) + $(if $(DT_SCHEMA_LINT),$(call echo-cmd,yamllint) $(cmd_yamllint),); \ + $(call echo-cmd,chk_bindings) $(cmd_chk_bindings); \ + $(call echo-cmd,mk_schema) $(cmd_mk_schema) endef
DT_DOCS = $(patsubst $(srctree)/%,%,$(shell $(find_all_cmd))) diff --git a/scripts/Makefile.lib b/scripts/Makefile.lib index 1ca84195c99..f82b3169e87 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 := dts/upstream/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)

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.
Reviewed-by: Tom Rini trini@konsulko.com Reviewed-by: Simon Glass sjg@chromium.org Reviewed-by: Ilias Apalodimas ilias.apalodimas@linaro.org Signed-off-by: Sumit Garg sumit.garg@linaro.org ---
Changes in v4: - Incorporate fix to resolve rk3399 migration issue reported by Simon.
Changes in v3: - Picked up review tags
Changes in v2: - s/UBOOT_DTSI_LOC/u_boot_dtsi_loc/
scripts/Makefile.lib | 27 +++++++++++++++------------ 1 file changed, 15 insertions(+), 12 deletions(-)
diff --git a/scripts/Makefile.lib b/scripts/Makefile.lib index f82b3169e87..fe2a0aadc41 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)) +u_boot_dtsi_loc = $(srctree)/arch/$(ARCH)/dts/ + +u_boot_dtsi_options = $(strip $(wildcard $(u_boot_dtsi_loc)$(basename $(notdir $<))-u-boot.dtsi) \ + $(wildcard $(u_boot_dtsi_loc)$(subst $",,$(CONFIG_SYS_SOC))-u-boot.dtsi) \ + $(wildcard $(u_boot_dtsi_loc)$(subst $",,$(CONFIG_SYS_CPU))-u-boot.dtsi) \ + $(wildcard $(u_boot_dtsi_loc)$(subst $",,$(CONFIG_SYS_VENDOR))-u-boot.dtsi) \ + $(wildcard $(u_boot_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 ... \ + $(u_boot_dtsi_loc)$(basename $(notdir $<))-u-boot.dtsi \ + $(u_boot_dtsi_loc)$(subst $",,$(CONFIG_SYS_SOC))-u-boot.dtsi \ + $(u_boot_dtsi_loc)$(subst $",,$(CONFIG_SYS_CPU))-u-boot.dtsi \ + $(u_boot_dtsi_loc)$(subst $",,$(CONFIG_SYS_VENDOR))-u-boot.dtsi \ + $(u_boot_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$(u_boot_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 $(u_boot_dtsi_loc) $(DTC_FLAGS) \ -d $(depfile).dtc.tmp $(dtc-tmp) || \ (echo "Check $(shell pwd)/$(pre-tmp) for errors" && false) \ ; \ @@ -354,7 +357,7 @@ ifdef CONFIG_EFI_CAPSULE_AUTHENTICATE dtsi_include_list += $(capsule_esl_dtsi) endif
-dtsi_include_list_deps = $(addprefix $(obj)/,$(subst $(quote),,$(dtsi_include_list))) +dtsi_include_list_deps = $(addprefix $(u_boot_dtsi_loc),$(subst $(quote),,$(dtsi_include_list)))
ifneq ($(CHECK_DTBS),) DT_CHECKER ?= dt-validate

Allow platforms to reuse DT headers and dtsi includes directly form upstream DT subtree which will be frequently synced with Linux kernel. This will further allow us to drop corresponding DT includes copy from U-Boot tree.
Also, since the DT includes from upstream DT subtree are done after DT includes from U-Boot tree, so it shouldn't cause any conflicts.
Tested-by: Bryan Brattlof bb@ti.com Signed-off-by: Sumit Garg sumit.garg@linaro.org ---
Changes in v4: - New patch to reuse upstream DT includes by U-Boot as per Brian's use-case for TI K3 SoCs.
Makefile | 3 ++- scripts/Makefile.lib | 5 +++++ 2 files changed, 7 insertions(+), 1 deletion(-)
diff --git a/Makefile b/Makefile index 69cffb16ee2..d4e65ffe49f 100644 --- a/Makefile +++ b/Makefile @@ -835,7 +835,8 @@ UBOOTINCLUDE := \ -I$(srctree)/arch/arm/thumb1/include), \ -I$(srctree)/arch/arm/thumb1/include)) \ -I$(srctree)/arch/$(ARCH)/include \ - -include $(srctree)/include/linux/kconfig.h + -include $(srctree)/include/linux/kconfig.h \ + -I$(srctree)/dts/upstream/include
NOSTDINC_FLAGS += -nostdinc -isystem $(shell $(CC) -print-file-name=include)
diff --git a/scripts/Makefile.lib b/scripts/Makefile.lib index fe2a0aadc41..fbcaf335f9a 100644 --- a/scripts/Makefile.lib +++ b/scripts/Makefile.lib @@ -189,12 +189,17 @@ dtsi_include_list = $(strip $(u_boot_dtsi_options_debug) \ dtsi_include_list += $(CONFIG_DEVICE_TREE_INCLUDES)
# Modified for U-Boot +upstream_dtsi_include = $(addprefix -I, $(srctree)/dts/upstream/src/ \ + $(sort $(dir $(wildcard $(srctree)/dts/upstream/src/$(ARCH)/*/*))) \ + $(if (CONFIG_ARM64), \ + $(sort $(dir $(wildcard $(srctree)/dts/upstream/src/arm64/*/*))))) dtc_cpp_flags = -Wp,-MD,$(depfile).pre.tmp -nostdinc \ $(UBOOTINCLUDE) \ -I$(dir $<) \ -I$(u_boot_dtsi_loc) \ -I$(srctree)/arch/$(ARCH)/dts/include \ -I$(srctree)/include \ + $(upstream_dtsi_include) \ -D__ASSEMBLY__ \ -undef -D__DTS__

Allow platform owners to mirror devicetree files from devitree-rebasing directory into dts/upstream/src/$(ARCH) (special case for 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 ---
Changes in v4: - Switched subtree to be imported as dts/upstream sub-directory rather than devicetree-rebasing sub-directory to better suite U-Boot directory structure. - Added a note to OF_UPSTREAM Kconfig option.
Changes in v3: - Minor commit message update
Changes in v2: - s/DEVICE_TREE_LOC/dt_dir/ and s/U-boot/U-Boot/
dts/Kconfig | 16 ++++++++++++++++ dts/Makefile | 17 ++++++++++++++--- dts/upstream/src/arm64/Makefile | 14 ++++++++++++++ 3 files changed, 44 insertions(+), 3 deletions(-) create mode 100644 dts/upstream/src/arm64/Makefile
diff --git a/dts/Kconfig b/dts/Kconfig index 00c0aeff893..09789d3e18b 100644 --- a/dts/Kconfig +++ b/dts/Kconfig @@ -85,6 +85,22 @@ 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. + + Note: This option should be set in Kconfig, for the SoC as a whole. + However, newer boards whose devicetree source files haven't landed in + the dts/upstream subtree, they can override this option to have the + DT build from existing U-Boot tree location instead. + choice prompt "Provider of DTB for DT control" depends on OF_CONTROL diff --git a/dts/Makefile b/dts/Makefile index 3437e54033d..d6c2c9daf31 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) +dt_dir := dts/upstream/src/arm64 +else +dt_dir := dts/upstream/src/$(ARCH) +endif +else +dt_dir := arch/$(ARCH)/dts +endif + ifneq ($(EXT_DTB),) DTB := $(EXT_DTB) else -DTB := arch/$(ARCH)/dts/$(DEVICE_TREE).dtb +DTB := $(dt_dir)/$(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)=$(dt_dir) 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 \ + ./upstream/src/arm64 ./upstream/src/$(ARCH) diff --git a/dts/upstream/src/arm64/Makefile b/dts/upstream/src/arm64/Makefile new file mode 100644 index 00000000000..9a8f6aa3584 --- /dev/null +++ b/dts/upstream/src/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

dts/update-dts-subtree.sh is just a wrapper around git subtree pull command. Usage from the top level U-Boot source tree, run:
$ ./dts/update-dts-subtree.sh <release-tag>
Signed-off-by: Sumit Garg sumit.garg@linaro.org ---
Changes in v4: - New patch to add script dts/update-dts-subtree.sh as per Rob's comments.
dts/update-dts-subtree.sh | 24 ++++++++++++++++++++++++ 1 file changed, 24 insertions(+) create mode 100755 dts/update-dts-subtree.sh
diff --git a/dts/update-dts-subtree.sh b/dts/update-dts-subtree.sh new file mode 100755 index 00000000000..2077094d0d2 --- /dev/null +++ b/dts/update-dts-subtree.sh @@ -0,0 +1,24 @@ +#!/bin/sh +# SPDX-License-Identifier: GPL-2.0+ +# +# Copyright 2024 Linaro Ltd. +# +# Usage: from the top level U-Boot source tree, run: +# $ ./dts/update-dts-subtree.sh <release-tag> +# +# The script will pull changes from devicetree-rebasing repo into U-Boot +# as a subtree located as <U-Boot>/dts/upstream sub-directory. It will +# automatically create a squash/merge commit listing the commits imported. + +set -e + +merge_commit_msg=$(cat << EOF +Subtree merge tag '$1' of devicetree-rebasing repo [1] into dts/upstream + +[1] https://git.kernel.org/pub/scm/linux/kernel/git/devicetree/devicetree-rebasi... +EOF +) + +git subtree pull --prefix dts/upstream \ + git://git.kernel.org/pub/scm/linux/kernel/git/devicetree/devicetree-rebasing.git \ + $1 --squash -m "${merge_commit_msg}"

Since U-Boot switched away from manual CONFIG_* defines to Kconfig options, align devicetree documentation accordingly.
Signed-off-by: Sumit Garg sumit.garg@linaro.org ---
Changes in v4: - Separate patch to align documentation to use Kconfig symbols instead.
doc/develop/devicetree/control.rst | 50 ++++++++++++++---------------- 1 file changed, 23 insertions(+), 27 deletions(-)
diff --git a/doc/develop/devicetree/control.rst b/doc/develop/devicetree/control.rst index 11c92d440f4..75d5e02aaec 100644 --- a/doc/develop/devicetree/control.rst +++ b/doc/develop/devicetree/control.rst @@ -29,7 +29,7 @@ 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. +To enable this feature, select `OF_CONTROL` via Kconfig.
What is a Flattened Devicetree? @@ -81,12 +81,8 @@ Failing that, you could write one from scratch yourself! Configuration -------------
-Use:: - - #define CONFIG_DEFAULT_DEVICE_TREE "<name>" - -to set the filename of the devicetree source. Then put your devicetree -file into:: +Set up "<name>" when prompted for `DEFAULT_DEVICE_TREE` by Kconfig. Then put +your devicetree file into::
arch/<arch>/dts/<name>.dts
@@ -94,24 +90,24 @@ 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.
-If CONFIG_OF_EMBED is defined, then it will be picked up and built into +If `OF_EMBED` is selected by Kconfig, then it will be picked up and built into the U-Boot image (including u-boot.bin). This is suitable for debugging and development only and is not recommended for production devices.
-If CONFIG_OF_SEPARATE is defined, then it will be built and placed in +If `OF_SEPARATE` is selected by Kconfig, then it will be built and placed in a u-boot.dtb file alongside u-boot-nodtb.bin with the combined result placed -in u-boot.bin so you can still just flash u-boot.bin onto your board. If you are -using CONFIG_SPL_FRAMEWORK, then u-boot.img will be built to include the device -tree binary. +in u-boot.bin so you can still just flash u-boot.bin onto your board. If Kconfig +option `SPL_FRAMEWORK` is enabled, then u-boot.img will be built to include the +device tree binary.
-If CONFIG_OF_BOARD is defined, a board-specific routine will provide the +If `OF_BOARD` is selected by Kconfig, a board-specific routine will provide the devicetree at runtime, for example if an earlier bootloader stage creates it and passes it to U-Boot.
-If CONFIG_BLOBLIST is defined, the devicetree may come from a bloblist passed -from a previous stage, if present. +If `BLOBLIST` is selected by Kconfig, the devicetree may come from a bloblist +passed from a previous stage, if present.
-If CONFIG_SANDBOX is defined, then it will be read from a file on +If `SANDBOX` is selected by Kconfig, then it will be read from a file on startup. Use the -d flag to U-Boot to specify the file to read, -D for the default and -T for the test devicetree, used to run sandbox unit tests.
@@ -145,7 +141,7 @@ Build: After the board configuration is done, fdt supported u-boot can be built in two ways:
-# build the default dts which is defined from CONFIG_DEFAULT_DEVICE_TREE:: +# build the default dts which is selected by DEFAULT_DEVICE_TREE Kconfig::
$ make
@@ -198,8 +194,8 @@ As mentioned above, the U-Boot build system automatically includes a `*-u-boot.dtsi` file, if found, containing U-Boot specific quirks. However, some data, such as the mentioned public keys, are not appropriate for upstream U-Boot but are better kept and maintained -outside the U-Boot repository. You can use CONFIG_DEVICE_TREE_INCLUDES -to specify a list of .dtsi files that will also be included when +outside the U-Boot repository. You can use `DEVICE_TREE_INCLUDES` Kconfig +option to specify a list of .dtsi files that will also be included when building .dtb files.
@@ -213,14 +209,14 @@ The full devicetree is available to U-Boot proper, but normally only a subset 'SPL Support' in doc/driver-model/design.rst for more details.
-Using several DTBs in the SPL (CONFIG_SPL_MULTI_DTB) ----------------------------------------------------- +Using several DTBs in the SPL (SPL_MULTI_DTB_FIT Kconfig option) +---------------------------------------------------------------- In some rare cases it is desirable to let SPL be able to select one DTB among many. This usually not very useful as the DTB for the SPL is small and usually fits several platforms. However the DTB sometimes include information that do work on several platforms (like IO tuning parameters). -In this case it is possible to use CONFIG_SPL_MULTI_DTB. This option appends to -the SPL a FIT image containing several DTBs listed in SPL_OF_LIST. +In this case it is possible to use SPL_MULTI_DTB_FIT Kconfig option. This option +appends to the SPL a FIT image containing several DTBs listed in SPL_OF_LIST. board_fit_config_name_match() is called to select the right DTB.
If board_fit_config_name_match() relies on DM (DM driver to access an EEPROM @@ -247,16 +243,16 @@ architectures.
It is important to understand that the fdt only selects options available in the platform / drivers. It cannot add new drivers (yet). So -you must still have the CONFIG option to enable the driver. For example, -you need to define CONFIG_SYS_NS16550 to bring in the NS16550 driver, +you must still have the Kconfig option to enable the driver. For example, +you need to enable SYS_NS16550 Kconfig option to bring in the NS16550 driver, but can use the fdt to specific the UART clock, peripheral address, etc. -In very broad terms, the CONFIG options in general control *what* driver +In very broad terms, the Kconfig options in general control *what* driver files are pulled in, and the fdt controls *how* those files work.
History -------
-U-Boot configuration was previous done using CONFIG options in the board +U-Boot configuration was previous done using Kconfig options in the board config file. This eventually got out of hand with nearly 10,000 options.
U-Boot adopted devicetrees around the same time as Linux and early boards

On Wed, Jan 10, 2024 at 7:37 AM Sumit Garg sumit.garg@linaro.org wrote:
History
-U-Boot configuration was previous done using CONFIG options in the board +U-Boot configuration was previous done using Kconfig options in the board config file. This eventually got out of hand with nearly 10,000 options.
It seems that the original text should be preserved here.

On Wed, 10 Jan 2024 at 18:01, Fabio Estevam festevam@gmail.com wrote:
On Wed, Jan 10, 2024 at 7:37 AM Sumit Garg sumit.garg@linaro.org wrote:
History
-U-Boot configuration was previous done using CONFIG options in the board +U-Boot configuration was previous done using Kconfig options in the board config file. This eventually got out of hand with nearly 10,000 options.
It seems that the original text should be preserved here.
Ah, you are right. I can preserve that in the next spin if I receive further feedback otherwise I hope Tom can fix it up while applying.
-Sumit

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 ---
Changes in v4: - Switched subtree to be imported as dts/upstream sub-directory rather than devicetree-rebasing sub-directory to better suite U-Boot directory structure. - Since we now have v6.7-dts tag available now, so switch subtree to that from its beginning. - Clarify subtree uprev schedule as a separate documentation section. Also, fixed documentation typos.
Changes in v3: - Replace CONFIG_* with Kconfig options
Changes in v2: - s/U-boot/U-Boot/
doc/develop/devicetree/control.rst | 112 +++++++++++++++++++++++------ 1 file changed, 92 insertions(+), 20 deletions(-)
diff --git a/doc/develop/devicetree/control.rst b/doc/develop/devicetree/control.rst index 75d5e02aaec..c8789ef7209 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-2024 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, select `OF_CONTROL` via Kconfig.
@@ -68,8 +68,14 @@ 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 intermediate release candidates. + +U-Boot maintains a Git subtree for devicetee-rebasing repo as `dts/upstream/` +sub-directory. You may find that the `dts/upstream/` sub-directory has a +suitable devicetree file for your board. Look in `dts/upstream/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 @@ -78,17 +84,33 @@ modify to your needs. Look in the board directories for files with a Failing that, you could write one from scratch yourself!
+Resyncing with devicetree-rebasing +---------------------------------- + +U-Boot regularly sync `dts/upstream/` subtree whenever the next window opens +with the next available kernel major release. `dts/update-dts-subtree.sh` script +provides a wrapper around git subtree pull command, usage from the top level +U-Boot source tree, run:: + + ./dts/update-dts-subtree.sh <devicetree-rebasing-release-tag> + + Configuration -------------
-Set up "<name>" when prompted for `DEFAULT_DEVICE_TREE` by Kconfig. Then put -your devicetree file into:: +Traditionally, U-Boot placed copies of devicetree source files from Linux +kernel into `arch/<arch>/dts/<name>.dts` which can be selected via setting +"<name>" when prompted for `DEFAULT_DEVICE_TREE` by Kconfig.
- arch/<arch>/dts/<name>.dts +However, it has become cumbersome over time for each SoC/board maintainer to +keep devicetree files in sync with Linux kernel. Therefore, SoC/board +maintainers are encouraged to migrate to use synced copies from +`dts/upstream/src/<arch>/<vendor>`. To do that enable `OF_UPSTREAM` for the +SoC being used via Kconfig and set up "<vendor>/<name>" when prompted for +`DEFAULT_DEVICE_TREE` by Kconfig.
-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 `OF_EMBED` is selected by Kconfig, then it will be picked up and built into the U-Boot image (including u-boot.bin). This is suitable for debugging @@ -155,8 +177,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 `dts/upstream` Git subtree, it is ensured that devicetree files in U-Boot +are an exact copy of those in Linux kernel available under +`dts/upstream/src/<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 @@ -169,8 +192,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 @@ -199,6 +222,54 @@ option 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 `dts/upstream/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. Please, refer to the GCC build documentation for installation +instructions :doc:`../../build/gcc`. + +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). On +Debian/Ubuntu systems:: + + apt install yamllint + +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 -----------------------
@@ -260,8 +331,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...

Add myself as devicetree-rebasing maintainer.
Reviewed-by: Simon Glass sjg@chromium.org Reviewed-by: Ilias Apalodimas ilias.apalodimas@linaro.org Signed-off-by: Sumit Garg sumit.garg@linaro.org ---
Changes in v4: - Switched subtree to be imported as dts/upstream sub-directory rather than devicetree-rebasing sub-directory to better suite U-Boot directory structure. - Added commit description.
Changes in v3: - Picked up review tags
Changes in v2: - Picked up review tags
MAINTAINERS | 5 +++++ 1 file changed, 5 insertions(+)
diff --git a/MAINTAINERS b/MAINTAINERS index 4fec063a242..39b5c01a5e0 100644 --- a/MAINTAINERS +++ b/MAINTAINERS @@ -957,6 +957,11 @@ 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: dts/upstream/ + DFU M: Lukasz Majewski lukma@denx.de M: Mattijs Korpershoek mkorpershoek@baylibre.com

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 enable OF_UPSTREAM to use upstream DT and add amlogic/ prefix to the DEFAULT_DEVICE_TREE. And thereby directly build DTB from dts/upstream/src/ including *-u-boot.dtsi files from arch/$(ARCH)/dts/ directory.
Reviewed-by: Neil Armstrong neil.armstrong@linaro.org Reviewed-by: Simon Glass sjg@chromium.org Signed-off-by: Sumit Garg sumit.garg@linaro.org ---
Changes in v4: - Picked up review tag
Changes in v3: - Dropped Makefile portion and enabled OF_UPSTREAM for SoC instead.
Changes in v2: - Picked up review tag
arch/arm/mach-meson/Kconfig | 1 + configs/nanopi-k2_defconfig | 2 +- configs/odroid-c2_defconfig | 2 +- configs/p200_defconfig | 2 +- configs/p201_defconfig | 2 +- configs/videostrong-kii-pro_defconfig | 2 +- configs/wetek-hub_defconfig | 2 +- configs/wetek-play2_defconfig | 2 +- 8 files changed, 8 insertions(+), 7 deletions(-)
diff --git a/arch/arm/mach-meson/Kconfig b/arch/arm/mach-meson/Kconfig index d6c89058061..8ddb59161a0 100644 --- a/arch/arm/mach-meson/Kconfig +++ b/arch/arm/mach-meson/Kconfig @@ -25,6 +25,7 @@ choice config MESON_GXBB bool "GXBB" select MESON_GX + imply OF_UPSTREAM help Select this if your SoC is an S905
diff --git a/configs/nanopi-k2_defconfig b/configs/nanopi-k2_defconfig index 41dbf7981f8..2e1c756bf7a 100644 --- a/configs/nanopi-k2_defconfig +++ b/configs/nanopi-k2_defconfig @@ -6,7 +6,7 @@ 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_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..ce5eaec3cd2 100644 --- a/configs/odroid-c2_defconfig +++ b/configs/odroid-c2_defconfig @@ -6,7 +6,7 @@ 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_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..b6946034795 100644 --- a/configs/p200_defconfig +++ b/configs/p200_defconfig @@ -6,7 +6,7 @@ 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_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..dcc1454be16 100644 --- a/configs/p201_defconfig +++ b/configs/p201_defconfig @@ -7,7 +7,7 @@ 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_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..7a5af234471 100644 --- a/configs/videostrong-kii-pro_defconfig +++ b/configs/videostrong-kii-pro_defconfig @@ -6,7 +6,7 @@ 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_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..85cff73f50f 100644 --- a/configs/wetek-hub_defconfig +++ b/configs/wetek-hub_defconfig @@ -6,7 +6,7 @@ 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_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..efdf820165b 100644 --- a/configs/wetek-play2_defconfig +++ b/configs/wetek-play2_defconfig @@ -6,7 +6,7 @@ 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_DEFAULT_DEVICE_TREE="amlogic/meson-gxbb-wetek-play2" CONFIG_OF_LIBFDT_OVERLAY=y CONFIG_DM_RESET=y CONFIG_DEBUG_UART_BASE=0xc81004c0

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.
Reviewed-by: Neil Armstrong neil.armstrong@linaro.org Signed-off-by: Sumit Garg sumit.garg@linaro.org ---
Changes in v4: - None
Changes in v3: - Picked up review tag
Changes in v2: - None
arch/arm/dts/Makefile | 8 - arch/arm/dts/meson-gxbb-kii-pro.dts | 140 ---- arch/arm/dts/meson-gxbb-nanopi-k2.dts | 426 ------------ arch/arm/dts/meson-gxbb-odroidc2.dts | 414 ----------- 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 | 870 ------------------------ 11 files changed, 2703 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 773c2546131..19b6823975f 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 7d94160f580..00000000000 --- a/arch/arm/dts/meson-gxbb-nanopi-k2.dts +++ /dev/null @@ -1,426 +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 = "okay"; - pinctrl-0 = <&uart_a_pins>, <&uart_a_cts_rts_pins>; - pinctrl-names = "default"; - uart-has-rtscts; - - bluetooth { - compatible = "brcm,bcm43438-bt"; - clocks = <&wifi_32k>; - clock-names = "lpo"; - vbat-supply = <&vddio_ao3v3>; - vddio-supply = <&vddio_ao18>; - host-wakeup-gpios = <&gpio GPIOX_21 GPIO_ACTIVE_HIGH>; - shutdown-gpios = <&gpio GPIOX_20 GPIO_ACTIVE_HIGH>; - }; -}; - -/* 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 01356437a07..00000000000 --- a/arch/arm/dts/meson-gxbb-odroidc2.dts +++ /dev/null @@ -1,414 +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>; - }; - }; -}; - -&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 { - dr_mode = "host"; - #address-cells = <1>; - #size-cells = <0>; - status = "okay"; - - hub@1 { - /* Genesys Logic GL852G USB 2.0 hub */ - compatible = "usb5e3,610"; - reg = <1>; - vdd-supply = <&p5v0>; - reset-gpio = <&gpio_ao GPIOAO_4 GPIO_ACTIVE_LOW>; - }; -}; 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 12ef6e81c8b..00000000000 --- a/arch/arm/dts/meson-gxbb.dtsi +++ /dev/null @@ -1,870 +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-gxbb-gpio-intc", - "amlogic,meson-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_idle_high_pins: spi-idle-high-pins { - mux { - groups = "spi_sclk"; - bias-pull-up; - }; - }; - - spi_idle_low_pins: spi-idle-low-pins { - mux { - groups = "spi_sclk"; - bias-pull-down; - }; - }; - - 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"; -};

On 16:05-20240110, Sumit Garg wrote: [...]
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 dts/upstream \ git://git.kernel.org/pub/scm/linux/kernel/git/devicetree/devicetree-rebasing.git \
Please use https://
also what is the baseline? didn't seem to apply on (fails at patch #2): next f28a77589e75 Merge tag 'dm-next-7jan23' of https://source.denx.de/u-boot/custodians/u-boot-dm into next master f7cca7ccc511 Revert "test: hush: dollar: fix bugous behavior"

Hi Nishanth,
Apologies for the delayed response as I was on a long weekend vacation.
On Fri, 19 Jan 2024 at 21:27, Nishanth Menon nm@ti.com wrote:
On 16:05-20240110, Sumit Garg wrote: [...]
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 dts/upstream \ git://git.kernel.org/pub/scm/linux/kernel/git/devicetree/devicetree-rebasing.git \
Please use https://
Okay I can do that given the widespread use of https://
also what is the baseline? didn't seem to apply on (fails at patch #2): next f28a77589e75 Merge tag 'dm-next-7jan23' of https://source.denx.de/u-boot/custodians/u-boot-dm into next master f7cca7ccc511 Revert "test: hush: dollar: fix bugous behavior"
Okay looks like recent merges caused conflicts, needs a rebase. However, for v4 you can use this branch [1] for testing.
[1] https://github.com/b49020/u-boot/tree/v4_dt
-Sumit
-- Regards, Nishanth Menon Key (0xDDB5849D1736249D) / Fingerprint: F8A2 8693 54EB 8232 17A3 1A34 DDB5 849D 1736 249D

On 1/10/24 11:35, Sumit Garg wrote:
Changes in v4:
- Switched subtree to be imported as dts/upstream sub-directory rather than devicetree-rebasing sub-directory to better suite U-Boot directory structure.
- Since we now have v6.7-dts tag available now, so switch subtree to that from its beginning.
- Patch #2: Incorporate build fix to adjust Bindings Makefile rules to old U-Boot Kbuild infrastructure.
- Patch #3: Incorporate fix to resolve rk3399 migration issue reported by Simon.
- Patch #4: New patch to reuse upstream DT includes by U-Boot as per Brian's use-case for TI K3 SoCs.
- Patch #5: Added a note to OF_UPSTREAM Kconfig option.
- Patch #6: New patch to add script dts/update-dts-subtree.sh as per Rob's comments.
- Patch #7: Separate patch to align documentation to use Kconfig symbols instead.
- Patch #8: Clarify subtree uprev schedule as a separate documentation section. Also, fixed documentation typos.
- Patch #9: Added commit description.
Changes in v3:
- Patch #4: Minor commit message update
- Patch #5: Replace CONFIG_* with Kconfig options
- Patch #7: Dropped Makefile portion and enabled OF_UPSTREAM for SoC instead.
- Patch #1, #3, #6 and #8: Picked up review tags
Changes in v2:
- Patch #1: excluded gitab CI config check and added commit description.
- Patch #3: s/UBOOT_DTSI_LOC/u_boot_dtsi_loc/
- Patch #4: s/DEVICE_TREE_LOC/dt_dir/ and s/U-boot/U-Boot/
- Patch #5: s/U-boot/U-Boot/
- Patch #6 and #7: Picked up review tags
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 dts/upstream \ git://git.kernel.org/pub/scm/linux/kernel/git/devicetree/devicetree-rebasing.git \ v6.7-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 `dts/upstream` sub-directory. U-Boot will regularly sync `dts/upstream/` subtree whenever the next window opens with the next available kernel major release. `dts/update-dts-subtree.sh` script provides a wrapper around git subtree pull command, usage from the top level U-Boot source tree, run:
$ ./dts/update-dts-subtree.sh <devicetree-rebasing-release-tag>
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.
I very much agree with the direction this is going in, but I do have two simple questions:
How do you propose to handle fixes to DTs which are applied to linux-stable releases ? For example, if Linux 6.6(.0) ships a DT which has some defect that is fixed in 6.6.1, how will that fix get into U-Boot DTs ?
Assume that there is some large breaking change in Linux 6.(n+1), something which would be problematic for specific U-Boot platform (e.g. i.MX) or would require a lot of work to sort out, will there be a way to temporarily pin DTs for specific platform to older DT version until that is resolved (e.g. pin to 6.n) ?

On 21/01/2024 15:33, Marek Vasut wrote:
On 1/10/24 11:35, Sumit Garg wrote:
Changes in v4:
- Switched subtree to be imported as dts/upstream sub-directory rather
than devicetree-rebasing sub-directory to better suite U-Boot directory structure.
- Since we now have v6.7-dts tag available now, so switch subtree to
that from its beginning.
- Patch #2: Incorporate build fix to adjust Bindings Makefile rules to
old U-Boot Kbuild infrastructure.
- Patch #3: Incorporate fix to resolve rk3399 migration issue reported
by Simon.
- Patch #4: New patch to reuse upstream DT includes by U-Boot as per
Brian's use-case for TI K3 SoCs.
- Patch #5: Added a note to OF_UPSTREAM Kconfig option.
- Patch #6: New patch to add script dts/update-dts-subtree.sh as per
Rob's comments.
- Patch #7: Separate patch to align documentation to use Kconfig symbols
instead.
- Patch #8: Clarify subtree uprev schedule as a separate documentation
section. Also, fixed documentation typos.
- Patch #9: Added commit description.
Changes in v3:
- Patch #4: Minor commit message update
- Patch #5: Replace CONFIG_* with Kconfig options
- Patch #7: Dropped Makefile portion and enabled OF_UPSTREAM for SoC
instead.
- Patch #1, #3, #6 and #8: Picked up review tags
Changes in v2:
- Patch #1: excluded gitab CI config check and added commit description.
- Patch #3: s/UBOOT_DTSI_LOC/u_boot_dtsi_loc/
- Patch #4: s/DEVICE_TREE_LOC/dt_dir/ and s/U-boot/U-Boot/
- Patch #5: s/U-boot/U-Boot/
- Patch #6 and #7: Picked up review tags
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 dts/upstream \
git://git.kernel.org/pub/scm/linux/kernel/git/devicetree/devicetree-rebasing.git \ v6.7-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 `dts/upstream` sub-directory. U-Boot will regularly sync `dts/upstream/` subtree whenever the next window opens with the next available kernel major release. `dts/update-dts-subtree.sh` script provides a wrapper around git subtree pull command, usage from the top level U-Boot source tree, run:
$ ./dts/update-dts-subtree.sh <devicetree-rebasing-release-tag>
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.
I very much agree with the direction this is going in, but I do have two simple questions:
How do you propose to handle fixes to DTs which are applied to linux-stable releases ? For example, if Linux 6.6(.0) ships a DT which has some defect that is fixed in 6.6.1, how will that fix get into U-Boot DTs ?
This fix would also be in the latest Linux tags, so I think it would find its way here - as I understand it patches aren't accepted into Linux stable unless they land in torvalds tree.
Assume that there is some large breaking change in Linux 6.(n+1), something which would be problematic for specific U-Boot platform (e.g. i.MX) or would require a lot of work to sort out, will there be a way to temporarily pin DTs for specific platform to older DT version until that is resolved (e.g. pin to 6.n) ?
(Upstream) devicetree has to be forwards and backwards compatible, were such a breaking change to get merged without prior discussion with DT users (i.e. U-Boot) then I think the correct course of action would be to revert it.
On a tangential note: as I understand it, DTs built from dt-rebasing are still subject to U-Boot customisations via the "-u-boot.dtsi" include files, this allows for dealing with incompatibilities due to missing features in U-Boot.

On Sun, Jan 21, 2024 at 10:41:51PM +0000, Caleb Connolly wrote:
On 21/01/2024 15:33, Marek Vasut wrote:
[snip]
Assume that there is some large breaking change in Linux 6.(n+1), something which would be problematic for specific U-Boot platform (e.g. i.MX) or would require a lot of work to sort out, will there be a way to temporarily pin DTs for specific platform to older DT version until that is resolved (e.g. pin to 6.n) ?
(Upstream) devicetree has to be forwards and backwards compatible, were such a breaking change to get merged without prior discussion with DT users (i.e. U-Boot) then I think the correct course of action would be to revert it.
The caveat is "unless it was wrong before", which happens more often than is generally thought of I think. I'm not sure off-hand the best way to deal with that.

On Mon, 22 Jan 2024 at 05:31, Tom Rini trini@konsulko.com wrote:
On Sun, Jan 21, 2024 at 10:41:51PM +0000, Caleb Connolly wrote:
On 21/01/2024 15:33, Marek Vasut wrote:
[snip]
Assume that there is some large breaking change in Linux 6.(n+1), something which would be problematic for specific U-Boot platform (e.g. i.MX) or would require a lot of work to sort out, will there be a way to temporarily pin DTs for specific platform to older DT version until that is resolved (e.g. pin to 6.n) ?
(Upstream) devicetree has to be forwards and backwards compatible, were such a breaking change to get merged without prior discussion with DT users (i.e. U-Boot) then I think the correct course of action would be to revert it.
The caveat is "unless it was wrong before", which happens more often than is generally thought of I think. I'm not sure off-hand the best way to deal with that.
I think that's the reason we just want to pull DT at once in the beginning of the next window and allow U-Boot developers/maintainers to detect and fix problems during the full U-Boot release cycle. However, we are open to discussions for a revert if there is a major DT ABI break among Linux major (.0) releases affecting many U-Boot platforms.
-Sumit
-- Tom

On 1/21/24 23:41, Caleb Connolly wrote:
Hi,
[...]
How do you propose to handle fixes to DTs which are applied to linux-stable releases ? For example, if Linux 6.6(.0) ships a DT which has some defect that is fixed in 6.6.1, how will that fix get into U-Boot DTs ?
This fix would also be in the latest Linux tags, so I think it would find its way here - as I understand it patches aren't accepted into Linux stable unless they land in torvalds tree.
See the devicetree-rebasing.git:
https://git.kernel.org/pub/scm/linux/kernel/git/devicetree/devicetree-rebasi...
That only contains refs for release versions (v6.6-dts, v6.7-dts etc), not any follow-up updates from linux-stable (like current 6.6.13 etc).
Would this require syncing in -rc versions of Linux DTs to get the latest fixes in ?
Assume that there is some large breaking change in Linux 6.(n+1), something which would be problematic for specific U-Boot platform (e.g. i.MX) or would require a lot of work to sort out, will there be a way to temporarily pin DTs for specific platform to older DT version until that is resolved (e.g. pin to 6.n) ?
(Upstream) devicetree has to be forwards and backwards compatible, were such a breaking change to get merged without prior discussion with DT users (i.e. U-Boot) then I think the correct course of action would be to revert it.
Not really, this could be a perfectly valid change, and would work for Linux just fine, it might simply be pulling in something which is not supported by U-Boot just yet and therefore syncing the DTs into U-Boot would break U-Boot on that platform . Using older version of DTs for a platform could work as a stopgap measure until the functionality is implemented. Is this possible ?
On a tangential note: as I understand it, DTs built from dt-rebasing are still subject to U-Boot customisations via the "-u-boot.dtsi" include files, this allows for dealing with incompatibilities due to missing features in U-Boot.
Would it be possible to auto-update those -u-boot.dtsi files during sync, to minimize the resulting DT blob delta before/after update, and thus also minimize the likelihood of causing breakage ?

Hi Marek,
On Mon, 22 Jan 2024 at 05:47, Marek Vasut marex@denx.de wrote:
On 1/21/24 23:41, Caleb Connolly wrote:
Hi,
[...]
How do you propose to handle fixes to DTs which are applied to linux-stable releases ? For example, if Linux 6.6(.0) ships a DT which has some defect that is fixed in 6.6.1, how will that fix get into U-Boot DTs ?
This fix would also be in the latest Linux tags, so I think it would find its way here - as I understand it patches aren't accepted into Linux stable unless they land in torvalds tree.
See the devicetree-rebasing.git:
https://git.kernel.org/pub/scm/linux/kernel/git/devicetree/devicetree-rebasi...
That only contains refs for release versions (v6.6-dts, v6.7-dts etc), not any follow-up updates from linux-stable (like current 6.6.13 etc).
Here we should only consider fixes which are critical to U-Boot. I think -u-boot.dtsi files would be suitable to carry those fixes until next uprev. However, if there is a fix affecting many platforms than we can consider pulling that standalone too.
Would this require syncing in -rc versions of Linux DTs to get the latest fixes in ?
Syncing -rc versions makes U-Boot more prone to DT ABI breakages. So its a chicken and egg problem as per your comments below. However, we can revisit our syncing strategy based on how the current one pans out.
Assume that there is some large breaking change in Linux 6.(n+1), something which would be problematic for specific U-Boot platform (e.g. i.MX) or would require a lot of work to sort out, will there be a way to temporarily pin DTs for specific platform to older DT version until that is resolved (e.g. pin to 6.n) ?
(Upstream) devicetree has to be forwards and backwards compatible, were such a breaking change to get merged without prior discussion with DT users (i.e. U-Boot) then I think the correct course of action would be to revert it.
Not really, this could be a perfectly valid change, and would work for Linux just fine, it might simply be pulling in something which is not supported by U-Boot just yet and therefore syncing the DTs into U-Boot would break U-Boot on that platform . Using older version of DTs for a platform could work as a stopgap measure until the functionality is implemented. Is this possible ?
For this particular reason we want to pull once during beginning on U-Boot next window and allow sufficient time for platform maintainers to adapt to it. However, OF_UPSTREAM=n can be an alternative for a stopgap solution.
On a tangential note: as I understand it, DTs built from dt-rebasing are still subject to U-Boot customisations via the "-u-boot.dtsi" include files, this allows for dealing with incompatibilities due to missing features in U-Boot.
Would it be possible to auto-update those -u-boot.dtsi files during sync, to minimize the resulting DT blob delta before/after update, and thus also minimize the likelihood of causing breakage ?
In the long run the DT community would like to avoid any DT ABI breakages at all. Rob is already working on a DT ABI check tool and seeking inputs for what could be an ABI break [1] from U-Boot perspective too. Feel free to provide your inputs.
Along with that we wouldn't need -u-boot.dtsi files once we make U-Boot fully compliant with DT bindings. Until that point U-Boot platform maintainers have to keep their -u-boot.dtsi files updated corresponding to latest DT rebasing releases.
[1] https://lore.kernel.org/all/CAL_JsqLo4nXrJ93dDsfp3UYLs08V02aMnbCCnsDj0MBBomc...
-Sumit

On 1/24/24 09:16, Sumit Garg wrote:
Hi,
How do you propose to handle fixes to DTs which are applied to linux-stable releases ? For example, if Linux 6.6(.0) ships a DT which has some defect that is fixed in 6.6.1, how will that fix get into U-Boot DTs ?
This fix would also be in the latest Linux tags, so I think it would find its way here - as I understand it patches aren't accepted into Linux stable unless they land in torvalds tree.
See the devicetree-rebasing.git:
https://git.kernel.org/pub/scm/linux/kernel/git/devicetree/devicetree-rebasi...
That only contains refs for release versions (v6.6-dts, v6.7-dts etc), not any follow-up updates from linux-stable (like current 6.6.13 etc).
Here we should only consider fixes which are critical to U-Boot. I think -u-boot.dtsi files would be suitable to carry those fixes until next uprev. However, if there is a fix affecting many platforms than we can consider pulling that standalone too.
That would mean extra duplicate work -- the critical fixes have already been selected into linux-stable, that work is already done, I don't think it makes sense to re-do it again.
Furthermore, I do not like the new necessity to start porting those fixes from linux-stable and converting them to adjustments to *-u-boot.dtsi files, this is tedious and error prone, so it would have to be automated.
But I still think it is much better to simply take the fixes directly from linux-stable as-is instead.
Would this require syncing in -rc versions of Linux DTs to get the latest fixes in ?
Syncing -rc versions makes U-Boot more prone to DT ABI breakages. So its a chicken and egg problem as per your comments below. However, we can revisit our syncing strategy based on how the current one pans out.
Assume that there is some large breaking change in Linux 6.(n+1), something which would be problematic for specific U-Boot platform (e.g. i.MX) or would require a lot of work to sort out, will there be a way to temporarily pin DTs for specific platform to older DT version until that is resolved (e.g. pin to 6.n) ?
(Upstream) devicetree has to be forwards and backwards compatible, were such a breaking change to get merged without prior discussion with DT users (i.e. U-Boot) then I think the correct course of action would be to revert it.
Not really, this could be a perfectly valid change, and would work for Linux just fine, it might simply be pulling in something which is not supported by U-Boot just yet and therefore syncing the DTs into U-Boot would break U-Boot on that platform . Using older version of DTs for a platform could work as a stopgap measure until the functionality is implemented. Is this possible ?
For this particular reason we want to pull once during beginning on U-Boot next window and allow sufficient time for platform maintainers to adapt to it. However, OF_UPSTREAM=n can be an alternative for a stopgap solution.
That pull would break other peoples platforms. It would be no different than adding broken patch into the code base. What I think would be an option is that there is a pull (as in patch) and people should be able to test it before it is applied. If one platform is severely affected while other platforms are fine, the one platform should be able to use the current working version of DTs, while the other platforms should not be blocked by it. Is that what OF_UPSTREAM=n does ?
As far as I understand OF_UPSTREAM=n, it would require re-importing DTs into the codebase ?
On a tangential note: as I understand it, DTs built from dt-rebasing are still subject to U-Boot customisations via the "-u-boot.dtsi" include files, this allows for dealing with incompatibilities due to missing features in U-Boot.
Would it be possible to auto-update those -u-boot.dtsi files during sync, to minimize the resulting DT blob delta before/after update, and thus also minimize the likelihood of causing breakage ?
In the long run the DT community would like to avoid any DT ABI breakages at all. Rob is already working on a DT ABI check tool and seeking inputs for what could be an ABI break [1] from U-Boot perspective too. Feel free to provide your inputs.
Along with that we wouldn't need -u-boot.dtsi files once we make U-Boot fully compliant with DT bindings. Until that point U-Boot platform maintainers have to keep their -u-boot.dtsi files updated corresponding to latest DT rebasing releases.
I think upstreaming the bootph* properties would still take a while, but is not relevant to the aforementioned question.
Assume there is a sync, would the current in-tree -u-boot.dtsi files get updated to work correctly with the newly synced DTs ?

On Thu, 25 Jan 2024 at 07:36, Marek Vasut marex@denx.de wrote:
On 1/24/24 09:16, Sumit Garg wrote:
Hi,
How do you propose to handle fixes to DTs which are applied to linux-stable releases ? For example, if Linux 6.6(.0) ships a DT which has some defect that is fixed in 6.6.1, how will that fix get into U-Boot DTs ?
This fix would also be in the latest Linux tags, so I think it would find its way here - as I understand it patches aren't accepted into Linux stable unless they land in torvalds tree.
See the devicetree-rebasing.git:
https://git.kernel.org/pub/scm/linux/kernel/git/devicetree/devicetree-rebasi...
That only contains refs for release versions (v6.6-dts, v6.7-dts etc), not any follow-up updates from linux-stable (like current 6.6.13 etc).
Here we should only consider fixes which are critical to U-Boot. I think -u-boot.dtsi files would be suitable to carry those fixes until next uprev. However, if there is a fix affecting many platforms than we can consider pulling that standalone too.
That would mean extra duplicate work -- the critical fixes have already been selected into linux-stable, that work is already done, I don't think it makes sense to re-do it again.
Furthermore, I do not like the new necessity to start porting those fixes from linux-stable and converting them to adjustments to *-u-boot.dtsi files, this is tedious and error prone, so it would have to be automated.
But I still think it is much better to simply take the fixes directly from linux-stable as-is instead.
That's fair, it would essentially be a DT ABI breakage for U-Boot for which a fix has to be taken in U-Boot from Linux stable release. So I am fine with that.
But at this point we have to move away from apprehensions about DT ABI breakages and provide real examples of the DT ABI breakages in the past. Are you aware of any DT ABI breaking change backported to Linux stable releases? This is the sort of information we would like to make DT bindings maintainers aware about.
Would this require syncing in -rc versions of Linux DTs to get the latest fixes in ?
Syncing -rc versions makes U-Boot more prone to DT ABI breakages. So its a chicken and egg problem as per your comments below. However, we can revisit our syncing strategy based on how the current one pans out.
Assume that there is some large breaking change in Linux 6.(n+1), something which would be problematic for specific U-Boot platform (e.g. i.MX) or would require a lot of work to sort out, will there be a way to temporarily pin DTs for specific platform to older DT version until that is resolved (e.g. pin to 6.n) ?
(Upstream) devicetree has to be forwards and backwards compatible, were such a breaking change to get merged without prior discussion with DT users (i.e. U-Boot) then I think the correct course of action would be to revert it.
Not really, this could be a perfectly valid change, and would work for Linux just fine, it might simply be pulling in something which is not supported by U-Boot just yet and therefore syncing the DTs into U-Boot would break U-Boot on that platform . Using older version of DTs for a platform could work as a stopgap measure until the functionality is implemented. Is this possible ?
For this particular reason we want to pull once during beginning on U-Boot next window and allow sufficient time for platform maintainers to adapt to it. However, OF_UPSTREAM=n can be an alternative for a stopgap solution.
That pull would break other peoples platforms. It would be no different than adding broken patch into the code base.
The platforms which get converted to OF_UPSTREAM=y are the ones which would be compliant with upstream DT bindings. So any DT ABI change among major Linux .0 releases would be the reason for that breakage. And we are happy to accept a revert for that change and feed that information back to Linux DT bindings maintainers.
Also as above, are you aware of any past DT ABI breakages for U-Boot since people have already been doing DT syncing from Linux manually. This series allows to reduce that pain and try to bring DT bindings compliance in U-Boot.
What I think would be an option is that there is a pull (as in patch) and people should be able to test it before it is applied.
We can't modify that pull but rather accept changes on top of it. IMO, it will get widely tested in U-Boot next branch.
If one platform is severely affected while other platforms are fine, the one platform should be able to use the current working version of DTs, while the other platforms should not be blocked by it. Is that what OF_UPSTREAM=n does ?
As far as I understand OF_UPSTREAM=n, it would require re-importing DTs into the codebase ?
No you don't have to re-import everything but rather import a board DTS file to the arch/ folder and reuse all the DT includes from dts/upstream subtree as per this [1] patch.
[1] https://lore.kernel.org/all/20240110103547.719757-5-sumit.garg@linaro.org/
On a tangential note: as I understand it, DTs built from dt-rebasing are still subject to U-Boot customisations via the "-u-boot.dtsi" include files, this allows for dealing with incompatibilities due to missing features in U-Boot.
Would it be possible to auto-update those -u-boot.dtsi files during sync, to minimize the resulting DT blob delta before/after update, and thus also minimize the likelihood of causing breakage ?
In the long run the DT community would like to avoid any DT ABI breakages at all. Rob is already working on a DT ABI check tool and seeking inputs for what could be an ABI break [1] from U-Boot perspective too. Feel free to provide your inputs.
Along with that we wouldn't need -u-boot.dtsi files once we make U-Boot fully compliant with DT bindings. Until that point U-Boot platform maintainers have to keep their -u-boot.dtsi files updated corresponding to latest DT rebasing releases.
I think upstreaming the bootph* properties would still take a while, but is not relevant to the aforementioned question.
Assume there is a sync, would the current in-tree -u-boot.dtsi files get updated to work correctly with the newly synced DTs ?
As long as they contain nodes/properties (eg. bootph* etc.) which are compliant with upstream DT bindings then yes they should work correctly with the newly synced DTs.
-Sumit

On Thu, Jan 25, 2024 at 12:54:22PM +0530, Sumit Garg wrote:
[snip]
But at this point we have to move away from apprehensions about DT ABI breakages and provide real examples of the DT ABI breakages in the past. Are you aware of any DT ABI breaking change backported to Linux stable releases? This is the sort of information we would like to make DT bindings maintainers aware about.
Well, how far back are we going? There was a serial related one, but it was probably closer than not to 10 years ago and lessons have been learned from it already.
The real breakage comes in the form of (from the Linux kernel): commit 37685f6a63eeca2135d1f704e7638409a071b1f6 Author: Peter Ujfalusi peter.ujfalusi@ti.com Date: Tue Feb 19 08:46:33 2019 -0800
ARM: dts: am335x-evm: Fix PHY mode for ethernet
The PHY must add both tx and rx delay and not only on the tx clock. The board uses AR8031_AL1A PHY where the rx delay is enabled by default, the tx dealy is disabled.
The reason why rgmii-txid worked because the rx delay was not disabled by the driver so essentially we ended up with rgmii-id PHY mode.
Signed-off-by: Peter Ujfalusi peter.ujfalusi@ti.com Signed-off-by: Tony Lindgren tony@atomide.com
And this is of the style "the DTS was wrong before so we can break it". This is the specific example (as the board is in my lab) that comes most clearly to mind but there have been similar examples in 2022/2023.
The other just as painful examples I think may be where Marek is concerned and it's around nodes being renamed for correctness. We've had a number of cases where a - turned to _ (or vice versa?) and whoops, platform stops booting. Down the line, tooling would catch that, and it's a problem of not being able to use better tooling until we have the updates that might break the boards that need the better tooling.
And really this gets to the crux of the problem, how much testing do we insist happens prior to a re-sync being merged? Do we want to go with the whole of the dts files are re-synced, or do we leave it per vendor? I think it's been noted that a subtree merge commit doesn't really "git send-email" well.
I really am inclined to start with keeping everyone to the release tags for everyone and merging them as soon as the next window opens. I _think__ and we'll be able to find out quickly enough, that we can cherry-pick fixes from upstream in to our subtree and have subtree Do The Right Thing in the next merge window.
[snip]
I think upstreaming the bootph* properties would still take a while, but is not relevant to the aforementioned question.
Assume there is a sync, would the current in-tree -u-boot.dtsi files get updated to work correctly with the newly synced DTs ?
As long as they contain nodes/properties (eg. bootph* etc.) which are compliant with upstream DT bindings then yes they should work correctly with the newly synced DTs.
This is a good specific example. The bootph* properties should _now_ be easier to get accepted upstream as our tooling handles the transitive property of them correctly and so they don't need to be manually applied so much (a problem upstream maintainers had, after the binding was accepted, was the sheer number of them being added, this is now fixed). But also applying these properties via -u-boot.dtsi was tripped up in resyncs where the parent node was renamed for correctness and there's no tooling that we had that complained. In the future, this would have been caught because we would have been dtbs_check clean, or at least clean enough that I'd be running it and caring about deltas from before/after.

On 1/25/24 16:04, Tom Rini wrote:
On Thu, Jan 25, 2024 at 12:54:22PM +0530, Sumit Garg wrote:
[snip]
But at this point we have to move away from apprehensions about DT ABI breakages and provide real examples of the DT ABI breakages in the past. Are you aware of any DT ABI breaking change backported to Linux stable releases? This is the sort of information we would like to make DT bindings maintainers aware about.
Well, how far back are we going? There was a serial related one, but it was probably closer than not to 10 years ago and lessons have been learned from it already.
The real breakage comes in the form of (from the Linux kernel): commit 37685f6a63eeca2135d1f704e7638409a071b1f6 Author: Peter Ujfalusi peter.ujfalusi@ti.com Date: Tue Feb 19 08:46:33 2019 -0800
ARM: dts: am335x-evm: Fix PHY mode for ethernet The PHY must add both tx and rx delay and not only on the tx clock. The board uses AR8031_AL1A PHY where the rx delay is enabled by default, the tx dealy is disabled. The reason why rgmii-txid worked because the rx delay was not disabled by the driver so essentially we ended up with rgmii-id PHY mode. Signed-off-by: Peter Ujfalusi <peter.ujfalusi@ti.com> Signed-off-by: Tony Lindgren <tony@atomide.com>
And this is of the style "the DTS was wrong before so we can break it". This is the specific example (as the board is in my lab) that comes most clearly to mind but there have been similar examples in 2022/2023.
The other just as painful examples I think may be where Marek is concerned and it's around nodes being renamed for correctness. We've had a number of cases where a - turned to _ (or vice versa?) and whoops, platform stops booting. Down the line, tooling would catch that, and it's a problem of not being able to use better tooling until we have the updates that might break the boards that need the better tooling.
And really this gets to the crux of the problem, how much testing do we insist happens prior to a re-sync being merged? Do we want to go with the whole of the dts files are re-synced, or do we leave it per vendor?
I'd much prefer to leave it per vendor, with the recommendation to use synced DTs. Eventually things will stabilize and vendors will start switching over.

On Thu, Jan 25, 2024 at 05:38:23PM +0100, Marek Vasut wrote:
On 1/25/24 16:04, Tom Rini wrote:
On Thu, Jan 25, 2024 at 12:54:22PM +0530, Sumit Garg wrote:
[snip]
But at this point we have to move away from apprehensions about DT ABI breakages and provide real examples of the DT ABI breakages in the past. Are you aware of any DT ABI breaking change backported to Linux stable releases? This is the sort of information we would like to make DT bindings maintainers aware about.
Well, how far back are we going? There was a serial related one, but it was probably closer than not to 10 years ago and lessons have been learned from it already.
The real breakage comes in the form of (from the Linux kernel): commit 37685f6a63eeca2135d1f704e7638409a071b1f6 Author: Peter Ujfalusi peter.ujfalusi@ti.com Date: Tue Feb 19 08:46:33 2019 -0800
ARM: dts: am335x-evm: Fix PHY mode for ethernet The PHY must add both tx and rx delay and not only on the tx clock. The board uses AR8031_AL1A PHY where the rx delay is enabled by default, the tx dealy is disabled. The reason why rgmii-txid worked because the rx delay was not disabled by the driver so essentially we ended up with rgmii-id PHY mode. Signed-off-by: Peter Ujfalusi <peter.ujfalusi@ti.com> Signed-off-by: Tony Lindgren <tony@atomide.com>
And this is of the style "the DTS was wrong before so we can break it". This is the specific example (as the board is in my lab) that comes most clearly to mind but there have been similar examples in 2022/2023.
The other just as painful examples I think may be where Marek is concerned and it's around nodes being renamed for correctness. We've had a number of cases where a - turned to _ (or vice versa?) and whoops, platform stops booting. Down the line, tooling would catch that, and it's a problem of not being able to use better tooling until we have the updates that might break the boards that need the better tooling.
And really this gets to the crux of the problem, how much testing do we insist happens prior to a re-sync being merged? Do we want to go with the whole of the dts files are re-synced, or do we leave it per vendor?
I'd much prefer to leave it per vendor, with the recommendation to use synced DTs. Eventually things will stabilize and vendors will start switching over.
To be clear, every SoC (or really, board) has to opt-in to OF_UPSTREAM to start with. With that, I see switching to OF_UPSTREAM meaning that there's a commitment to keeping up with dts change in upstream dts that might lead to issues within U-Boot. Do you still feel it would be better to have the re-sync _also_ be per custodian tree? That might be a bit harder to handle.

On 1/26/24 00:19, Tom Rini wrote:
On Thu, Jan 25, 2024 at 05:38:23PM +0100, Marek Vasut wrote:
On 1/25/24 16:04, Tom Rini wrote:
On Thu, Jan 25, 2024 at 12:54:22PM +0530, Sumit Garg wrote:
[snip]
But at this point we have to move away from apprehensions about DT ABI breakages and provide real examples of the DT ABI breakages in the past. Are you aware of any DT ABI breaking change backported to Linux stable releases? This is the sort of information we would like to make DT bindings maintainers aware about.
Well, how far back are we going? There was a serial related one, but it was probably closer than not to 10 years ago and lessons have been learned from it already.
The real breakage comes in the form of (from the Linux kernel): commit 37685f6a63eeca2135d1f704e7638409a071b1f6 Author: Peter Ujfalusi peter.ujfalusi@ti.com Date: Tue Feb 19 08:46:33 2019 -0800
ARM: dts: am335x-evm: Fix PHY mode for ethernet The PHY must add both tx and rx delay and not only on the tx clock. The board uses AR8031_AL1A PHY where the rx delay is enabled by default, the tx dealy is disabled. The reason why rgmii-txid worked because the rx delay was not disabled by the driver so essentially we ended up with rgmii-id PHY mode. Signed-off-by: Peter Ujfalusi <peter.ujfalusi@ti.com> Signed-off-by: Tony Lindgren <tony@atomide.com>
And this is of the style "the DTS was wrong before so we can break it". This is the specific example (as the board is in my lab) that comes most clearly to mind but there have been similar examples in 2022/2023.
The other just as painful examples I think may be where Marek is concerned and it's around nodes being renamed for correctness. We've had a number of cases where a - turned to _ (or vice versa?) and whoops, platform stops booting. Down the line, tooling would catch that, and it's a problem of not being able to use better tooling until we have the updates that might break the boards that need the better tooling.
And really this gets to the crux of the problem, how much testing do we insist happens prior to a re-sync being merged? Do we want to go with the whole of the dts files are re-synced, or do we leave it per vendor?
I'd much prefer to leave it per vendor, with the recommendation to use synced DTs. Eventually things will stabilize and vendors will start switching over.
To be clear, every SoC (or really, board) has to opt-in to OF_UPSTREAM to start with. With that, I see switching to OF_UPSTREAM meaning that there's a commitment to keeping up with dts change in upstream dts that might lead to issues within U-Boot. Do you still feel it would be better to have the re-sync _also_ be per custodian tree? That might be a bit harder to handle.
Maybe the best thing we can do is just give it a try and see how it works out, esp. since it is opt-in per board .
It would still be good to solve the part about pulling in fixes from linux-stable though .

On 1/26/24 03:10, Marek Vasut wrote:
On 1/26/24 00:19, Tom Rini wrote:
On Thu, Jan 25, 2024 at 05:38:23PM +0100, Marek Vasut wrote:
On 1/25/24 16:04, Tom Rini wrote:
On Thu, Jan 25, 2024 at 12:54:22PM +0530, Sumit Garg wrote:
[snip]
But at this point we have to move away from apprehensions about DT ABI breakages and provide real examples of the DT ABI breakages in the past. Are you aware of any DT ABI breaking change backported to Linux stable releases? This is the sort of information we would like to make DT bindings maintainers aware about.
Well, how far back are we going? There was a serial related one, but it was probably closer than not to 10 years ago and lessons have been learned from it already.
The real breakage comes in the form of (from the Linux kernel): commit 37685f6a63eeca2135d1f704e7638409a071b1f6 Author: Peter Ujfalusi peter.ujfalusi@ti.com Date: Tue Feb 19 08:46:33 2019 -0800
ARM: dts: am335x-evm: Fix PHY mode for ethernet
The PHY must add both tx and rx delay and not only on the tx clock. The board uses AR8031_AL1A PHY where the rx delay is enabled by default, the tx dealy is disabled.
The reason why rgmii-txid worked because the rx delay was not disabled by the driver so essentially we ended up with rgmii-id PHY mode.
Signed-off-by: Peter Ujfalusi peter.ujfalusi@ti.com Signed-off-by: Tony Lindgren tony@atomide.com
And this is of the style "the DTS was wrong before so we can break it". This is the specific example (as the board is in my lab) that comes most clearly to mind but there have been similar examples in 2022/2023.
The other just as painful examples I think may be where Marek is concerned and it's around nodes being renamed for correctness. We've had a number of cases where a - turned to _ (or vice versa?) and whoops, platform stops booting. Down the line, tooling would catch that, and it's a problem of not being able to use better tooling until we have the updates that might break the boards that need the better tooling.
And really this gets to the crux of the problem, how much testing do we insist happens prior to a re-sync being merged? Do we want to go with the whole of the dts files are re-synced, or do we leave it per vendor?
I'd much prefer to leave it per vendor, with the recommendation to use synced DTs. Eventually things will stabilize and vendors will start switching over.
To be clear, every SoC (or really, board) has to opt-in to OF_UPSTREAM to start with. With that, I see switching to OF_UPSTREAM meaning that there's a commitment to keeping up with dts change in upstream dts that might lead to issues within U-Boot. Do you still feel it would be better to have the re-sync _also_ be per custodian tree? That might be a bit harder to handle.
Maybe the best thing we can do is just give it a try and see how it works out, esp. since it is opt-in per board .
It would still be good to solve the part about pulling in fixes from linux-stable though .
I would let board owners/custodians to deal with their boards. There is very high chance that if you do it globally that it is question of time when something will break. It make sense to talk about how to do that transition and describe that steps and having tools/script to help with.
Thanks, Michal

On Fri, 26 Jan 2024 at 12:35, Michal Simek michal.simek@amd.com wrote:
On 1/26/24 03:10, Marek Vasut wrote:
On 1/26/24 00:19, Tom Rini wrote:
On Thu, Jan 25, 2024 at 05:38:23PM +0100, Marek Vasut wrote:
On 1/25/24 16:04, Tom Rini wrote:
On Thu, Jan 25, 2024 at 12:54:22PM +0530, Sumit Garg wrote:
[snip]
But at this point we have to move away from apprehensions about DT ABI breakages and provide real examples of the DT ABI breakages in the past. Are you aware of any DT ABI breaking change backported to Linux stable releases? This is the sort of information we would like to make DT bindings maintainers aware about.
Well, how far back are we going? There was a serial related one, but it was probably closer than not to 10 years ago and lessons have been learned from it already.
The real breakage comes in the form of (from the Linux kernel): commit 37685f6a63eeca2135d1f704e7638409a071b1f6 Author: Peter Ujfalusi peter.ujfalusi@ti.com Date: Tue Feb 19 08:46:33 2019 -0800
ARM: dts: am335x-evm: Fix PHY mode for ethernet The PHY must add both tx and rx delay and not only on the tx clock. The board uses AR8031_AL1A PHY where the rx delay is enabled by default, the tx dealy is disabled. The reason why rgmii-txid worked because the rx delay was not disabled by the driver so essentially we ended up with rgmii-id PHY mode. Signed-off-by: Peter Ujfalusi <peter.ujfalusi@ti.com> Signed-off-by: Tony Lindgren <tony@atomide.com>
And this is of the style "the DTS was wrong before so we can break it". This is the specific example (as the board is in my lab) that comes most clearly to mind but there have been similar examples in 2022/2023.
I agree that these sorts of changes should be done in a DT ABI compatible manner to U-Boot or atleast proactively adapt U-Boot to those changes. But I am not sure how we can improve here without a regular DT sync cadence with upstream and a Linux kernel maintainer profile to say that DT ABI towards U-Boot has to be kept in mind.
The existing ad hoc syncs won't be motivating Linux DT maintainers to care about U-Boot regressions.
The other just as painful examples I think may be where Marek is concerned and it's around nodes being renamed for correctness. We've had a number of cases where a - turned to _ (or vice versa?) and whoops, platform stops booting. Down the line, tooling would catch that, and it's a problem of not being able to use better tooling until we have the updates that might break the boards that need the better tooling.
AFAIU from this [1], the DT node names aren't part of the ABI. Given that we should start motivating people to move away from relying on node names, for eg. using uclass_get_device_by_seq() instead of uclass_get_device_by_name().
[1] https://www.kernel.org/doc/Documentation/ABI/testing/sysfs-firmware-ofw
And really this gets to the crux of the problem, how much testing do we insist happens prior to a re-sync being merged?
I am not sure why custodians/maintainers depend on the global re-sync to be merged for testing purposes. They can very well have their local vendor directories synced-up and proactively look for any regressions.
Do we want to go with the whole of the dts files are re-synced, or do we leave it per vendor?
Leaving it per vendor would be somewhat similar to existing ad hoc syncs. BTW, what about bindings directory? We won't be able to enforce binding checks given the different state of per vendor DTS directory.
I'd much prefer to leave it per vendor, with the recommendation to use synced DTs. Eventually things will stabilize and vendors will start switching over.
To be clear, every SoC (or really, board) has to opt-in to OF_UPSTREAM to start with. With that, I see switching to OF_UPSTREAM meaning that there's a commitment to keeping up with dts change in upstream dts that might lead to issues within U-Boot. Do you still feel it would be better to have the re-sync _also_ be per custodian tree? That might be a bit harder to handle.
Maybe the best thing we can do is just give it a try and see how it works out, esp. since it is opt-in per board .
Yeah given that we are conservative about re-syncs with a full U-Boot release cycle to detect and fix regressions.
It would still be good to solve the part about pulling in fixes from linux-stable though .
So I did a demo experiment for this here [1] where cherry picking DT fixes into subtree just worked fine with the next uprev. Steps followed:
$ cd <U-Boot tree>/ $ git remote add dt-rebasing https://git.kernel.org/pub/scm/linux/kernel/git/devicetree/devicetree-rebasi... $ git fetch dt-rebasing master $ git cherry-pick -x --strategy=subtree -Xsubtree=dts/upstream/ 9de355a75fdeffc26486508107bf644ca2749fdb $ ./dts/update-dts-subtree.sh v6.8-rc2-dts
If you would like it to be documented then I can do that for the next rev.
[1] https://github.com/b49020/u-boot/commits/v4_dt_demo_fixes/
I would let board owners/custodians to deal with their boards. There is very high chance that if you do it globally that it is question of time when something will break. It make sense to talk about how to do that transition and describe that steps and having tools/script to help with.
Given my comments above, I think we should at least give U-Boot owners/custodians a chance to opt for this and see how it pans out. It will give a better opportunity for the U-Boot community to engage and be a part of the current DT contribution model.
-Sumit
Thanks, Michal

On Wed, Jan 31, 2024 at 06:26:54PM +0530, Sumit Garg wrote:
[snip]
So I did a demo experiment for this here [1] where cherry picking DT fixes into subtree just worked fine with the next uprev. Steps followed:
$ cd <U-Boot tree>/ $ git remote add dt-rebasing https://git.kernel.org/pub/scm/linux/kernel/git/devicetree/devicetree-rebasi... $ git fetch dt-rebasing master $ git cherry-pick -x --strategy=subtree -Xsubtree=dts/upstream/ 9de355a75fdeffc26486508107bf644ca2749fdb $ ./dts/update-dts-subtree.sh v6.8-rc2-dts
If you would like it to be documented then I can do that for the next rev.
Yes please.

On Wed, 10 Jan 2024 16:05:36 +0530 Sumit Garg sumit.garg@linaro.org wrote:
Hi,
I certainly welcome this more automatic synchronisation of the DTs, however have one comment about the upcoming sync process:
... 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 `dts/upstream` sub-directory. U-Boot will regularly sync `dts/upstream/` subtree whenever the next window opens with the next available kernel major release.
I hope this doesn't need to stay that restricted? Can we either sync more often, or at least on the kernel's -rc1, and not only on a "full" release?
The reason I ask is that we have a chicken-egg problem here: without a DT merged into the kernel tree, no U-Boot board support can be merged. And without U-Boot support, we cannot boot a kernel, at least not in the canonical way.
Since the U-Boot and kernel merge windows are not in phase, for sunxi I try to sync the kernel DTs either as early as possible (-rc1, sometimes even before, when the maintainers have merged them into their tree), or sometimes "out of season", if a board defconfig patch is coming up.
Otherwise new board support, which typically has a very low regression risk for the rest of the code base, would need to be delayed until the next release. In the worst case the U-Boot merge windows opens one week before a kernel release, then new boards need to wait three months?
Cheers, Andre
`dts/update-dts-subtree.sh` script provides a wrapper around git subtree pull command, usage from the top level U-Boot source tree, run:
$ ./dts/update-dts-subtree.sh <devicetree-rebasing-release-tag>
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

On Mon, Jan 22, 2024 at 11:45:15AM +0000, Andre Przywara wrote:
On Wed, 10 Jan 2024 16:05:36 +0530 Sumit Garg sumit.garg@linaro.org wrote:
Hi,
I certainly welcome this more automatic synchronisation of the DTs, however have one comment about the upcoming sync process:
... 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 `dts/upstream` sub-directory. U-Boot will regularly sync `dts/upstream/` subtree whenever the next window opens with the next available kernel major release.
I hope this doesn't need to stay that restricted? Can we either sync more often, or at least on the kernel's -rc1, and not only on a "full" release?
The reason I ask is that we have a chicken-egg problem here: without a DT merged into the kernel tree, no U-Boot board support can be merged. And without U-Boot support, we cannot boot a kernel, at least not in the canonical way.
Since the U-Boot and kernel merge windows are not in phase, for sunxi I try to sync the kernel DTs either as early as possible (-rc1, sometimes even before, when the maintainers have merged them into their tree), or sometimes "out of season", if a board defconfig patch is coming up.
Otherwise new board support, which typically has a very low regression risk for the rest of the code base, would need to be delayed until the next release. In the worst case the U-Boot merge windows opens one week before a kernel release, then new boards need to wait three months?
Would it be to bad to bring in board X with OF_UPSTREAM=n for one U-Boot release, and then with the next one switch to OF_UPSTREAM=y (and delete the dts from arch/) for the next release, when we would have gotten back in sync?

On Mon, 22 Jan 2024 11:49:59 -0500 Tom Rini trini@konsulko.com wrote:
Hi Tom,
On Mon, Jan 22, 2024 at 11:45:15AM +0000, Andre Przywara wrote:
On Wed, 10 Jan 2024 16:05:36 +0530 Sumit Garg sumit.garg@linaro.org wrote:
Hi,
I certainly welcome this more automatic synchronisation of the DTs, however have one comment about the upcoming sync process:
... 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 `dts/upstream` sub-directory. U-Boot will regularly sync `dts/upstream/` subtree whenever the next window opens with the next available kernel major release.
I hope this doesn't need to stay that restricted? Can we either sync more often, or at least on the kernel's -rc1, and not only on a "full" release?
The reason I ask is that we have a chicken-egg problem here: without a DT merged into the kernel tree, no U-Boot board support can be merged. And without U-Boot support, we cannot boot a kernel, at least not in the canonical way.
Since the U-Boot and kernel merge windows are not in phase, for sunxi I try to sync the kernel DTs either as early as possible (-rc1, sometimes even before, when the maintainers have merged them into their tree), or sometimes "out of season", if a board defconfig patch is coming up.
Otherwise new board support, which typically has a very low regression risk for the rest of the code base, would need to be delayed until the next release. In the worst case the U-Boot merge windows opens one week before a kernel release, then new boards need to wait three months?
Would it be to bad to bring in board X with OF_UPSTREAM=n for one U-Boot release, and then with the next one switch to OF_UPSTREAM=y (and delete the dts from arch/) for the next release, when we would have gotten back in sync?
Ah, I didn't look into the actual patches, but if this provision is there, that sounds surely acceptable. It might still be good to sync earlier than the .0 kernel release: if it appears in Linus' tree, it had already seen a good share of review and testing. And with the U-Boot releases being always further away than the next kernel release, we could pull fixes still in time. So we could pick the latest -rc (or .0 release, whichever is more recent) when the U-Boot merge window opens?
Cheers, Andre

On Mon, Jan 22, 2024 at 6:59 PM Andre Przywara andre.przywara@arm.com wrote:
On Mon, 22 Jan 2024 11:49:59 -0500 Tom Rini trini@konsulko.com wrote:
Hi Tom,
On Mon, Jan 22, 2024 at 11:45:15AM +0000, Andre Przywara wrote:
On Wed, 10 Jan 2024 16:05:36 +0530 Sumit Garg sumit.garg@linaro.org wrote:
Hi,
I certainly welcome this more automatic synchronisation of the DTs, however have one comment about the upcoming sync process:
... 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 `dts/upstream` sub-directory. U-Boot will regularly sync `dts/upstream/` subtree whenever the next window opens with the next available kernel major release.
I hope this doesn't need to stay that restricted? Can we either sync more often, or at least on the kernel's -rc1, and not only on a "full" release?
The reason I ask is that we have a chicken-egg problem here: without a DT merged into the kernel tree, no U-Boot board support can be merged. And without U-Boot support, we cannot boot a kernel, at least not in the canonical way.
Since the U-Boot and kernel merge windows are not in phase, for sunxi I try to sync the kernel DTs either as early as possible (-rc1, sometimes even before, when the maintainers have merged them into their tree), or sometimes "out of season", if a board defconfig patch is coming up.
Otherwise new board support, which typically has a very low regression risk for the rest of the code base, would need to be delayed until the next release. In the worst case the U-Boot merge windows opens one week before a kernel release, then new boards need to wait three months?
Would it be to bad to bring in board X with OF_UPSTREAM=n for one U-Boot release, and then with the next one switch to OF_UPSTREAM=y (and delete the dts from arch/) for the next release, when we would have gotten back in sync?
Ah, I didn't look into the actual patches, but if this provision is there, that sounds surely acceptable. It might still be good to sync earlier than the .0 kernel release: if it appears in Linus' tree, it had already seen a good share of review and testing. And with the U-Boot releases being always further away than the next kernel release, we could pull fixes still in time. So we could pick the latest -rc (or .0 release, whichever is more recent) when the U-Boot merge window opens?
That should be mostly fine IMO, but there are the occasional "oops, let's change/fix the binding before it's released".
Couldn't you pull in the latest rc in the merge window, but only if the .0 release will happen before the next u-boot release. And then update from rc to .0 before the u-boot release.
Also, from a quick look at the dts changes during rc releases, they tend to come in the later rc releases. Probably that's just the latency of going to sub-arch maintainer->SoC->Linus.
Rob

Hi Rob, Andre,
On Tue, 23 Jan 2024 at 22:12, Rob Herring robh+dt@kernel.org wrote:
On Mon, Jan 22, 2024 at 6:59 PM Andre Przywara andre.przywara@arm.com wrote:
On Mon, 22 Jan 2024 11:49:59 -0500 Tom Rini trini@konsulko.com wrote:
Hi Tom,
On Mon, Jan 22, 2024 at 11:45:15AM +0000, Andre Przywara wrote:
On Wed, 10 Jan 2024 16:05:36 +0530 Sumit Garg sumit.garg@linaro.org wrote:
Hi,
I certainly welcome this more automatic synchronisation of the DTs, however have one comment about the upcoming sync process:
... 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 `dts/upstream` sub-directory. U-Boot will regularly sync `dts/upstream/` subtree whenever the next window opens with the next available kernel major release.
I hope this doesn't need to stay that restricted? Can we either sync more often, or at least on the kernel's -rc1, and not only on a "full" release?
The reason I ask is that we have a chicken-egg problem here: without a DT merged into the kernel tree, no U-Boot board support can be merged. And without U-Boot support, we cannot boot a kernel, at least not in the canonical way.
Since the U-Boot and kernel merge windows are not in phase, for sunxi I try to sync the kernel DTs either as early as possible (-rc1, sometimes even before, when the maintainers have merged them into their tree), or sometimes "out of season", if a board defconfig patch is coming up.
Otherwise new board support, which typically has a very low regression risk for the rest of the code base, would need to be delayed until the next release. In the worst case the U-Boot merge windows opens one week before a kernel release, then new boards need to wait three months?
Would it be to bad to bring in board X with OF_UPSTREAM=n for one U-Boot release, and then with the next one switch to OF_UPSTREAM=y (and delete the dts from arch/) for the next release, when we would have gotten back in sync?
Ah, I didn't look into the actual patches, but if this provision is there, that sounds surely acceptable. It might still be good to sync earlier than the .0 kernel release: if it appears in Linus' tree, it had already seen a good share of review and testing. And with the U-Boot releases being always further away than the next kernel release, we could pull fixes still in time. So we could pick the latest -rc (or .0 release, whichever is more recent) when the U-Boot merge window opens?
That should be mostly fine IMO, but there are the occasional "oops, let's change/fix the binding before it's released".
Couldn't you pull in the latest rc in the merge window, but only if the .0 release will happen before the next u-boot release. And then update from rc to .0 before the u-boot release.
Also, from a quick look at the dts changes during rc releases, they tend to come in the later rc releases. Probably that's just the latency of going to sub-arch maintainer->SoC->Linus.
I agree with your intent to keep U-Boot updated with the latest Linux DT .0 releases. However, we would like to provide sufficient time (a full U-Boot release cycle) for U-Boot developers/maintainers to adapt, detect and fix problems for their platforms wrt. to a new Linux DT .0 release. We can always revisit the syncing strategy to be more aggressive if everything pans out as per plan.
-Sumit
Rob
participants (9)
-
Andre Przywara
-
Caleb Connolly
-
Fabio Estevam
-
Marek Vasut
-
Michal Simek
-
Nishanth Menon
-
Rob Herring
-
Sumit Garg
-
Tom Rini