Skip to content

Add initial devicetree for Turing RK1

Sam Edwards linux-arm-kernel linux-devicetree linux-rockchip lkml 2 versions – Applied

Status from this message: Applied, thanks!

Get series with b4
b4 am [email protected]

Versions newest first · linked by author and title

  1. v2 Latest3 patches 2 repliesApplied
  2. v13 patches 2 repliesSuperseded

Patches in v2 Applied

#Subject and filesSizeRepliesApplied
1/3dt-bindings: vendor-prefixes: add turingDocumentation/devicetree/bindings/vendor-prefixes.yaml+2 -00 replies
2/3dt-bindings: arm: rockchip: Add Turing RK1Documentation/devicetree/bindings/arm/rockchip.yaml+5 -01 reply
3/3arm64: dts: rockchip: Add Turing RK1 SoM supportarch/arm64/boot/dts/rockchip/Makefile arch/arm64/boot/dts/rockchip/rk3588-turing-rk1.dts arch/arm64/boot/dts/rockchip/rk3588-turing-rk1.dtsi+645 -00 replies

Reviews trailers per patch

2 of 3 patches have a Reviewed-by or Acked-by.

PatchRob Herring
1/3A-b
2/3A-b
3/3

Trailers given in replies are filled; those carried in the patches from earlier versions are outlined with dashes.

Read the v2 thread

Cover letter [PATCH v2 0/3] Add initial devicetree for Turing RK1

Hi again list,

This is the second version of my patch to bring in support for the RK3588-based Turing RK1 SoM. In my previous cover letter, I perhaps should have specified that the RK1 is a little bit unusual in that, though it *is* a true SoM, it is targeted toward home-hosting/edge users directly as a compute node, and as a result the vast majority of users will be seeing it more like a micro-bladeserver, rather than an off-the-shelf part meant to power a larger system. This was my rationale for previously sending this as a single .dts, targeting that use case.

However, Heiko previously made a good point that it still depends on a carrier board to be "complete," and then I reminded myself that not all users will be treating the RK1 like a mere "node" -- some will be incorporating them into larger carriers, which the RK1 is meant to enable (not the other way around).

This version tries to strike a compromise, by moving the SoM-specific stuff to a .dtsi, introducing a .dts specifically for the "opinionated" view of the RK1 as a carrier-agnostic node, and adding another paragraph to the PATCH 3/3 changelog explaining that.

I am wondering if there will be an objection about the .dts having the exact same base filename and compatible as the .dtsi. I am not sure what word/term to use to mean "RK1 but thought of as the system itself and not as a piece of a system," but am open to suggestions. :)

Cheers all,
Sam

Sam Edwards (3):
dt-bindings: vendor-prefixes: add turing
dt-bindings: arm: rockchip: Add Turing RK1
arm64: dts: rockchip: Add Turing RK1 SoM support

 .../devicetree/bindings/arm/rockchip.yaml     |   5 +
 .../devicetree/bindings/vendor-prefixes.yaml  |   2 +
 arch/arm64/boot/dts/rockchip/Makefile         |   1 +
 .../boot/dts/rockchip/rk3588-turing-rk1.dts   |  21 +
 .../boot/dts/rockchip/rk3588-turing-rk1.dtsi  | 623 ++++++++++++++++++
 5 files changed, 652 insertions(+)
 create mode 100644 arch/arm64/boot/dts/rockchip/rk3588-turing-rk1.dts
 create mode 100644 arch/arm64/boot/dts/rockchip/rk3588-turing-rk1.dtsi
Signature · 1 line
2.41.0