mbox series

[GIT,PULL] RISC-V Devicetrees for v6.10

Message ID 20240503-swimmer-botany-7368a8a17b1a@spud (mailing list archive)
State Rejected
Headers show
Series [GIT,PULL] RISC-V Devicetrees for v6.10 | expand

Pull-request

https://git.kernel.org/pub/scm/linux/kernel/git/conor/linux.git/ tags/riscv-dt-for-v6.10

Checks

Context Check Description
conchuod/vmtest-fixes-PR fail merge-conflict

Message

Conor Dooley May 3, 2024, 3:24 p.m. UTC
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

Comments

Arnd Bergmann May 7, 2024, 9:27 a.m. UTC | #1
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
Conor Dooley May 7, 2024, 9:58 a.m. UTC | #2
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...
Arnd Bergmann May 7, 2024, 10:08 a.m. UTC | #3
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
Conor Dooley May 7, 2024, 10:21 a.m. UTC | #4
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.
Arnd Bergmann May 7, 2024, 12:15 p.m. UTC | #5
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
Conor Dooley May 8, 2024, 8:19 p.m. UTC | #6
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.