| Message ID | 20260422143112.1329478-5-raymondmaoca@gmail.com |
|---|---|
| State | New |
| Delegated to: | Andes |
| Headers | show |
| Series | Add PIN and SPI support for Spacemit K1 | expand |
On Wed, Apr 22, 2026 at 10:31:00AM -0400, Raymond Mao wrote: > From: Raymond Mao <raymond.mao@riscstar.com> > > Import k1-pinctrl.dtsi from upstream folder. Why doesn't the platform just use the upstream dts directly?
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@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. U-Boot's version, reset: reset-controller@d4050000 { compatible = "spacemit,k1-reset"; reg = <0x0 0xd4050000 0x0 0x209c>, <0x0 0xd4282800 0x0 0x400>, <0x0 0xd4015000 0x0 0x1000>, <0x0 0xd4090000 0x0 0x1000>, <0x0 0xd4282c00 0x0 0x400>, <0x0 0xd8440000 0x0 0x98>, <0x0 0xc0000000 0x0 0x4280>, <0x0 0xf0610000 0x0 0x20>; reg-names = "mpmu", "apmu", "apbc", "apbs", "ciu", "dciu", "ddrc", "apbc2"; #reset-cells = <1>; status = "disabled"; }; Kernel's version, syscon_apmu: system-controller@d4282800 { compatible = "spacemit,k1-syscon-apmu"; reg = <0x0 0xd4282800 0x0 0x400>; clocks = <&osc_32k>, <&vctcxo_1m>, <&vctcxo_3m>, <&vctcxo_24m>; clock-names = "osc", "vctcxo_1m", "vctcxo_3m", "vctcxo_24m"; #clock-cells = <1>; #power-domain-cells = <1>; #reset-cells = <1>; }; (and many other independent system-controller nodes, each for a distinct MMIO region) I suspect we have to deal with the difference before switching to upstream devicetree, since I2C controllers introduced in this series do depend on resets. Regards, Yao Zi
Am 30. April 2026 03:26:38 MESZ schrieb Yao Zi <me@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@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. Best regards Heinrich > >U-Boot's version, > > reset: reset-controller@d4050000 { > compatible = "spacemit,k1-reset"; > reg = <0x0 0xd4050000 0x0 0x209c>, > <0x0 0xd4282800 0x0 0x400>, > <0x0 0xd4015000 0x0 0x1000>, > <0x0 0xd4090000 0x0 0x1000>, > <0x0 0xd4282c00 0x0 0x400>, > <0x0 0xd8440000 0x0 0x98>, > <0x0 0xc0000000 0x0 0x4280>, > <0x0 0xf0610000 0x0 0x20>; > reg-names = "mpmu", "apmu", "apbc", "apbs", "ciu", "dciu", "ddrc", "apbc2"; > #reset-cells = <1>; > status = "disabled"; > }; > >Kernel's version, > > syscon_apmu: system-controller@d4282800 { > compatible = "spacemit,k1-syscon-apmu"; > reg = <0x0 0xd4282800 0x0 0x400>; > clocks = <&osc_32k>, <&vctcxo_1m>, <&vctcxo_3m>, > <&vctcxo_24m>; > clock-names = "osc", "vctcxo_1m", "vctcxo_3m", > "vctcxo_24m"; > #clock-cells = <1>; > #power-domain-cells = <1>; > #reset-cells = <1>; > }; > > (and many other independent system-controller nodes, each for a > distinct MMIO region) > >I suspect we have to deal with the difference before switching to >upstream devicetree, since I2C controllers introduced in this series >do depend on resets. > >Regards, >Yao Zi
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@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@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.
Hi Tom, Conor, Heinrich, Yao Zi, On Thu, Apr 30, 2026 at 10:33 PM Tom Rini <trini@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@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@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 Thanks, Guodong > -- > Tom
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@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@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@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!
diff --git a/arch/riscv/dts/k1-pinctrl.dtsi b/arch/riscv/dts/k1-pinctrl.dtsi index 14e7096fbcf..aff19c86d5f 100644 --- a/arch/riscv/dts/k1-pinctrl.dtsi +++ b/arch/riscv/dts/k1-pinctrl.dtsi @@ -1,12 +1,64 @@ -// SPDX-License-Identifier: (GPL-2.0 OR MIT) +// SPDX-License-Identifier: GPL-2.0 OR MIT /* - * Copyright (C) 2022 Spacemit Inc. - * Copyright (C) 2025 Yixun Lan <dlan@gentoo.org> + * Copyright (c) 2024 Yixun Lan <dlan@gentoo.org> */ +#include <dt-bindings/gpio/gpio.h> + #define K1_PADCONF(pin, func) (((pin) << 16) | (func)) +/* Map GPIO pin to each bank's <index, offset> */ +#define K1_GPIO(x) (x / 32) (x % 32) + &pinctrl { + gmac0_cfg: gmac0-cfg { + gmac0-pins { + pinmux = <K1_PADCONF(0, 1)>, /* gmac0_rxdv */ + <K1_PADCONF(1, 1)>, /* gmac0_rx_d0 */ + <K1_PADCONF(2, 1)>, /* gmac0_rx_d1 */ + <K1_PADCONF(3, 1)>, /* gmac0_rx_clk */ + <K1_PADCONF(4, 1)>, /* gmac0_rx_d2 */ + <K1_PADCONF(5, 1)>, /* gmac0_rx_d3 */ + <K1_PADCONF(6, 1)>, /* gmac0_tx_d0 */ + <K1_PADCONF(7, 1)>, /* gmac0_tx_d1 */ + <K1_PADCONF(8, 1)>, /* gmac0_tx */ + <K1_PADCONF(9, 1)>, /* gmac0_tx_d2 */ + <K1_PADCONF(10, 1)>, /* gmac0_tx_d3 */ + <K1_PADCONF(11, 1)>, /* gmac0_tx_en */ + <K1_PADCONF(12, 1)>, /* gmac0_mdc */ + <K1_PADCONF(13, 1)>, /* gmac0_mdio */ + <K1_PADCONF(14, 1)>, /* gmac0_int_n */ + <K1_PADCONF(45, 1)>; /* gmac0_clk_ref */ + + bias-pull-up = <0>; + drive-strength = <21>; + }; + }; + + gmac1_cfg: gmac1-cfg { + gmac1-pins { + pinmux = <K1_PADCONF(29, 1)>, /* gmac1_rxdv */ + <K1_PADCONF(30, 1)>, /* gmac1_rx_d0 */ + <K1_PADCONF(31, 1)>, /* gmac1_rx_d1 */ + <K1_PADCONF(32, 1)>, /* gmac1_rx_clk */ + <K1_PADCONF(33, 1)>, /* gmac1_rx_d2 */ + <K1_PADCONF(34, 1)>, /* gmac1_rx_d3 */ + <K1_PADCONF(35, 1)>, /* gmac1_tx_d0 */ + <K1_PADCONF(36, 1)>, /* gmac1_tx_d1 */ + <K1_PADCONF(37, 1)>, /* gmac1_tx */ + <K1_PADCONF(38, 1)>, /* gmac1_tx_d2 */ + <K1_PADCONF(39, 1)>, /* gmac1_tx_d3 */ + <K1_PADCONF(40, 1)>, /* gmac1_tx_en */ + <K1_PADCONF(41, 1)>, /* gmac1_mdc */ + <K1_PADCONF(42, 1)>, /* gmac1_mdio */ + <K1_PADCONF(43, 1)>, /* gmac1_int_n */ + <K1_PADCONF(46, 1)>; /* gmac1_clk_ref */ + + bias-pull-up = <0>; + drive-strength = <21>; + }; + }; + uart0_2_cfg: uart0-2-cfg { uart0-2-pins { pinmux = <K1_PADCONF(68, 2)>, @@ -16,4 +68,12 @@ drive-strength = <32>; }; }; + + pwm14_1_cfg: pwm14-1-cfg { + pwm14-1-pins { + pinmux = <K1_PADCONF(44, 4)>; + bias-pull-up = <0>; + drive-strength = <32>; + }; + }; };