[PATCH 04/16] dts: k1: import pinctrl dts file from upstream folder

[Tom Rini]

On Thu, May 07, 2026 at 07:59:41PM +0800, Guodong Xu wrote:
> Hi Tom, Conor, Heinrich, Yao Zi,
> 
> 
> On Thu, Apr 30, 2026 at 10:33 PM Tom Rini <trini at konsulko.com> wrote:
> >
> > On Thu, Apr 30, 2026 at 07:21:58AM +0200, Heinrich Schuchardt wrote:
> > > Am 30. April 2026 03:26:38 MESZ schrieb Yao Zi <me at ziyao.cc>:
> > > >On Wed, Apr 29, 2026 at 08:48:39PM +0100, Conor Dooley wrote:
> > > >> On Wed, Apr 22, 2026 at 10:31:00AM -0400, Raymond Mao wrote:
> > > >> > From: Raymond Mao <raymond.mao at riscstar.com>
> > > >> >
> > > >> > Import k1-pinctrl.dtsi from upstream folder.
> > > >>
> > > >> Why doesn't the platform just use the upstream dts directly?
> > > >
> > > >AFAIK, U-Boot's reset driver for SpacemiT K1 predates land of the
> > > >kernel side driver, and follows a complete different (and to me,
> > > >broken since it combines completely unrelated MMIO regions) ABI.
> > >
> > > Shouldn't we first correct the reset drivers and switch to the upstream kernel device-tree before adding anything new? - This would reduce future rework.
> >
> > Exactly. That's a condition of bringing stuff in to U-Boot before it's
> > accepted to the kernel. It *must* be updated once the kernel folks have
> > provided feedback, we do not diverge.
> >
> 
> Chiming in as one of the K1 platform contributors.
> 
> Yao Zi is right about the reset driver. U-Boot's spacemit,k1-reset driver
> predates the current kernel binding. The kernel K1 reset driver was reworked
> to use the auxiliary-device mechanism during upstream review. At that
> point the kernel DTS (arch/riscv/boot/dts/spacemit/k1.dtsi) dropped its
> reset-controller node. And it is from there, the K1 uboot and kernel dts/dtsi
> files starting to diverge with each other.
> 
> To pull them back together, with the goal to reuse the kernel dts,
> we plan to:
> 
> 1. Refactor U-Boot's K1 reset driver to be spawned from each per-syscon
> clock driver via device_bind_driver_to_node(), called from the .bind
> hook in drivers/clk/spacemit/clk-k1.c. More study is requried but for
> now we think this is the correct way. After the refactor, the K1
> build should be able to switch dts/upstream/src/riscv/spacemit/, with
> a simple U-Boot specifics layered as <board>-u-boot.dtsi overlays.
> 
> 2. After the refactor, we'll rebase the still in-flight K1 SPL bring-up
> work [1] and the PIN/SPI series [2] (this one) on top, dropping
> the patches that imported the forked DT, and resend.
> 
> Could you confirm this matches your direction? If so, we'll send the
> K1 reset driver refactor as a standalone series first.
> 
> Link: https://lore.kernel.org/u-boot/20260325223232.1553212-1-raymondmaoca@gmail.com/
> [1]
> [PATCH v3 00/16] Add board support for Spacemit K1 SoC in SPL
> 
> Link: https://lore.kernel.org/u-boot/20260422143112.1329478-1-raymondmaoca@gmail.com/
> [2]
> [PATCH 00/16] Add PIN and SPI support for Spacemit K1

From my point of view, yes, whatever is needed such that we can use the
upstream bindings again makes sense and I'll defer to you about how is
best given the SoC design. Thanks!

-- 
Tom
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 228 bytes
Desc: not available
URL: <https://lists.denx.de/pipermail/u-boot/attachments/20260507/00510881/attachment.sig>