Re: [PATCH v1 4/5] arm64: dts: rockchip: add core dtsi for RK3568 SoC

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Hi Heiko, Ezequiel,

On 2021/4/23 上午1:23, Ezequiel Garcia wrote:
Hi Liang,

I'm very impressed Rockchip is pushing patches so early, thanks a lot!

See below.

On Wed, 2021-04-21 at 11:13 +0200, Heiko Stübner wrote:
Hi Liang,

Am Mittwoch, 21. April 2021, 08:59:20 CEST schrieb cl@xxxxxxxxxxxxxx:
From: Liang Chen <cl@xxxxxxxxxxxxxx>

RK3568 is a high-performance and low power quad-core application processor
designed for personal mobile internet device and AIoT equipments.

This patch add basic core dtsi file for it.

Signed-off-by: Liang Chen <cl@xxxxxxxxxxxxxx>
this is a first round of basic stuff :-) .

First of all, I really like the move of moving the pretty standardized
pinconfig entries to the rockchip-pinconf.dtsi .

(1) But please move this into a separate patch to make that more visible
and maybe even convert _some_ or all arm64 Rockchip socs to use that
as well

"arm64: dts: rockchip: add generic pinconfig settings used by most Rockchip socs

The pinconfig settings for Rockchip SoCs are pretty similar on all socs,
so move them to a shared dtsi to be included, instead of redefining them
for each soc"

(2) I also like the external rk3568-pinctrl approach with the dtsi getting
auto-generated. This will probably help us in keeping pinctrl settings
synchronous between mainline and the vendor kernel.

(3) From my basic understanding the rk3568 is basically a rk3566 + more
peripherals, so ideally they would share the basic ones in a rk3566.dtsi
which the rk3568.dtsi then could include and extend with its additional
peripherals.

With at least the pine64 boards being based on the rk3566, there probably
will be quite a mainline use of it as well.

Or is there something that would prevent this?

I agree with having a rk3566.dtsi, and rk3568.dtsi on top, instead of the
other way around. We have some RK3566 boards here, so we can surely test
the RK3566.dtsi patches very quickly.
We consider rk3568 as a full implementation and rk3566 is a subset, all the dts compatible string for driver should go with string 'rk3568', and rk3568 will be the long term version and definitely have more boards  in next few years. So we would like to upstream rk3568 first and follow the implement mode
of PX30+RK3326, which can also cover the need by RK3566.

We can have a rk3566.dtsi like rk3326.dtsi.


Thanks,
- Kever

Also, it's fine if you want to send v2 with just these minimal peripherals.
However, I think you could include GMAC and TS-ADC:

https://lore.kernel.org/linux-rockchip/31c2e531-96d0-a1c1-644c-28c60eb40cf4@xxxxxxxxx/T/#t
https://lore.kernel.org/linux-rockchip/20210421203409.40717-1-ezequiel@xxxxxxxxxxxxx/T/#t

These should work right out of the box!

Thanks!
Ezequiel








[Index of Archives]     [Kernel Newbies]     [Security]     [Netfilter]     [Bugtraq]     [Linux PPP]     [Linux FS]     [Yosemite News]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Samba]     [Video 4 Linux]     [Linmodem]     [Device Mapper]     [Linux Kernel for ARM]

  Powered by Linux