| Message ID | 20240503-swimmer-botany-7368a8a17b1a@spud (mailing list archive) |
|---|---|
| State | Mainlined |
| Headers | show |
| Series | [GIT,PULL] RISC-V Devicetrees for v6.10 | expand |
On Fri, May 3, 2024, at 17:24, Conor Dooley wrote: > Hey Arnd, > > Please pull some dt updates for v6.10. The diff here is a little bigger > than my tag implies, but I've done this on top of -fixes and wanted to > make this obvious. I've also not really mentioned all the Kconfig stuff > much as you'll get that in another branch. Hi Conor, I don't have a good feeling about pulling this one, given that it is both really late and that it pulls in more dependencies than we'd like to have. I was really hoping to be done with new features last week as I pulled in the other branches. There are two other DT pull requests I got after that (amlogic and aspeed), which I added to a "soc/dt-late" branch that I could send in the second week of the merge window if everything goes well, but those don't have the dependencies. If you are able to extract the DT bits that don't depend on other branches (jh7xxx, microchip, bindings and new files) and resend those, I could still add them to the same dt-late branch. Basing a branch on top of a fixes branch is usually fine, especially if those fixes were originally based on an early -rc. I can also make exceptions when there are complex dependencies between branches, but I need to be able to plan for those and not get them just ahead of the merge window. Arnd
On Tue, May 07, 2024 at 11:27:36AM +0200, Arnd Bergmann wrote: > On Fri, May 3, 2024, at 17:24, Conor Dooley wrote: > > Hey Arnd, > > > > Please pull some dt updates for v6.10. The diff here is a little bigger > > than my tag implies, but I've done this on top of -fixes and wanted to > > make this obvious. I've also not really mentioned all the Kconfig stuff > > much as you'll get that in another branch. > > Hi Conor, > > I don't have a good feeling about pulling this one, given that it > is both really late and that it pulls in more dependencies than > we'd like to have. > > I was really hoping to be done with new features last week > as I pulled in the other branches. There are two other DT > pull requests I got after that (amlogic and aspeed), which > I added to a "soc/dt-late" branch that I could send in the > second week of the merge window if everything goes well, but > those don't have the dependencies. > > If you are able to extract the DT bits that don't depend > on other branches (jh7xxx, microchip, bindings and > new files) and resend those, I could still add them to the > same dt-late branch. The jh7xxx stuff does actually depend on another branch, although that branch is fixes. Do you want that removed too? If you do, I'd say to just drop the whole PR. > Basing a branch on top of a fixes branch is usually fine, > especially if those fixes were originally based on an > early -rc. I can also make exceptions when there are > complex dependencies between branches, but I need to be > able to plan for those and not get them just ahead of > the merge window. It hadn't seemed particularly complex to me, so I didn't think to ask you about what to do with the branches etc when I applied the patches. I'll be more paranoid in the future...
On Tue, May 7, 2024, at 11:58, Conor Dooley wrote: > On Tue, May 07, 2024 at 11:27:36AM +0200, Arnd Bergmann wrote: >> On Fri, May 3, 2024, at 17:24, Conor Dooley wrote: >> >> I don't have a good feeling about pulling this one, given that it >> is both really late and that it pulls in more dependencies than >> we'd like to have. >> >> I was really hoping to be done with new features last week >> as I pulled in the other branches. There are two other DT >> pull requests I got after that (amlogic and aspeed), which >> I added to a "soc/dt-late" branch that I could send in the >> second week of the merge window if everything goes well, but >> those don't have the dependencies. >> >> If you are able to extract the DT bits that don't depend >> on other branches (jh7xxx, microchip, bindings and >> new files) and resend those, I could still add them to the >> same dt-late branch. > > The jh7xxx stuff does actually depend on another branch, although that > branch is fixes. Do you want that removed too? If you do, I'd say to > just drop the whole PR. As I wrote below, it's fine to have a branch based on a fixes branch, so please keep that part. Arnd
On Tue, May 07, 2024 at 12:08:13PM +0200, Arnd Bergmann wrote: > On Tue, May 7, 2024, at 11:58, Conor Dooley wrote: > > On Tue, May 07, 2024 at 11:27:36AM +0200, Arnd Bergmann wrote: > >> On Fri, May 3, 2024, at 17:24, Conor Dooley wrote: > >> If you are able to extract the DT bits that don't depend > >> on other branches (jh7xxx, microchip, bindings and > >> new files) and resend those, I could still add them to the > >> same dt-late branch. > > > > The jh7xxx stuff does actually depend on another branch, although that > > branch is fixes. Do you want that removed too? If you do, I'd say to > > just drop the whole PR. > > As I wrote below, it's fine to have a branch based on a > fixes branch, so please keep that part. Cool, just wasn't sure if you were intentionally contradicting yourself or if the "below" part had just been some general remarks. I'll try to get a "revised" PR sent tomorrow. Cheers, Conor.
On Tue, May 7, 2024, at 12:21, Conor Dooley wrote: > On Tue, May 07, 2024 at 12:08:13PM +0200, Arnd Bergmann wrote: >> On Tue, May 7, 2024, at 11:58, Conor Dooley wrote: >> > On Tue, May 07, 2024 at 11:27:36AM +0200, Arnd Bergmann wrote: >> >> On Fri, May 3, 2024, at 17:24, Conor Dooley wrote: > >> >> If you are able to extract the DT bits that don't depend >> >> on other branches (jh7xxx, microchip, bindings and >> >> new files) and resend those, I could still add them to the >> >> same dt-late branch. >> > >> > The jh7xxx stuff does actually depend on another branch, although that >> > branch is fixes. Do you want that removed too? If you do, I'd say to >> > just drop the whole PR. >> >> As I wrote below, it's fine to have a branch based on a >> fixes branch, so please keep that part. > > Cool, just wasn't sure if you were intentionally contradicting yourself > or if the "below" part had just been some general remarks. I'll try to > get a "revised" PR sent tomorrow. Ok. To clarify: basing on a bugfix pull request is always fine since those are already in Linus' tree by the time I send my pull requests to him for the merge window, so the branch contents as seen by 'git request-pull' are clean. For dependencies between the branches that are meant for the merge window, I don't mind taking them when there is a good reason and we have discussed it in advance. It means a little extra work for me as I have to be careful about the order of my own pull requests to ensure that the branch that contains the dependency gets merged first, and the commit log on Linus' side is what's actually meant to be in the branch. I also try hard (in general) to avoid dependencies between the soc/dt branch and any of the other branches, to be sure that there are no incompatible binding changes. This wasn't a problem here (I think), but if you send something late in the cycle, I pretty much don't want to have to think about that. Arnd
On Tue, May 07, 2024 at 02:15:39PM +0200, Arnd Bergmann wrote: > On Tue, May 7, 2024, at 12:21, Conor Dooley wrote: > > Cool, just wasn't sure if you were intentionally contradicting yourself > > or if the "below" part had just been some general remarks. I'll try to > > get a "revised" PR sent tomorrow. > > Ok. To clarify: basing on a bugfix pull request is always fine > since those are already in Linus' tree by the time I send my > pull requests to him for the merge window, so the branch contents > as seen by 'git request-pull' are clean. Ye, I was pretty sure that this is what you meant, but didn't wanna have my second attempt also go awry! > > I also try hard (in general) to avoid dependencies between the > soc/dt branch and any of the other branches, to be sure that > there are no incompatible binding changes. This wasn't a > problem here (I think), but if you send something late in the > cycle, I pretty much don't want to have to think about that. If there's anyone you don't need to worry about making incompatible binding changes like that, it's probably Krzysztof or I. It'd be a bit hypocritical of me to send you stuff like that.. I sent an "take 2" PR there, once the rebased branch had a chance to appear in linux-next. Cheers, Conor.
Hey Arnd, Please pull some dt updates for v6.10. The diff here is a little bigger than my tag implies, but I've done this on top of -fixes and wanted to make this obvious. I've also not really mentioned all the Kconfig stuff much as you'll get that in another branch. Cheers, Conor. The following changes since commit 4cece764965020c22cff7665b18a012006359095: Linux 6.9-rc1 (2024-03-24 14:10:05 -0700) are available in the Git repository at: https://git.kernel.org/pub/scm/linux/kernel/git/conor/linux.git/ tags/riscv-dt-for-v6.10 for you to fetch changes up to 8fd63d81a76024fbd8e3fca29a0748bc9ca46161: riscv: dts: microchip: add pac1934 power-monitor to icicle (2024-05-02 17:24:09 +0100) ---------------------------------------------------------------- RISC-V Devicetrees for v6.10 Canaan: Basic support for the k230 from Canaan and two boards based on it. The k230 is the first SoC we're adding support for that implements the ratified Vector extension, granted mainline doesn't yet support the non-ratified extension for the SoCs that have it. Only the "Big" core is supported right now and in a very basic configuration. The SoC is also the first we have that support the Zicbom and Zicboz cache management/zeroing extensions. Despite having T-Head CPU cores, the non-spec compliant page table bit "erratum" isn't currently used here either, as the SoC supports the standard Svpbmt extension. Using Svpbmt requires non-factory m-mode firmware to clear the relevant bit in CSR.MXSTATUS, but non-factory firmware is required for running mainline on most (all?) SoCs using a T-Head CPU to date due to other issues. Commit 5db2c4dc413e ("riscv: dts: add initial canmv-k230 and k230-evb dts") contains more information on the supported extensions. Support for the k230 required some re-jiggling of Kconfig options that previously operated under the assumption that a Canaan SoC meant a kernel running in m-mode with the MMU disabled. Microchip: A simple addition of a power-monitor on the Icicle dev board, as the binding for it is now in mainline. StarFive: Support for the Milk-V Mars. This board is incredibly similar to the VisionFive v2 that is already supported, with only the really ethernet configuration being slightly different. Emil requested that a common dtsi file, so my fixes branch is pulled into for-next to avoid an annoying conflict between moved content and some erroneously added nodes that were removed as fixes this cycle. Signed-off-by: Conor Dooley <conor.dooley@microchip.com> ---------------------------------------------------------------- Conor Dooley (3): RISC-V: Drop unused SOC_CANAAN RISC-V: add Milkv Mars board devicetree riscv: dts: microchip: add pac1934 power-monitor to icicle Hannah Peuckmann (2): riscv: dts: starfive: visionfive 2: Remove non-existing TDM hardware riscv: dts: starfive: visionfive 2: Remove non-existing I2S hardware Jisheng Zhang (8): riscv: dts: starfive: add 'cpus' label to jh7110 and jh7100 soc dtsi dt-bindings: riscv: starfive: add Milkv Mars board riscv: dts: starfive: visionfive 2: update sound and codec dt node name riscv: dts: starfive: visionfive 2: use cpus label for timebase freq riscv: dts: starfive: visionfive 2: add tf cd-gpios riscv: dts: starfive: visionfive 2: add "disable-wp" for tfcard riscv: dts: starfive: introduce a common board dtsi for jh7110 based boards riscv: dts: starfive: add Milkv Mars board device tree Shengyu Qu (1): riscv: dts: starfive: Remove PMIC interrupt info for Visionfive 2 board Thomas Bonnefille (1): riscv: dts: thead: Fix node ordering in TH1520 device tree Yangyu Chen (10): riscv: Kconfig.socs: Split ARCH_CANAAN and SOC_CANAAN_K210 soc: canaan: Deprecate SOC_CANAAN and use SOC_CANAAN_K210 for K210 clk: k210: Deprecate SOC_CANAAN and use SOC_CANAAN_K210 pinctrl: k210: Deprecate SOC_CANAAN and use SOC_CANAAN_K210 reset: k210: Deprecate SOC_CANAAN and use SOC_CANAAN_K210 dt-bindings: riscv: Add T-HEAD C908 compatible dt-bindings: add Canaan K230 boards compatible strings dt-bindings: timer: Add Canaan K230 CLINT dt-bindings: interrupt-controller: Add Canaan K230 PLIC riscv: dts: add initial canmv-k230 and k230-evb dts .../interrupt-controller/sifive,plic-1.0.0.yaml | 1 + .../devicetree/bindings/riscv/canaan.yaml | 8 +- Documentation/devicetree/bindings/riscv/cpus.yaml | 1 + .../devicetree/bindings/riscv/starfive.yaml | 1 + .../devicetree/bindings/timer/sifive,clint.yaml | 1 + arch/riscv/Kconfig.socs | 8 +- arch/riscv/Makefile | 2 +- arch/riscv/boot/dts/canaan/Makefile | 2 + arch/riscv/boot/dts/canaan/k230-canmv.dts | 24 + arch/riscv/boot/dts/canaan/k230-evb.dts | 24 + arch/riscv/boot/dts/canaan/k230.dtsi | 142 +++++ arch/riscv/boot/dts/microchip/mpfs-icicle-kit.dts | 32 + arch/riscv/boot/dts/starfive/Makefile | 1 + arch/riscv/boot/dts/starfive/jh7100.dtsi | 2 +- arch/riscv/boot/dts/starfive/jh7110-common.dtsi | 599 ++++++++++++++++++ arch/riscv/boot/dts/starfive/jh7110-milkv-mars.dts | 30 + .../dts/starfive/jh7110-starfive-visionfive-2.dtsi | 683 +-------------------- arch/riscv/boot/dts/starfive/jh7110.dtsi | 2 +- arch/riscv/boot/dts/thead/th1520.dtsi | 54 +- arch/riscv/configs/nommu_k210_defconfig | 3 +- arch/riscv/configs/nommu_k210_sdcard_defconfig | 3 +- drivers/clk/Kconfig | 4 +- drivers/pinctrl/Kconfig | 4 +- drivers/reset/Kconfig | 4 +- drivers/soc/Makefile | 2 +- drivers/soc/canaan/Kconfig | 4 +- 26 files changed, 914 insertions(+), 727 deletions(-) create mode 100644 arch/riscv/boot/dts/canaan/k230-canmv.dts create mode 100644 arch/riscv/boot/dts/canaan/k230-evb.dts create mode 100644 arch/riscv/boot/dts/canaan/k230.dtsi create mode 100644 arch/riscv/boot/dts/starfive/jh7110-common.dtsi create mode 100644 arch/riscv/boot/dts/starfive/jh7110-milkv-mars.dts