* [PATCH v4 01/11] CI: Exclude devicetree-rebasing subtree for CONFIG checks
2024-01-10 10:35 [PATCH v4 00/11] An effort to bring DT bindings compliance within U-Boot Sumit Garg
@ 2024-01-10 10:35 ` Sumit Garg
2024-01-10 10:35 ` [PATCH v4 02/11] Makefile: Add support for DT bindings schema checks Sumit Garg
` (12 subsequent siblings)
13 siblings, 0 replies; 36+ messages in thread
From: Sumit Garg @ 2024-01-10 10:35 UTC (permalink / raw)
To: u-boot, u-boot-amlogic, u-boot-custodians
Cc: trini, sjg, robh+dt, krzysztof.kozlowski+dt, conor,
neil.armstrong, caleb.connolly, ff, daniel.thompson, dgilmore,
pbrobinson, ilias.apalodimas, maxim.uvarov, b.galvani,
xypron.glpk, michal.simek, seanga2, rasmus.villemoes, peng.fan,
jh80.chung, rfried.dev, marex, mibodhi, bb, mark.kettenis,
Sumit Garg
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:
--
2.34.1
^ permalink raw reply related [flat|nested] 36+ messages in thread* [PATCH v4 02/11] Makefile: Add support for DT bindings schema checks
2024-01-10 10:35 [PATCH v4 00/11] An effort to bring DT bindings compliance within U-Boot Sumit Garg
2024-01-10 10:35 ` [PATCH v4 01/11] CI: Exclude devicetree-rebasing subtree for CONFIG checks Sumit Garg
@ 2024-01-10 10:35 ` Sumit Garg
2024-01-10 10:35 ` [PATCH v4 03/11] scripts/Makefile.lib: Statically define *-u-boot.dtsi files location Sumit Garg
` (11 subsequent siblings)
13 siblings, 0 replies; 36+ messages in thread
From: Sumit Garg @ 2024-01-10 10:35 UTC (permalink / raw)
To: u-boot, u-boot-amlogic, u-boot-custodians
Cc: trini, sjg, robh+dt, krzysztof.kozlowski+dt, conor,
neil.armstrong, caleb.connolly, ff, daniel.thompson, dgilmore,
pbrobinson, ilias.apalodimas, maxim.uvarov, b.galvani,
xypron.glpk, michal.simek, seanga2, rasmus.villemoes, peng.fan,
jh80.chung, rfried.dev, marex, mibodhi, bb, mark.kettenis,
Sumit Garg
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)
--
2.34.1
^ permalink raw reply related [flat|nested] 36+ messages in thread* [PATCH v4 03/11] scripts/Makefile.lib: Statically define *-u-boot.dtsi files location
2024-01-10 10:35 [PATCH v4 00/11] An effort to bring DT bindings compliance within U-Boot Sumit Garg
2024-01-10 10:35 ` [PATCH v4 01/11] CI: Exclude devicetree-rebasing subtree for CONFIG checks Sumit Garg
2024-01-10 10:35 ` [PATCH v4 02/11] Makefile: Add support for DT bindings schema checks Sumit Garg
@ 2024-01-10 10:35 ` Sumit Garg
2024-01-10 10:35 ` [PATCH v4 04/11] Makefile: Allow upstream DT subtree to provide DT includes Sumit Garg
` (10 subsequent siblings)
13 siblings, 0 replies; 36+ messages in thread
From: Sumit Garg @ 2024-01-10 10:35 UTC (permalink / raw)
To: u-boot, u-boot-amlogic, u-boot-custodians
Cc: trini, sjg, robh+dt, krzysztof.kozlowski+dt, conor,
neil.armstrong, caleb.connolly, ff, daniel.thompson, dgilmore,
pbrobinson, ilias.apalodimas, maxim.uvarov, b.galvani,
xypron.glpk, michal.simek, seanga2, rasmus.villemoes, peng.fan,
jh80.chung, rfried.dev, marex, mibodhi, bb, mark.kettenis,
Sumit Garg
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
--
2.34.1
^ permalink raw reply related [flat|nested] 36+ messages in thread* [PATCH v4 04/11] Makefile: Allow upstream DT subtree to provide DT includes
2024-01-10 10:35 [PATCH v4 00/11] An effort to bring DT bindings compliance within U-Boot Sumit Garg
` (2 preceding siblings ...)
2024-01-10 10:35 ` [PATCH v4 03/11] scripts/Makefile.lib: Statically define *-u-boot.dtsi files location Sumit Garg
@ 2024-01-10 10:35 ` Sumit Garg
2024-01-10 10:35 ` [PATCH v4 05/11] dts: Add alternative location for upstream DTB builds Sumit Garg
` (9 subsequent siblings)
13 siblings, 0 replies; 36+ messages in thread
From: Sumit Garg @ 2024-01-10 10:35 UTC (permalink / raw)
To: u-boot, u-boot-amlogic, u-boot-custodians
Cc: trini, sjg, robh+dt, krzysztof.kozlowski+dt, conor,
neil.armstrong, caleb.connolly, ff, daniel.thompson, dgilmore,
pbrobinson, ilias.apalodimas, maxim.uvarov, b.galvani,
xypron.glpk, michal.simek, seanga2, rasmus.villemoes, peng.fan,
jh80.chung, rfried.dev, marex, mibodhi, bb, mark.kettenis,
Sumit Garg
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__
--
2.34.1
^ permalink raw reply related [flat|nested] 36+ messages in thread* [PATCH v4 05/11] dts: Add alternative location for upstream DTB builds
2024-01-10 10:35 [PATCH v4 00/11] An effort to bring DT bindings compliance within U-Boot Sumit Garg
` (3 preceding siblings ...)
2024-01-10 10:35 ` [PATCH v4 04/11] Makefile: Allow upstream DT subtree to provide DT includes Sumit Garg
@ 2024-01-10 10:35 ` Sumit Garg
2024-01-10 10:35 ` [PATCH v4 06/11] dts: Add script to uprev dts/upstream subtree Sumit Garg
` (8 subsequent siblings)
13 siblings, 0 replies; 36+ messages in thread
From: Sumit Garg @ 2024-01-10 10:35 UTC (permalink / raw)
To: u-boot, u-boot-amlogic, u-boot-custodians
Cc: trini, sjg, robh+dt, krzysztof.kozlowski+dt, conor,
neil.armstrong, caleb.connolly, ff, daniel.thompson, dgilmore,
pbrobinson, ilias.apalodimas, maxim.uvarov, b.galvani,
xypron.glpk, michal.simek, seanga2, rasmus.villemoes, peng.fan,
jh80.chung, rfried.dev, marex, mibodhi, bb, mark.kettenis,
Sumit Garg
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
--
2.34.1
^ permalink raw reply related [flat|nested] 36+ messages in thread* [PATCH v4 06/11] dts: Add script to uprev dts/upstream subtree
2024-01-10 10:35 [PATCH v4 00/11] An effort to bring DT bindings compliance within U-Boot Sumit Garg
` (4 preceding siblings ...)
2024-01-10 10:35 ` [PATCH v4 05/11] dts: Add alternative location for upstream DTB builds Sumit Garg
@ 2024-01-10 10:35 ` Sumit Garg
2024-01-10 10:35 ` [PATCH v4 07/11] doc: devicetree: Align documentation to use Kconfig options Sumit Garg
` (7 subsequent siblings)
13 siblings, 0 replies; 36+ messages in thread
From: Sumit Garg @ 2024-01-10 10:35 UTC (permalink / raw)
To: u-boot, u-boot-amlogic, u-boot-custodians
Cc: trini, sjg, robh+dt, krzysztof.kozlowski+dt, conor,
neil.armstrong, caleb.connolly, ff, daniel.thompson, dgilmore,
pbrobinson, ilias.apalodimas, maxim.uvarov, b.galvani,
xypron.glpk, michal.simek, seanga2, rasmus.villemoes, peng.fan,
jh80.chung, rfried.dev, marex, mibodhi, bb, mark.kettenis,
Sumit Garg
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-rebasing.git/
+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}"
--
2.34.1
^ permalink raw reply related [flat|nested] 36+ messages in thread* [PATCH v4 07/11] doc: devicetree: Align documentation to use Kconfig options
2024-01-10 10:35 [PATCH v4 00/11] An effort to bring DT bindings compliance within U-Boot Sumit Garg
` (5 preceding siblings ...)
2024-01-10 10:35 ` [PATCH v4 06/11] dts: Add script to uprev dts/upstream subtree Sumit Garg
@ 2024-01-10 10:35 ` Sumit Garg
2024-01-10 12:31 ` Fabio Estevam
2024-01-10 10:35 ` [PATCH v4 08/11] doc: devicetree: Updates for devicetree-rebasing subtree Sumit Garg
` (6 subsequent siblings)
13 siblings, 1 reply; 36+ messages in thread
From: Sumit Garg @ 2024-01-10 10:35 UTC (permalink / raw)
To: u-boot, u-boot-amlogic, u-boot-custodians
Cc: trini, sjg, robh+dt, krzysztof.kozlowski+dt, conor,
neil.armstrong, caleb.connolly, ff, daniel.thompson, dgilmore,
pbrobinson, ilias.apalodimas, maxim.uvarov, b.galvani,
xypron.glpk, michal.simek, seanga2, rasmus.villemoes, peng.fan,
jh80.chung, rfried.dev, marex, mibodhi, bb, mark.kettenis,
Sumit Garg
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
--
2.34.1
^ permalink raw reply related [flat|nested] 36+ messages in thread* Re: [PATCH v4 07/11] doc: devicetree: Align documentation to use Kconfig options
2024-01-10 10:35 ` [PATCH v4 07/11] doc: devicetree: Align documentation to use Kconfig options Sumit Garg
@ 2024-01-10 12:31 ` Fabio Estevam
2024-01-10 12:40 ` Sumit Garg
0 siblings, 1 reply; 36+ messages in thread
From: Fabio Estevam @ 2024-01-10 12:31 UTC (permalink / raw)
To: Sumit Garg
Cc: u-boot, u-boot-amlogic, u-boot-custodians, trini, sjg, robh+dt,
krzysztof.kozlowski+dt, conor, neil.armstrong, caleb.connolly, ff,
daniel.thompson, dgilmore, pbrobinson, ilias.apalodimas,
maxim.uvarov, b.galvani, xypron.glpk, michal.simek, seanga2,
rasmus.villemoes, peng.fan, jh80.chung, rfried.dev, marex,
mibodhi, bb, mark.kettenis
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.
^ permalink raw reply [flat|nested] 36+ messages in thread
* Re: [PATCH v4 07/11] doc: devicetree: Align documentation to use Kconfig options
2024-01-10 12:31 ` Fabio Estevam
@ 2024-01-10 12:40 ` Sumit Garg
0 siblings, 0 replies; 36+ messages in thread
From: Sumit Garg @ 2024-01-10 12:40 UTC (permalink / raw)
To: Fabio Estevam
Cc: u-boot, u-boot-amlogic, u-boot-custodians, trini, sjg, robh+dt,
krzysztof.kozlowski+dt, conor, neil.armstrong, caleb.connolly, ff,
daniel.thompson, dgilmore, pbrobinson, ilias.apalodimas,
maxim.uvarov, b.galvani, xypron.glpk, michal.simek, seanga2,
rasmus.villemoes, peng.fan, jh80.chung, rfried.dev, marex,
mibodhi, bb, mark.kettenis
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
^ permalink raw reply [flat|nested] 36+ messages in thread
* [PATCH v4 08/11] doc: devicetree: Updates for devicetree-rebasing subtree
2024-01-10 10:35 [PATCH v4 00/11] An effort to bring DT bindings compliance within U-Boot Sumit Garg
` (6 preceding siblings ...)
2024-01-10 10:35 ` [PATCH v4 07/11] doc: devicetree: Align documentation to use Kconfig options Sumit Garg
@ 2024-01-10 10:35 ` Sumit Garg
2024-01-10 10:35 ` [PATCH v4 09/11] MAINTAINERS: Add myself as devicetree-rebasing maintainer Sumit Garg
` (5 subsequent siblings)
13 siblings, 0 replies; 36+ messages in thread
From: Sumit Garg @ 2024-01-10 10:35 UTC (permalink / raw)
To: u-boot, u-boot-amlogic, u-boot-custodians
Cc: trini, sjg, robh+dt, krzysztof.kozlowski+dt, conor,
neil.armstrong, caleb.connolly, ff, daniel.thompson, dgilmore,
pbrobinson, ilias.apalodimas, maxim.uvarov, b.galvani,
xypron.glpk, michal.simek, seanga2, rasmus.villemoes, peng.fan,
jh80.chung, rfried.dev, marex, mibodhi, bb, mark.kettenis,
Sumit Garg
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-rebasing.git
--
2.34.1
^ permalink raw reply related [flat|nested] 36+ messages in thread* [PATCH v4 09/11] MAINTAINERS: Add myself as devicetree-rebasing maintainer
2024-01-10 10:35 [PATCH v4 00/11] An effort to bring DT bindings compliance within U-Boot Sumit Garg
` (7 preceding siblings ...)
2024-01-10 10:35 ` [PATCH v4 08/11] doc: devicetree: Updates for devicetree-rebasing subtree Sumit Garg
@ 2024-01-10 10:35 ` Sumit Garg
2024-01-10 10:35 ` [PATCH v4 10/11] dts: meson-gxbb: Switch to using upstream DT Sumit Garg
` (4 subsequent siblings)
13 siblings, 0 replies; 36+ messages in thread
From: Sumit Garg @ 2024-01-10 10:35 UTC (permalink / raw)
To: u-boot, u-boot-amlogic, u-boot-custodians
Cc: trini, sjg, robh+dt, krzysztof.kozlowski+dt, conor,
neil.armstrong, caleb.connolly, ff, daniel.thompson, dgilmore,
pbrobinson, ilias.apalodimas, maxim.uvarov, b.galvani,
xypron.glpk, michal.simek, seanga2, rasmus.villemoes, peng.fan,
jh80.chung, rfried.dev, marex, mibodhi, bb, mark.kettenis,
Sumit Garg
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>
--
2.34.1
^ permalink raw reply related [flat|nested] 36+ messages in thread* [PATCH v4 10/11] dts: meson-gxbb: Switch to using upstream DT
2024-01-10 10:35 [PATCH v4 00/11] An effort to bring DT bindings compliance within U-Boot Sumit Garg
` (8 preceding siblings ...)
2024-01-10 10:35 ` [PATCH v4 09/11] MAINTAINERS: Add myself as devicetree-rebasing maintainer Sumit Garg
@ 2024-01-10 10:35 ` Sumit Garg
2024-01-10 10:35 ` [PATCH v4 11/11] dts: meson-gxbb: Drop redundant devicetree files Sumit Garg
` (3 subsequent siblings)
13 siblings, 0 replies; 36+ messages in thread
From: Sumit Garg @ 2024-01-10 10:35 UTC (permalink / raw)
To: u-boot, u-boot-amlogic, u-boot-custodians
Cc: trini, sjg, robh+dt, krzysztof.kozlowski+dt, conor,
neil.armstrong, caleb.connolly, ff, daniel.thompson, dgilmore,
pbrobinson, ilias.apalodimas, maxim.uvarov, b.galvani,
xypron.glpk, michal.simek, seanga2, rasmus.villemoes, peng.fan,
jh80.chung, rfried.dev, marex, mibodhi, bb, mark.kettenis,
Sumit Garg
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
--
2.34.1
^ permalink raw reply related [flat|nested] 36+ messages in thread* [PATCH v4 11/11] dts: meson-gxbb: Drop redundant devicetree files
2024-01-10 10:35 [PATCH v4 00/11] An effort to bring DT bindings compliance within U-Boot Sumit Garg
` (9 preceding siblings ...)
2024-01-10 10:35 ` [PATCH v4 10/11] dts: meson-gxbb: Switch to using upstream DT Sumit Garg
@ 2024-01-10 10:35 ` Sumit Garg
2024-01-19 15:56 ` [PATCH v4 00/11] An effort to bring DT bindings compliance within U-Boot Nishanth Menon
` (2 subsequent siblings)
13 siblings, 0 replies; 36+ messages in thread
From: Sumit Garg @ 2024-01-10 10:35 UTC (permalink / raw)
To: u-boot, u-boot-amlogic, u-boot-custodians
Cc: trini, sjg, robh+dt, krzysztof.kozlowski+dt, conor,
neil.armstrong, caleb.connolly, ff, daniel.thompson, dgilmore,
pbrobinson, ilias.apalodimas, maxim.uvarov, b.galvani,
xypron.glpk, michal.simek, seanga2, rasmus.villemoes, peng.fan,
jh80.chung, rfried.dev, marex, mibodhi, bb, mark.kettenis,
Sumit Garg
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";
-};
--
2.34.1
^ permalink raw reply related [flat|nested] 36+ messages in thread* Re: [PATCH v4 00/11] An effort to bring DT bindings compliance within U-Boot
2024-01-10 10:35 [PATCH v4 00/11] An effort to bring DT bindings compliance within U-Boot Sumit Garg
` (10 preceding siblings ...)
2024-01-10 10:35 ` [PATCH v4 11/11] dts: meson-gxbb: Drop redundant devicetree files Sumit Garg
@ 2024-01-19 15:56 ` Nishanth Menon
2024-01-24 7:15 ` Sumit Garg
2024-01-21 14:33 ` Marek Vasut
2024-01-22 11:45 ` Andre Przywara
13 siblings, 1 reply; 36+ messages in thread
From: Nishanth Menon @ 2024-01-19 15:56 UTC (permalink / raw)
To: Sumit Garg
Cc: u-boot, u-boot-amlogic, u-boot-custodians, trini, sjg, robh+dt,
krzysztof.kozlowski+dt, conor, neil.armstrong, caleb.connolly, ff,
daniel.thompson, dgilmore, pbrobinson, ilias.apalodimas,
maxim.uvarov, b.galvani, xypron.glpk, michal.simek, seanga2,
rasmus.villemoes, peng.fan, jh80.chung, rfried.dev, marex,
mibodhi, bb, mark.kettenis
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"
--
Regards,
Nishanth Menon
Key (0xDDB5849D1736249D) / Fingerprint: F8A2 8693 54EB 8232 17A3 1A34 DDB5 849D 1736 249D
^ permalink raw reply [flat|nested] 36+ messages in thread* Re: [PATCH v4 00/11] An effort to bring DT bindings compliance within U-Boot
2024-01-19 15:56 ` [PATCH v4 00/11] An effort to bring DT bindings compliance within U-Boot Nishanth Menon
@ 2024-01-24 7:15 ` Sumit Garg
0 siblings, 0 replies; 36+ messages in thread
From: Sumit Garg @ 2024-01-24 7:15 UTC (permalink / raw)
To: Nishanth Menon
Cc: u-boot, u-boot-amlogic, u-boot-custodians, trini, sjg, robh+dt,
krzysztof.kozlowski+dt, conor, neil.armstrong, caleb.connolly, ff,
daniel.thompson, dgilmore, pbrobinson, ilias.apalodimas,
maxim.uvarov, b.galvani, xypron.glpk, michal.simek, seanga2,
rasmus.villemoes, peng.fan, jh80.chung, rfried.dev, marex,
mibodhi, bb, mark.kettenis
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
^ permalink raw reply [flat|nested] 36+ messages in thread
* Re: [PATCH v4 00/11] An effort to bring DT bindings compliance within U-Boot
2024-01-10 10:35 [PATCH v4 00/11] An effort to bring DT bindings compliance within U-Boot Sumit Garg
` (11 preceding siblings ...)
2024-01-19 15:56 ` [PATCH v4 00/11] An effort to bring DT bindings compliance within U-Boot Nishanth Menon
@ 2024-01-21 14:33 ` Marek Vasut
2024-01-21 22:41 ` Caleb Connolly
2024-01-22 11:45 ` Andre Przywara
13 siblings, 1 reply; 36+ messages in thread
From: Marek Vasut @ 2024-01-21 14:33 UTC (permalink / raw)
To: Sumit Garg, u-boot, u-boot-amlogic, u-boot-custodians
Cc: trini, sjg, robh+dt, krzysztof.kozlowski+dt, conor,
neil.armstrong, caleb.connolly, ff, daniel.thompson, dgilmore,
pbrobinson, ilias.apalodimas, maxim.uvarov, b.galvani,
xypron.glpk, michal.simek, seanga2, rasmus.villemoes, peng.fan,
jh80.chung, rfried.dev, mibodhi, bb, mark.kettenis
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) ?
^ permalink raw reply [flat|nested] 36+ messages in thread* Re: [PATCH v4 00/11] An effort to bring DT bindings compliance within U-Boot
2024-01-21 14:33 ` Marek Vasut
@ 2024-01-21 22:41 ` Caleb Connolly
2024-01-22 0:01 ` Tom Rini
2024-01-22 0:14 ` Marek Vasut
0 siblings, 2 replies; 36+ messages in thread
From: Caleb Connolly @ 2024-01-21 22:41 UTC (permalink / raw)
To: Marek Vasut, Sumit Garg, u-boot, u-boot-amlogic,
u-boot-custodians
Cc: trini, sjg, robh+dt, krzysztof.kozlowski+dt, conor,
neil.armstrong, ff, daniel.thompson, dgilmore, pbrobinson,
ilias.apalodimas, maxim.uvarov, b.galvani, xypron.glpk,
michal.simek, seanga2, rasmus.villemoes, peng.fan, jh80.chung,
rfried.dev, mibodhi, bb, mark.kettenis
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.
--
// Caleb (they/them)
^ permalink raw reply [flat|nested] 36+ messages in thread
* Re: [PATCH v4 00/11] An effort to bring DT bindings compliance within U-Boot
2024-01-21 22:41 ` Caleb Connolly
@ 2024-01-22 0:01 ` Tom Rini
2024-01-24 7:36 ` Sumit Garg
2024-01-22 0:14 ` Marek Vasut
1 sibling, 1 reply; 36+ messages in thread
From: Tom Rini @ 2024-01-22 0:01 UTC (permalink / raw)
To: Caleb Connolly
Cc: Marek Vasut, Sumit Garg, u-boot, u-boot-amlogic,
u-boot-custodians, sjg, robh+dt, krzysztof.kozlowski+dt, conor,
neil.armstrong, ff, daniel.thompson, dgilmore, pbrobinson,
ilias.apalodimas, maxim.uvarov, b.galvani, xypron.glpk,
michal.simek, seanga2, rasmus.villemoes, peng.fan, jh80.chung,
rfried.dev, mibodhi, bb, mark.kettenis
[-- Attachment #1: Type: text/plain, Size: 883 bytes --]
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.
--
Tom
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 659 bytes --]
^ permalink raw reply [flat|nested] 36+ messages in thread
* Re: [PATCH v4 00/11] An effort to bring DT bindings compliance within U-Boot
2024-01-22 0:01 ` Tom Rini
@ 2024-01-24 7:36 ` Sumit Garg
0 siblings, 0 replies; 36+ messages in thread
From: Sumit Garg @ 2024-01-24 7:36 UTC (permalink / raw)
To: Tom Rini
Cc: Caleb Connolly, Marek Vasut, u-boot, u-boot-amlogic,
u-boot-custodians, sjg, robh+dt, krzysztof.kozlowski+dt, conor,
neil.armstrong, ff, daniel.thompson, dgilmore, pbrobinson,
ilias.apalodimas, maxim.uvarov, b.galvani, xypron.glpk,
michal.simek, seanga2, rasmus.villemoes, peng.fan, jh80.chung,
rfried.dev, mibodhi, bb, mark.kettenis
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
^ permalink raw reply [flat|nested] 36+ messages in thread
* Re: [PATCH v4 00/11] An effort to bring DT bindings compliance within U-Boot
2024-01-21 22:41 ` Caleb Connolly
2024-01-22 0:01 ` Tom Rini
@ 2024-01-22 0:14 ` Marek Vasut
2024-01-24 8:16 ` Sumit Garg
1 sibling, 1 reply; 36+ messages in thread
From: Marek Vasut @ 2024-01-22 0:14 UTC (permalink / raw)
To: Caleb Connolly, Sumit Garg, u-boot, u-boot-amlogic,
u-boot-custodians
Cc: trini, sjg, robh+dt, krzysztof.kozlowski+dt, conor,
neil.armstrong, ff, daniel.thompson, dgilmore, pbrobinson,
ilias.apalodimas, maxim.uvarov, b.galvani, xypron.glpk,
michal.simek, seanga2, rasmus.villemoes, peng.fan, jh80.chung,
rfried.dev, mibodhi, bb, mark.kettenis
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-rebasing.git/refs/
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 ?
^ permalink raw reply [flat|nested] 36+ messages in thread
* Re: [PATCH v4 00/11] An effort to bring DT bindings compliance within U-Boot
2024-01-22 0:14 ` Marek Vasut
@ 2024-01-24 8:16 ` Sumit Garg
2024-01-25 2:03 ` Marek Vasut
0 siblings, 1 reply; 36+ messages in thread
From: Sumit Garg @ 2024-01-24 8:16 UTC (permalink / raw)
To: Marek Vasut
Cc: Caleb Connolly, u-boot, u-boot-amlogic, u-boot-custodians, trini,
sjg, robh+dt, krzysztof.kozlowski+dt, conor, neil.armstrong, ff,
daniel.thompson, dgilmore, pbrobinson, ilias.apalodimas,
maxim.uvarov, b.galvani, xypron.glpk, michal.simek, seanga2,
rasmus.villemoes, peng.fan, jh80.chung, rfried.dev, mibodhi, bb,
mark.kettenis
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-rebasing.git/refs/
>
> 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_JsqLo4nXrJ93dDsfp3UYLs08V02aMnbCCnsDj0MBBomc35w@mail.gmail.com/
-Sumit
^ permalink raw reply [flat|nested] 36+ messages in thread
* Re: [PATCH v4 00/11] An effort to bring DT bindings compliance within U-Boot
2024-01-24 8:16 ` Sumit Garg
@ 2024-01-25 2:03 ` Marek Vasut
2024-01-25 7:24 ` Sumit Garg
0 siblings, 1 reply; 36+ messages in thread
From: Marek Vasut @ 2024-01-25 2:03 UTC (permalink / raw)
To: Sumit Garg
Cc: Caleb Connolly, u-boot, u-boot-amlogic, u-boot-custodians, trini,
sjg, robh+dt, krzysztof.kozlowski+dt, conor, neil.armstrong, ff,
daniel.thompson, dgilmore, pbrobinson, ilias.apalodimas,
maxim.uvarov, b.galvani, xypron.glpk, michal.simek, seanga2,
rasmus.villemoes, peng.fan, jh80.chung, rfried.dev, mibodhi, bb,
mark.kettenis
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-rebasing.git/refs/
>>
>> 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 ?
^ permalink raw reply [flat|nested] 36+ messages in thread
* Re: [PATCH v4 00/11] An effort to bring DT bindings compliance within U-Boot
2024-01-25 2:03 ` Marek Vasut
@ 2024-01-25 7:24 ` Sumit Garg
2024-01-25 15:04 ` Tom Rini
0 siblings, 1 reply; 36+ messages in thread
From: Sumit Garg @ 2024-01-25 7:24 UTC (permalink / raw)
To: Marek Vasut
Cc: Caleb Connolly, u-boot, u-boot-amlogic, u-boot-custodians, trini,
sjg, robh+dt, krzysztof.kozlowski+dt, conor, neil.armstrong, ff,
daniel.thompson, dgilmore, pbrobinson, ilias.apalodimas,
maxim.uvarov, b.galvani, xypron.glpk, michal.simek, seanga2,
rasmus.villemoes, peng.fan, jh80.chung, rfried.dev, mibodhi, bb,
mark.kettenis
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-rebasing.git/refs/
> >>
> >> 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
^ permalink raw reply [flat|nested] 36+ messages in thread
* Re: [PATCH v4 00/11] An effort to bring DT bindings compliance within U-Boot
2024-01-25 7:24 ` Sumit Garg
@ 2024-01-25 15:04 ` Tom Rini
2024-01-25 16:38 ` Marek Vasut
0 siblings, 1 reply; 36+ messages in thread
From: Tom Rini @ 2024-01-25 15:04 UTC (permalink / raw)
To: Sumit Garg
Cc: Marek Vasut, Caleb Connolly, u-boot, u-boot-amlogic,
u-boot-custodians, sjg, robh+dt, krzysztof.kozlowski+dt, conor,
neil.armstrong, ff, daniel.thompson, dgilmore, pbrobinson,
ilias.apalodimas, maxim.uvarov, b.galvani, xypron.glpk,
michal.simek, seanga2, rasmus.villemoes, peng.fan, jh80.chung,
rfried.dev, mibodhi, bb, mark.kettenis
[-- Attachment #1: Type: text/plain, Size: 3753 bytes --]
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.
--
Tom
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 659 bytes --]
^ permalink raw reply [flat|nested] 36+ messages in thread* Re: [PATCH v4 00/11] An effort to bring DT bindings compliance within U-Boot
2024-01-25 15:04 ` Tom Rini
@ 2024-01-25 16:38 ` Marek Vasut
2024-01-25 23:19 ` Tom Rini
0 siblings, 1 reply; 36+ messages in thread
From: Marek Vasut @ 2024-01-25 16:38 UTC (permalink / raw)
To: Tom Rini, Sumit Garg
Cc: Caleb Connolly, u-boot, u-boot-amlogic, u-boot-custodians, sjg,
robh+dt, krzysztof.kozlowski+dt, conor, neil.armstrong, ff,
daniel.thompson, dgilmore, pbrobinson, ilias.apalodimas,
maxim.uvarov, b.galvani, xypron.glpk, michal.simek, seanga2,
rasmus.villemoes, peng.fan, jh80.chung, rfried.dev, mibodhi, bb,
mark.kettenis
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.
^ permalink raw reply [flat|nested] 36+ messages in thread
* Re: [PATCH v4 00/11] An effort to bring DT bindings compliance within U-Boot
2024-01-25 16:38 ` Marek Vasut
@ 2024-01-25 23:19 ` Tom Rini
2024-01-26 2:10 ` Marek Vasut
0 siblings, 1 reply; 36+ messages in thread
From: Tom Rini @ 2024-01-25 23:19 UTC (permalink / raw)
To: Marek Vasut
Cc: Sumit Garg, Caleb Connolly, u-boot, u-boot-amlogic,
u-boot-custodians, sjg, robh+dt, krzysztof.kozlowski+dt, conor,
neil.armstrong, ff, daniel.thompson, dgilmore, pbrobinson,
ilias.apalodimas, maxim.uvarov, b.galvani, xypron.glpk,
michal.simek, seanga2, rasmus.villemoes, peng.fan, jh80.chung,
rfried.dev, mibodhi, bb, mark.kettenis
[-- Attachment #1: Type: text/plain, Size: 2980 bytes --]
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.
--
Tom
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 659 bytes --]
^ permalink raw reply [flat|nested] 36+ messages in thread
* Re: [PATCH v4 00/11] An effort to bring DT bindings compliance within U-Boot
2024-01-25 23:19 ` Tom Rini
@ 2024-01-26 2:10 ` Marek Vasut
2024-01-26 7:04 ` Michal Simek
0 siblings, 1 reply; 36+ messages in thread
From: Marek Vasut @ 2024-01-26 2:10 UTC (permalink / raw)
To: Tom Rini
Cc: Sumit Garg, Caleb Connolly, u-boot, u-boot-amlogic,
u-boot-custodians, sjg, robh+dt, krzysztof.kozlowski+dt, conor,
neil.armstrong, ff, daniel.thompson, dgilmore, pbrobinson,
ilias.apalodimas, maxim.uvarov, b.galvani, xypron.glpk,
michal.simek, seanga2, rasmus.villemoes, peng.fan, jh80.chung,
rfried.dev, mibodhi, bb, mark.kettenis
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 .
^ permalink raw reply [flat|nested] 36+ messages in thread
* Re: [PATCH v4 00/11] An effort to bring DT bindings compliance within U-Boot
2024-01-26 2:10 ` Marek Vasut
@ 2024-01-26 7:04 ` Michal Simek
2024-01-31 12:56 ` Sumit Garg
0 siblings, 1 reply; 36+ messages in thread
From: Michal Simek @ 2024-01-26 7:04 UTC (permalink / raw)
To: Marek Vasut, Tom Rini
Cc: Sumit Garg, Caleb Connolly, u-boot, u-boot-amlogic,
u-boot-custodians, sjg, robh+dt, krzysztof.kozlowski+dt, conor,
neil.armstrong, ff, daniel.thompson, dgilmore, pbrobinson,
ilias.apalodimas, maxim.uvarov, b.galvani, xypron.glpk, seanga2,
rasmus.villemoes, peng.fan, jh80.chung, rfried.dev, mibodhi, bb,
mark.kettenis
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
^ permalink raw reply [flat|nested] 36+ messages in thread
* Re: [PATCH v4 00/11] An effort to bring DT bindings compliance within U-Boot
2024-01-26 7:04 ` Michal Simek
@ 2024-01-31 12:56 ` Sumit Garg
2024-01-31 14:13 ` Tom Rini
0 siblings, 1 reply; 36+ messages in thread
From: Sumit Garg @ 2024-01-31 12:56 UTC (permalink / raw)
To: Tom Rini, Marek Vasut, Michal Simek
Cc: Caleb Connolly, u-boot, u-boot-amlogic, u-boot-custodians, sjg,
robh+dt, krzysztof.kozlowski+dt, conor, neil.armstrong, ff,
daniel.thompson, dgilmore, pbrobinson, ilias.apalodimas,
maxim.uvarov, b.galvani, xypron.glpk, seanga2, rasmus.villemoes,
peng.fan, jh80.chung, rfried.dev, mibodhi, bb, mark.kettenis
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-rebasing.git
$ 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
^ permalink raw reply [flat|nested] 36+ messages in thread
* Re: [PATCH v4 00/11] An effort to bring DT bindings compliance within U-Boot
2024-01-31 12:56 ` Sumit Garg
@ 2024-01-31 14:13 ` Tom Rini
0 siblings, 0 replies; 36+ messages in thread
From: Tom Rini @ 2024-01-31 14:13 UTC (permalink / raw)
To: Sumit Garg
Cc: Marek Vasut, Michal Simek, Caleb Connolly, u-boot, u-boot-amlogic,
u-boot-custodians, sjg, robh+dt, krzysztof.kozlowski+dt, conor,
neil.armstrong, ff, daniel.thompson, dgilmore, pbrobinson,
ilias.apalodimas, maxim.uvarov, b.galvani, xypron.glpk, seanga2,
rasmus.villemoes, peng.fan, jh80.chung, rfried.dev, mibodhi, bb,
mark.kettenis
[-- Attachment #1: Type: text/plain, Size: 667 bytes --]
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-rebasing.git
> $ 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.
--
Tom
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 659 bytes --]
^ permalink raw reply [flat|nested] 36+ messages in thread
* Re: [PATCH v4 00/11] An effort to bring DT bindings compliance within U-Boot
2024-01-10 10:35 [PATCH v4 00/11] An effort to bring DT bindings compliance within U-Boot Sumit Garg
` (12 preceding siblings ...)
2024-01-21 14:33 ` Marek Vasut
@ 2024-01-22 11:45 ` Andre Przywara
2024-01-22 16:49 ` Tom Rini
13 siblings, 1 reply; 36+ messages in thread
From: Andre Przywara @ 2024-01-22 11:45 UTC (permalink / raw)
To: Sumit Garg
Cc: u-boot, u-boot-amlogic, u-boot-custodians, trini, sjg, robh+dt,
krzysztof.kozlowski+dt, conor, neil.armstrong, caleb.connolly, ff,
daniel.thompson, dgilmore, pbrobinson, ilias.apalodimas,
maxim.uvarov, b.galvani, xypron.glpk, michal.simek, seanga2,
rasmus.villemoes, peng.fan, jh80.chung, rfried.dev, marex,
mibodhi, bb, mark.kettenis
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+pDg@mail.gmail.com/
> [2] https://lore.kernel.org/all/CAL_JsqKEjv2tSGmT+0ZiO7_qbBfhTycbGnhJhYpKDFzfO9jzDg@mail.gmail.com/
> [3] https://git.kernel.org/pub/scm/linux/kernel/git/devicetree/devicetree-rebasing.git/
> [4] https://github.com/u-boot/u-boot/pull/451
>
^ permalink raw reply [flat|nested] 36+ messages in thread* Re: [PATCH v4 00/11] An effort to bring DT bindings compliance within U-Boot
2024-01-22 11:45 ` Andre Przywara
@ 2024-01-22 16:49 ` Tom Rini
2024-01-23 0:58 ` Andre Przywara
0 siblings, 1 reply; 36+ messages in thread
From: Tom Rini @ 2024-01-22 16:49 UTC (permalink / raw)
To: Andre Przywara
Cc: Sumit Garg, u-boot, u-boot-amlogic, u-boot-custodians, sjg,
robh+dt, krzysztof.kozlowski+dt, conor, neil.armstrong,
caleb.connolly, ff, daniel.thompson, dgilmore, pbrobinson,
ilias.apalodimas, maxim.uvarov, b.galvani, xypron.glpk,
michal.simek, seanga2, rasmus.villemoes, peng.fan, jh80.chung,
rfried.dev, marex, mibodhi, bb, mark.kettenis
[-- Attachment #1: Type: text/plain, Size: 2315 bytes --]
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?
--
Tom
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 659 bytes --]
^ permalink raw reply [flat|nested] 36+ messages in thread
* Re: [PATCH v4 00/11] An effort to bring DT bindings compliance within U-Boot
2024-01-22 16:49 ` Tom Rini
@ 2024-01-23 0:58 ` Andre Przywara
2024-01-23 16:42 ` Rob Herring
0 siblings, 1 reply; 36+ messages in thread
From: Andre Przywara @ 2024-01-23 0:58 UTC (permalink / raw)
To: Tom Rini
Cc: Sumit Garg, u-boot, u-boot-amlogic, u-boot-custodians, sjg,
robh+dt, krzysztof.kozlowski+dt, conor, neil.armstrong,
caleb.connolly, ff, daniel.thompson, dgilmore, pbrobinson,
ilias.apalodimas, maxim.uvarov, b.galvani, xypron.glpk,
michal.simek, seanga2, rasmus.villemoes, peng.fan, jh80.chung,
rfried.dev, marex, mibodhi, bb, mark.kettenis
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
^ permalink raw reply [flat|nested] 36+ messages in thread
* Re: [PATCH v4 00/11] An effort to bring DT bindings compliance within U-Boot
2024-01-23 0:58 ` Andre Przywara
@ 2024-01-23 16:42 ` Rob Herring
2024-01-24 9:03 ` Sumit Garg
0 siblings, 1 reply; 36+ messages in thread
From: Rob Herring @ 2024-01-23 16:42 UTC (permalink / raw)
To: Andre Przywara
Cc: Tom Rini, Sumit Garg, u-boot, u-boot-amlogic, u-boot-custodians,
sjg, krzysztof.kozlowski+dt, conor, neil.armstrong,
caleb.connolly, ff, daniel.thompson, dgilmore, pbrobinson,
ilias.apalodimas, maxim.uvarov, b.galvani, xypron.glpk,
michal.simek, seanga2, rasmus.villemoes, peng.fan, jh80.chung,
rfried.dev, marex, mibodhi, bb, mark.kettenis
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
^ permalink raw reply [flat|nested] 36+ messages in thread
* Re: [PATCH v4 00/11] An effort to bring DT bindings compliance within U-Boot
2024-01-23 16:42 ` Rob Herring
@ 2024-01-24 9:03 ` Sumit Garg
0 siblings, 0 replies; 36+ messages in thread
From: Sumit Garg @ 2024-01-24 9:03 UTC (permalink / raw)
To: Rob Herring
Cc: Andre Przywara, Tom Rini, u-boot, u-boot-amlogic,
u-boot-custodians, sjg, krzysztof.kozlowski+dt, conor,
neil.armstrong, caleb.connolly, ff, daniel.thompson, dgilmore,
pbrobinson, ilias.apalodimas, maxim.uvarov, b.galvani,
xypron.glpk, michal.simek, seanga2, rasmus.villemoes, peng.fan,
jh80.chung, rfried.dev, marex, mibodhi, bb, mark.kettenis
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
^ permalink raw reply [flat|nested] 36+ messages in thread