| Message ID | 20240730-k1-01-basic-dt-v5-0-98263aae83be@gentoo.org (mailing list archive) |
|---|---|
| Headers | show |
| Series | riscv: add initial support for SpacemiT K1 | expand |
On Mon, 29 Jul 2024 17:28:03 PDT (-0700), dlan@gentoo.org 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]. > > As previous discussion in patch v1[4], maintainer expect more basic drivers > ready before really merging it, which would be fine. For other follow-up patches, > that are clk, pinctrl/gpio, reset.. My current goal would target at a headless > system including SD card, emmc, and ethernet. Acked-by: Palmer Dabbelt <palmer@rivosinc.com> if you guys want to take this through some SOC tree. I'm not really sure what the bar is for SOC support to get merged, but I'd be happy to just see this booting at all -- we've got a bunch of them floating around and the vendor kernels are pretty crusty, so anything's an improvement on my end. > In this series, the uart node has no 'fifo-size', 'tx-threshold' property populated, > will add them once this patch is resolved, see thread [5] > > P.S: talked to Yangyu, I will help and take care of this patch series, thanks > > --- > Changes in v5: > - fix cache-sets in dts > - collect Rob's Ack > - rebase to 6.11-rc1 > - Link to v4: https://lore.kernel.org/r/20240709-k1-01-basic-dt-v4-0-ae5bb5e56aaf@gentoo.org > > Changes in v4: > - add i/d-cache, l2-cache info > - squash uart1 dts node > - update tags > - Link to v3: https://lore.kernel.org/r/20240703-k1-01-basic-dt-v3-0-12f73b47461e@gentoo.org > > Changes in v3: > - fix dt_binding_check error > - fix plic compatible > - fix uart node name > - add uart1 dts node > - collect tags > - Link to v2: https://lore.kernel.org/r/20240627-k1-01-basic-dt-v2-0-cc06c7555f07@gentoo.org > > Changes in v2: > - fix timebase-frequency according to current setting > - add other uart dt nodes, fix input frequency > - introduce new uart compatible for K1 SoC > - add 'k1' prefix to bananapi-f3.dts > - fix k1-clint compatible > - fix some typos > - Link to v1: https://lore.kernel.org/r/tencent_BC64B7B1876F5D10479BD19112F73F262505@qq.com > > Link: https://github.com/BPI-SINOVOIP/armbian-build/tree/v24.04.30 [1] > Link: https://gist.github.com/cyyself/a07096e6e99c949ed13f8fa16d884402 [2] > Link: https://gist.github.com/cyyself/a2201c01f5c8955a119641f97b7d0280 [3] > Link: https://lore.kernel.org/r/20240618-hardwood-footrest-ab5ec5bce3cf@wendy [4] > Link: https://lore.kernel.org/linux-riscv/20240706082928.2238-1-jszhang@kernel.org/ [5] > > Signed-off-by: Yangyu Chen <cyy@cyyself.name> > Signed-off-by: Yixun Lan <dlan@gentoo.org> > > --- > Yangyu Chen (9): > dt-bindings: vendor-prefixes: add spacemit > dt-bindings: riscv: Add SpacemiT X60 compatibles > dt-bindings: riscv: add SpacemiT K1 bindings > dt-bindings: timer: Add SpacemiT K1 CLINT > dt-bindings: interrupt-controller: Add SpacemiT K1 PLIC > riscv: add SpacemiT SoC family Kconfig support > riscv: dts: add initial SpacemiT K1 SoC device tree > riscv: dts: spacemit: add Banana Pi BPI-F3 board device tree > riscv: defconfig: enable SpacemiT SoC > > Yixun Lan (1): > dt-bindings: serial: 8250: Add SpacemiT K1 uart compatible > > .../interrupt-controller/sifive,plic-1.0.0.yaml | 1 + > Documentation/devicetree/bindings/riscv/cpus.yaml | 1 + > .../devicetree/bindings/riscv/spacemit.yaml | 28 ++ > Documentation/devicetree/bindings/serial/8250.yaml | 4 +- > .../devicetree/bindings/timer/sifive,clint.yaml | 1 + > .../devicetree/bindings/vendor-prefixes.yaml | 2 + > arch/riscv/Kconfig.socs | 5 + > arch/riscv/boot/dts/Makefile | 1 + > arch/riscv/boot/dts/spacemit/Makefile | 2 + > arch/riscv/boot/dts/spacemit/k1-bananapi-f3.dts | 19 + > arch/riscv/boot/dts/spacemit/k1.dtsi | 459 +++++++++++++++++++++ > arch/riscv/configs/defconfig | 1 + > 12 files changed, 523 insertions(+), 1 deletion(-) > --- > base-commit: 8400291e289ee6b2bf9779ff1c83a291501f017b > change-id: 20240626-k1-01-basic-dt-1aa31eeebcd2 > > Best regards,
On Tue, Sep 17, 2024 at 06:04:29AM -0700, Palmer Dabbelt wrote: > On Mon, 29 Jul 2024 17:28:03 PDT (-0700), dlan@gentoo.org 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]. > > > > As previous discussion in patch v1[4], maintainer expect more basic drivers > > ready before really merging it, which would be fine. For other follow-up patches, > > that are clk, pinctrl/gpio, reset.. My current goal would target at a headless > > system including SD card, emmc, and ethernet. > > Acked-by: Palmer Dabbelt <palmer@rivosinc.com> > > if you guys want to take this through some SOC tree. I'm not really sure > what the bar is for SOC support to get merged, but I'd be happy to just see > this booting at all -- we've got a bunch of them floating around and the > vendor kernels are pretty crusty, so anything's an improvement on my end. I've asked for clock and ideally pinctrl support before merging it. We had a conversation about the usefulness etc of some of the initial devicetrees merged for some platforms a few months back, that lead to me not merging the k230 support I had queued up. I know this isn't exactly a "fair" barrier to entry, as it is likely that platforms supported by hobbyists are going to be more affected than companies that usually come with that basic level, but have to draw a line somewhere. Both clock and pinctrl are currently in progress for the k1, hopefully wont take too much longer before this is mergeable. In other news, nobody has really made an "official" statement about who is going to maintain this particular platform. People have expressed interest (including the submitter of the series, IIRC) but there's no MAINTAINERS entry added here AFAICT. I used to have an entry that covered arch/riscv/boot/dts/*, with exclusions for sunxi and renesas, but with Drew taking on thead and sophgo being the resぽonsibility of Chen Wang and Inochi, I no longer have that wildcard. I'm happy to apply patches for the platform if noone else is interested in that side of things, provided there are willing reviewers, but I would much rather that someone else took up the responsibility of applying patches and sending PRs - and of course I am happy to help whoever that is with the process. Cheers, Conor.
On Tue, Sep 17, 2024 at 10:08:03PM +0100, Conor Dooley wrote: > In other news, nobody has really made an "official" statement about who > is going to maintain this particular platform. People have expressed > interest (including the submitter of the series, IIRC) but there's no > MAINTAINERS entry added here AFAICT. I used to have an entry that > covered arch/riscv/boot/dts/*, with exclusions for sunxi and renesas, > but with Drew taking on thead and sophgo being the resぽonsibility of > Chen Wang and Inochi, I no longer have that wildcard. > > I'm happy to apply patches for the platform if noone else is interested > in that side of things, provided there are willing reviewers, but I > would much rather that someone else took up the responsibility of > applying patches and sending PRs - and of course I am happy to help > whoever that is with the process. On second thoughts (and on a second opinion) I am not actually willing to apply patches for this platform, since it isn't sustainable to take on each and every platform that there's no maintainer for. +CC a few more people that have been involved in the platform. Yixun Lan, you're kinda the "prime" person to maintain the platform since you're the one who took up the core support work etc. Is maintaining the platform, maybe with the help of one of the other folks working on it something you can do? Mostly the responsibilities are just applying patches for fixes/new content and sending PRs to the soc maintainers - but knowing what's right or not obviously requires familiarity with the platform which people that work on it are best placed to do. Myself and the soc maintainers will help if whoever does this runs into any trouble. There is some documentation here https://docs.kernel.org/process/maintainer-soc.html that will assist somewhat with getting up to speed with the process also. Cheers, Conor.
Hi Conor: On 18:24 Fri 18 Oct , Conor Dooley wrote: > On Tue, Sep 17, 2024 at 10:08:03PM +0100, Conor Dooley wrote: > > In other news, nobody has really made an "official" statement about who > > is going to maintain this particular platform. People have expressed > > interest (including the submitter of the series, IIRC) but there's no > > MAINTAINERS entry added here AFAICT. I used to have an entry that > > covered arch/riscv/boot/dts/*, with exclusions for sunxi and renesas, > > but with Drew taking on thead and sophgo being the resぽonsibility of > > Chen Wang and Inochi, I no longer have that wildcard. > > > > I'm happy to apply patches for the platform if noone else is interested > > in that side of things, provided there are willing reviewers, but I > > would much rather that someone else took up the responsibility of > > applying patches and sending PRs - and of course I am happy to help > > whoever that is with the process. > > On second thoughts (and on a second opinion) I am not actually willing > to apply patches for this platform, since it isn't sustainable to take > on each and every platform that there's no maintainer for. > Ok, I fully understand your concern.. > +CC a few more people that have been involved in the platform. > > Yixun Lan, you're kinda the "prime" person to maintain the platform > since you're the one who took up the core support work etc. Is > maintaining the platform, maybe with the help of one of the other folks > working on it something you can do? > That would be sweet, yes, I can take the maintainer responsibitly for now but, I'm open if someone else willing to help and co-maintain.. > Mostly the responsibilities are just applying patches for fixes/new > content and sending PRs to the soc maintainers - but knowing what's > right or not obviously requires familiarity with the platform which > people that work on it are best placed to do. Myself and the soc > maintainers will help if whoever does this runs into any trouble. > There is some documentation here https://docs.kernel.org/process/maintainer-soc.html > that will assist somewhat with getting up to speed with the process > also. > Great, thanks for the info > Cheers, > Conor. last, one question I'd raise: for this particular patch series, do you want me to send another version v6 which can update the MAINTAINERS file (nothing changed with the code)