From: Yao Zi <ziyao@disroot.org>
To: Alex Bee <knaerzche@gmail.com>, Jonas Karlman <jonas@kwiboo.se>
Cc: Heiko Stuebner <heiko@sntech.de>, Rob Herring <robh@kernel.org>,
Krzysztof Kozlowski <krzk+dt@kernel.org>,
Conor Dooley <conor+dt@kernel.org>,
Chukun Pan <amadeus@jmu.edu.cn>,
linux-rockchip@lists.infradead.org, devicetree@vger.kernel.org,
linux-arm-kernel@lists.infradead.org,
linux-kernel@vger.kernel.org
Subject: Re: [PATCH v3 0/6] arm64: dts: rockchip: Add ROCK 2A/2F, Sige1 and NanoPi Zero2
Date: Mon, 14 Jul 2025 01:00:08 +0000 [thread overview]
Message-ID: <aHRWmMFTh7leEhrq@pie.lan> (raw)
In-Reply-To: <88c7b90d-4c29-453b-9a5c-9679b371a3a9@gmail.com>
On Sun, Jul 13, 2025 at 10:56:59PM +0200, Alex Bee wrote:
> Hi Jonas,
>
> > Hi Alex,
> >
> > On 7/13/2025 9:13 PM, Alex Bee wrote:
> > > Hi list, Hi Jonas,
> > >
> > > > This series adds dt-bindings and initial device tree for the following
> > > > Rockchip RK3528A boards:
> > > > - Radxa ROCK 2A/2F
> > > > - ArmSoM Sige1
> > > > - FriendlyElec NanoPi Zero2
> > >
> > > this only sub-related to this series: Is there any particular reason, why
> > > we call the compatible "rockchip,rk3528" and not "rockchip,rk3528a"? From
> > > what I can see all boards currently supported (and those in this series)
> > > are having the RK3528A version of the SoC. I didn't follow the development
> > > here, but there are differences - I did a quick compare of the datasheets
> > > of those two SoC versions - it looks like RK3528 version has USB3-DRD
> > > controller, while RK3528A has USB3 host-only controller. Also it seems to
> > > have different video codec IPs and the DRAM controller additionally
> > > supports LPDDR4X.
> > What datasheet versions did you check? I can only find:
> > - RK3528 Rev 1.0 (2023-05-22)
> > - RK3528A Rev 1.2 (2024-04-10)
> I used
>
> 2023-07-12 Revision V1.0
>
> which didn't include these features - which is interesting: Why would a
> SoC vendor not try to sell all features in the first place :)
>
> But I now double checked in
>
> 2025-05-12 Revision 1.4
>
> and you are right: It appears there also for RK3528A.
>
> The only difference I could now make out by comparing v1.4 of both versions
> is the cipher engine: RK3528 additionally supports "SM2/SM3/SM4 cipher" -
> but still it exists and additionally the different video codec (if mpp
> userspace library is correct about that).
>
> Anyway: My question was more about: Why didn't we choose the correct
> compatible from the beginning? And of course the dts files would have to be
> renamed if the compatible is changed, as they are named according to their
> SoC-compatible.
Just like what Jonas said, I was not aware of any technical
documentation at the time of writing the basic devicetree, and even for
now the only datasheet I manage to find is the 2023 revision about
RK3528 without A suffix, so I didn't realize the difference between
RK3528 and RK3528A, but just followed the vendor code and devicetree[1],
where only RK3528 is mentioned :-(
Regards,
Yao Zi
[1]: https://github.com/rockchip-linux/kernel, branch develop-5.10
> Regards,
> Alex
> >
> > And both list LPDDR4X support and the A-variant seem to list USB3-DRD
> > support, did you mix them up above?
> >
> > I think these SoCs are similar to rk3228/rk3229, rk3228h/rk3328 and now
> > rk3528/rk3528a, in that only the second variant support VP9 decoding.
> >
> > Use of rockchip,rk3528a compatible could be something to change,
> > could also be something that bootloader set at runtime, similar to
> > what it does for rk3288w.
> >
> > > I guess it would be good to discuss this before this series is merged,
> > > because re-naming *.dts files after they have been in a release is somewhat
> > > impossible.
> > I think renaming the device tree files is unnecessary, as there seem to
> > be very little difference. All boards I have come across are currently
> > RK3528A variants. How would we treat the Radxa E20C?, it is not named
> > rk3528-radxa-e20c.dtb, yet uses the A-variant.
> >
> > For mainline U-Boot I have included printing out the SoC-variant,
> > however the compatible is not adjusted:
> >
> > Model: Radxa E20C
> > SoC: RK3528A
> > DRAM: 2 GiB
> >
> > Regards,
> > Jonas
> >
> > > Regards,
> > > Alex
> > > > The bt/wifi_reg_on pins are described in the device tree using
> > > > rfkill-gpio nodes.
> > > >
> > > > Changes in v3:
> > > > - Rename led nodes to led-0/led-1
> > > > - Remove pinctrl* props from sdio0
> > > > - Collect a-b tags
> > > >
> > > > Changes in v2:
> > > > - Limit sdmmc max-frequency to 100 MHz on ROCK 2A/2F
> > > > - Drop clock-output-names prop from rtc node on Sige1 and NanoPi Zero2
> > > > - Drop regulator-boot-on from usb 2.0 host regulators on Sige1
> > > > - Add bluetooth and wifi nodes on Sige1
> > > > - Collect t-b tag for NanoPi Zero2
> > > >
> > > > These boards can be booted from emmc or sd-card using the U-Boot 2025.07
> > > > generic-rk3528 target or work-in-progress patches for these boards [1].
> > > >
> > > > For working bluetooth on ArmSoM Sige1 the patch "arm64: dts: rockchip:
> > > > Fix UART DMA support for RK3528" [2] is required.
> > > >
> > > > [1] https://source.denx.de/u-boot/contributors/kwiboo/u-boot/-/commits/rk3528
> > > > [2] https://lore.kernel.org/r/20250709210831.3170458-1-jonas@kwiboo.se
> > > >
> > > > Jonas Karlman (6):
> > > > dt-bindings: arm: rockchip: Add Radxa ROCK 2A/2F
> > > > arm64: dts: rockchip: Add Radxa ROCK 2A/2F
> > > > dt-bindings: arm: rockchip: Add ArmSoM Sige1
> > > > arm64: dts: rockchip: Add ArmSoM Sige1
> > > > dt-bindings: arm: rockchip: Add FriendlyElec NanoPi Zero2
> > > > arm64: dts: rockchip: Add FriendlyElec NanoPi Zero2
> > > >
> > > > .../devicetree/bindings/arm/rockchip.yaml | 17 +
> > > > arch/arm64/boot/dts/rockchip/Makefile | 4 +
> > > > .../boot/dts/rockchip/rk3528-armsom-sige1.dts | 465 ++++++++++++++++++
> > > > .../boot/dts/rockchip/rk3528-nanopi-zero2.dts | 340 +++++++++++++
> > > > .../boot/dts/rockchip/rk3528-rock-2.dtsi | 293 +++++++++++
> > > > .../boot/dts/rockchip/rk3528-rock-2a.dts | 82 +++
> > > > .../boot/dts/rockchip/rk3528-rock-2f.dts | 10 +
> > > > 7 files changed, 1211 insertions(+)
> > > > create mode 100644 arch/arm64/boot/dts/rockchip/rk3528-armsom-sige1.dts
> > > > create mode 100644 arch/arm64/boot/dts/rockchip/rk3528-nanopi-zero2.dts
> > > > create mode 100644 arch/arm64/boot/dts/rockchip/rk3528-rock-2.dtsi
> > > > create mode 100644 arch/arm64/boot/dts/rockchip/rk3528-rock-2a.dts
> > > > create mode 100644 arch/arm64/boot/dts/rockchip/rk3528-rock-2f.dts
> > > >
next prev parent reply other threads:[~2025-07-14 1:00 UTC|newest]
Thread overview: 33+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-07-12 17:37 Jonas Karlman
2025-07-12 17:37 ` [PATCH v3 1/6] dt-bindings: arm: rockchip: Add Radxa ROCK 2A/2F Jonas Karlman
2025-07-12 17:37 ` [PATCH v3 2/6] arm64: dts: " Jonas Karlman
2025-07-13 13:39 ` Yao Zi
2025-07-14 9:44 ` Nicolas Frattaroli
2025-07-14 10:49 ` Jonas Karlman
2025-07-14 11:15 ` Nicolas Frattaroli
2025-07-12 17:37 ` [PATCH v3 3/6] dt-bindings: arm: rockchip: Add ArmSoM Sige1 Jonas Karlman
2025-07-12 17:37 ` [PATCH v3 4/6] arm64: dts: " Jonas Karlman
2025-07-15 14:01 ` Chukun Pan
2025-07-15 14:21 ` Jonas Karlman
2025-07-16 7:00 ` Chukun Pan
2025-07-12 17:37 ` [PATCH v3 5/6] dt-bindings: arm: rockchip: Add FriendlyElec NanoPi Zero2 Jonas Karlman
2025-07-12 17:37 ` [PATCH v3 6/6] arm64: dts: " Jonas Karlman
2025-07-13 19:13 ` [PATCH v3 0/6] arm64: dts: rockchip: Add ROCK 2A/2F, Sige1 and " Alex Bee
2025-07-13 20:13 ` Jonas Karlman
2025-07-13 20:56 ` Alex Bee
2025-07-14 0:04 ` Jonas Karlman
2025-07-14 5:53 ` Alex Bee
2025-07-15 18:56 ` Heiko Stübner
2025-07-19 9:58 ` Alex Bee
2025-07-19 14:30 ` Chukun Pan
2025-07-19 16:07 ` Alex Bee
2025-07-20 9:45 ` Alex Bee
2025-07-20 13:40 ` Chukun Pan
2025-07-20 15:51 ` Alex Bee
2025-07-21 14:00 ` Chukun Pan
2025-07-21 18:07 ` Alex Bee
2025-07-23 13:40 ` Chukun Pan
2025-07-26 11:07 ` Alex Bee
2025-07-14 1:00 ` Yao Zi [this message]
2025-07-14 8:52 ` Nicolas Frattaroli
2025-07-14 15:24 ` Rob Herring (Arm)
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=aHRWmMFTh7leEhrq@pie.lan \
--to=ziyao@disroot.org \
--cc=amadeus@jmu.edu.cn \
--cc=conor+dt@kernel.org \
--cc=devicetree@vger.kernel.org \
--cc=heiko@sntech.de \
--cc=jonas@kwiboo.se \
--cc=knaerzche@gmail.com \
--cc=krzk+dt@kernel.org \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-rockchip@lists.infradead.org \
--cc=robh@kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox
all inboxes | Powered by JetHome®