[PATCH v5 00/10] riscv: add initial support for SpacemiT K1

[Yixun Lan]

Hi Conor:

On 15:04 Sun 15 Dec     , Conor Dooley wrote:
> On Thu, Dec 12, 2024 at 06:19:01PM +0800, Yixun Lan wrote:
> > Hi Conor:
> > 
> > On 22:33 Wed 11 Dec     , patchwork-bot+linux-riscv at kernel.org wrote:
> > > Hello:
> > > 
> > > This series was applied to riscv/linux.git (fixes)
> > > by Conor Dooley <conor.dooley at microchip.com>:
> > > 
> > > On Tue, 30 Jul 2024 00:28:03 +0000 you wrote:
> > > > SpacemiT K1 is an ideal chip for some new extension such as RISC-V Vector
> > > > 1.0 and Zicond evaluation now. Add initial support for it to allow more
> > > > people to participate in building drivers to mainline for it.
> > > > 
> > > > This kernel has been tested upon Banana Pi BPI-F3 board on vendor U-Boot
> > > > bootflow generated by Armbian SDK[1] and patched OpenSBI[2] to enable
> > > > Zicboz, which does not in the vendor dts on its U-Boot. Then successfully
> > > > booted to busybox on initrd with this log[3].
> > > > 
> > > > [...]
> > > 
> > > Here is the summary with links:
> > >   - [v5,01/10] dt-bindings: vendor-prefixes: add spacemit
> > >     https://git.kernel.org/riscv/c/7cf3e9bfc63d
> > If I understand correctly, only patch [01/10] of this series was accepted
> > to 6.13-rc1
> > 
> > for the rest of patches, they would be expected to go through SpacemiT's
> > SoC tree? which should I take care of them.. so if no objection, I'd like to
> > queue them at branch k1/dt-for-next [1] first, we might rebase or revert if
> > something happens before merging (since the clock driver is still under review)
> > 
> > Let me know what you think..
> 
> Sure. I had grabbed the first patch because a couple trees needed the

No problem, thanks for helping on this

> vendor prefix for peripheral drivers. How is the clock driver getting
> on? Do you think it is close to being merged?

The clock driver's review is still on-going, the biggest concern is about
the mix clock implementation [1], which isn't decent, and Haylen's working on
to have a better version, I'd hope we can catch this in 6.14's merge window..

But, in the worst case if we have to postpone clock to next merge window,
would you think it's ok to push the basic dts and pinctrl dts first?
IMHO, they have no hard dependency on clock driver, and pushing them
first would simplify the future developement..

http://lore.kernel.org/r/Z2LBsQ7a3T3mElLl@ketchup [1]

-- 
Yixun Lan (dlan)
Gentoo Linux Developer
GPG Key ID AABEFD55