| Message ID | 20240829092705.6241-1-ziyao@disroot.org |
|---|---|
| Headers | show |
| Series | Add initial support for Rockchip RK3528 SoC | expand |
On Thu, Aug 29, 2024 at 09:27:01AM +0000, Yao Zi wrote: > Rockchip RK3528 is a quad-core ARM Cortex-A53 SoC designed for > multimedia application. This series add a basic device tree with CPU, > interrupts and UART nodes for it and is able to boot into a kernel with > only UART console. > > Has been tested on Radxa E20C board[1] with vendor U-boot, successfully > booted into initramfs with this log[2]. > > [1]: https://docs.radxa.com/en/e/e20c > [2]: https://gist.github.com/ziyao233/b74523a1e3e8bf36286a572e008ca319 > > Changed from v3: > - move mmio devices into soc node > https://lore.kernel.org/all/20240814155014.18097-1-ziyao@disroot.org/ > > Changed from v2: > - fix fixed-clock nodename > https://lore.kernel.org/all/20240811140725.64866-1-ziyao@disroot.org/ > > Changed from v1: > - fix stdout-path > - style improvements > https://lore.kernel.org/all/20240803125510.4699-2-ziyao@disroot.org/ > > Yao Zi (4): > dt-bindings: serial: snps-dw-apb-uart: Document Rockchip RK3528 > dt-bindings: arm: rockchip: Add Radxa E20C board > arm64: dts: rockchip: Add base DT for rk3528 SoC > arm64: dts: rockchip: Add Radxa e20c board > > .../devicetree/bindings/arm/rockchip.yaml | 5 + > .../bindings/serial/snps-dw-apb-uart.yaml | 1 + > arch/arm64/boot/dts/rockchip/Makefile | 1 + > .../boot/dts/rockchip/rk3528-radxa-e20c.dts | 22 ++ > arch/arm64/boot/dts/rockchip/rk3528.dtsi | 189 ++++++++++++++++++ > 5 files changed, 218 insertions(+) > create mode 100644 arch/arm64/boot/dts/rockchip/rk3528-radxa-e20c.dts > create mode 100644 arch/arm64/boot/dts/rockchip/rk3528.dtsi > > -- > 2.46.0 > Ping on this thread. Is it possible to get this merged in v6.12? Or anything else I need to do? Thanks for your time. Best regards, Yao Zi
Hey, Am Dienstag, 17. September 2024, 22:14:36 CEST schrieb Yao Zi: > On Thu, Aug 29, 2024 at 09:27:01AM +0000, Yao Zi wrote: > > Rockchip RK3528 is a quad-core ARM Cortex-A53 SoC designed for > > multimedia application. This series add a basic device tree with CPU, > > interrupts and UART nodes for it and is able to boot into a kernel with > > only UART console. > > > > Has been tested on Radxa E20C board[1] with vendor U-boot, successfully > > booted into initramfs with this log[2]. > Ping on this thread. Is it possible to get this merged in v6.12? Or > anything else I need to do? sadly nope. From a timeline point of view things should ideally be in the Rockchip tree by -rc6 . Which then move to the soc tree and from there to Linus' tree. There is this rule that all new development for a -rc1 kernel should be present in linux-next _before_ the merge-window opens. The thing we need to figure out for your series is the uart binding, because that _should_ go through the tree handling serial drivers. Greg is in your cc list but with the amount of mail he gets, I don't think he has single-parts of patch series on his radar. So I guess the easiest way would be to send the uart-binding from patch 1 as a completely separate patch with adapted Cc list, so that it's obvious this should go through the serial tree. From talking with Collabora people today at the Open Source Summit, it seems that's also their plan for the rk3576 that is stuck at a similar state. Hope that helps a bit to explain Heiko
On Wed, Sep 18, 2024 at 01:13:25AM +0200, Heiko Stuebner wrote: > Hey, > > Am Dienstag, 17. September 2024, 22:14:36 CEST schrieb Yao Zi: > > On Thu, Aug 29, 2024 at 09:27:01AM +0000, Yao Zi wrote: > > > Rockchip RK3528 is a quad-core ARM Cortex-A53 SoC designed for > > > multimedia application. This series add a basic device tree with CPU, > > > interrupts and UART nodes for it and is able to boot into a kernel with > > > only UART console. > > > > > > Has been tested on Radxa E20C board[1] with vendor U-boot, successfully > > > booted into initramfs with this log[2]. > > > Ping on this thread. Is it possible to get this merged in v6.12? Or > > anything else I need to do? > > sadly nope. From a timeline point of view things should ideally be in the > Rockchip tree by -rc6 . Which then move to the soc tree and from there > to Linus' tree. > > There is this rule that all new development for a -rc1 kernel should be > present in linux-next _before_ the merge-window opens. > > The thing we need to figure out for your series is the uart binding, > because that _should_ go through the tree handling serial drivers. > Greg is in your cc list but with the amount of mail he gets, I don't > think he has single-parts of patch series on his radar. Yeah, I missed this as it was part of a larger series. > So I guess the easiest way would be to send the uart-binding from patch 1 > as a completely separate patch with adapted Cc list, so that it's obvious > this should go through the serial tree. Yes, please just send that one patch and I can pick it up. thanks, greg k-h
On Wed, Sep 18, 2024 at 01:13:25AM +0200, Heiko Stuebner wrote: > Hey, > > Am Dienstag, 17. September 2024, 22:14:36 CEST schrieb Yao Zi: > > On Thu, Aug 29, 2024 at 09:27:01AM +0000, Yao Zi wrote: > > > Rockchip RK3528 is a quad-core ARM Cortex-A53 SoC designed for > > > multimedia application. This series add a basic device tree with CPU, > > > interrupts and UART nodes for it and is able to boot into a kernel with > > > only UART console. > > > > > > Has been tested on Radxa E20C board[1] with vendor U-boot, successfully > > > booted into initramfs with this log[2]. > > > Ping on this thread. Is it possible to get this merged in v6.12? Or > > anything else I need to do? > > sadly nope. From a timeline point of view things should ideally be in the > Rockchip tree by -rc6 . Which then move to the soc tree and from there > to Linus' tree. > > There is this rule that all new development for a -rc1 kernel should be > present in linux-next _before_ the merge-window opens. > > The thing we need to figure out for your series is the uart binding, > because that _should_ go through the tree handling serial drivers. > Greg is in your cc list but with the amount of mail he gets, I don't > think he has single-parts of patch series on his radar. > > So I guess the easiest way would be to send the uart-binding from patch 1 > as a completely separate patch with adapted Cc list, so that it's obvious > this should go through the serial tree. Will do it, thanks for the suggestion. > From talking with Collabora people today at the Open Source Summit, it > seems that's also their plan for the rk3576 that is stuck at a similar > state. > > > Hope that helps a bit to explain Thanks for your reply. Cheers, Yao Zi