| Message ID | 20190602080500.31700-2-paul.walmsley@sifive.com (mailing list archive) |
|---|---|
| State | New, archived |
| Headers | show |
| Series | arch: riscv: add board and SoC DT file support | expand |
On Sun 02 Jun 2019 at 01:04, Paul Walmsley <paul.walmsley@sifive.com> wrote: > Similar to ARM64, add support for building DTB files from DT source > data for RISC-V boards. > > This patch starts with the infrastructure needed for SiFive boards. > Boards from other vendors would add support here in a similar form. > > Signed-off-by: Paul Walmsley <paul.walmsley@sifive.com> > Signed-off-by: Paul Walmsley <paul@pwsan.com> > Cc: Palmer Dabbelt <palmer@sifive.com> > Cc: Albert Ou <aou@eecs.berkeley.edu> > --- > arch/riscv/boot/dts/Makefile | 2 ++ > 1 file changed, 2 insertions(+) > create mode 100644 arch/riscv/boot/dts/Makefile > > diff --git a/arch/riscv/boot/dts/Makefile b/arch/riscv/boot/dts/Makefile > new file mode 100644 > index 000000000000..dcc3ada78455 > --- /dev/null > +++ b/arch/riscv/boot/dts/Makefile > @@ -0,0 +1,2 @@ > +# SPDX-License-Identifier: GPL-2.0 > +subdir-y += sifive Always build it ? Any particular reason to drop ARCH_SIFIVE ?
On Tue, 4 Jun 2019, Loys Ollivier wrote: > Always build it ? > Any particular reason to drop ARCH_SIFIVE ? Palmer had some reservations about it, so I dropped it for now. But then as I was thinking about it, I remembered that I also had some reservations about it, years ago: that everyone should use CONFIG_SOC_* for this, rather than CONFIG_ARCH. CONFIG_ARCH_* seems better reserved for CPU architectures. If you agree, would you like to send a followup series, based on the DT patches, to make the SiFive DT file builds depend on CONFIG_SOC_* instead? Thanks for the comment, - Paul
On Thu 06 Jun 2019 at 22:12, Paul Walmsley <paul.walmsley@sifive.com> wrote: > On Tue, 4 Jun 2019, Loys Ollivier wrote: > >> Always build it ? >> Any particular reason to drop ARCH_SIFIVE ? > > Palmer had some reservations about it, so I dropped it for now. But then > as I was thinking about it, I remembered that I also had some reservations > about it, years ago: that everyone should use CONFIG_SOC_* for this, > rather than CONFIG_ARCH. CONFIG_ARCH_* seems better reserved for > CPU architectures. Agree on the CONFIG_SOC. > > If you agree, would you like to send a followup series, based on the DT > patches, to make the SiFive DT file builds depend on CONFIG_SOC_* instead? Sure, I'd be glad to follow up on that. I'll send a followup series to start a discussion. -- Loys
On Thu, 06 Jun 2019 22:12:05 PDT (-0700), Paul Walmsley wrote: > On Tue, 4 Jun 2019, Loys Ollivier wrote: > >> Always build it ? >> Any particular reason to drop ARCH_SIFIVE ? > > Palmer had some reservations about it, so I dropped it for now. But then > as I was thinking about it, I remembered that I also had some reservations > about it, years ago: that everyone should use CONFIG_SOC_* for this, > rather than CONFIG_ARCH. CONFIG_ARCH_* seems better reserved for > CPU architectures. Specifically my worry is that "ARCH_SIFIVE" makes it sound like we're adding SiFive-specific architecture features, and we've been trying really hard to make sure that the various bits of core software avoid boing vendor specific. We've had suggestions of adding vendor-specific instructions to the Linux port with those instructions being conditionally compiled under ARCH_$VENDOR, but I'd rejected that under the "no vendor-specific stuff" argument. As such it doesn't seem fair to go add in an ARCH_SIFIVE for our vendor-specific stuff. The SOC stuff will, of course, be vendor specific. In this idealized world SiFive's SOC support has nothing to do with RISC-V, but of course all of SiFive's SOCs are RISC-V based so the separation is a bit of pedantry. That said, in this case I think getting the name right does make it slightly easier to espouse this "one kernel can run on all RISC-V systems" philosophy. Balancing the SiFive and RISC-V stuff can be a bit tricky, which is why I am sometimes a bit pedantic about these sorts of things. > If you agree, would you like to send a followup series, based on the DT > patches, to make the SiFive DT file builds depend on CONFIG_SOC_* instead? I'd be happy with something like that. We'd also talked about this selecting all the SiFive platform drivers. It should, of course, be possible to select multiple SOC vendors in a single kernel -- we don't have any other real hardware right now, but maybe some sort of "CONFIG_SOC_RISCV_VIRT" would be a good proof of concept? > Thanks for the comment, > > - Paul
On Sat, 8 Jun 2019, Palmer Dabbelt wrote: > On Thu, 06 Jun 2019 22:12:05 PDT (-0700), Paul Walmsley wrote: > > On Tue, 4 Jun 2019, Loys Ollivier wrote: > > > > > Always build it ? > > > Any particular reason to drop ARCH_SIFIVE ? > > > > Palmer had some reservations about it, so I dropped it for now. But then > > as I was thinking about it, I remembered that I also had some reservations > > about it, years ago: that everyone should use CONFIG_SOC_* for this, > > rather than CONFIG_ARCH. CONFIG_ARCH_* seems better reserved for > > CPU architectures. > > The SOC stuff will, of course, be vendor specific. In this idealized world > SiFive's SOC support has nothing to do with RISC-V, but of course all of > SiFive's SOCs are RISC-V based so the separation is a bit of pedantry. That > said, in this case I think getting the name right does make it slightly easier > to espouse this "one kernel can run on all RISC-V systems" philosophy. > Balancing the SiFive and RISC-V stuff can be a bit tricky, which is why I am > sometimes a bit pedantic about these sorts of things. Once there are SoC variants that have different CPU cores, but with the remaining chip integration the same, I think it would make sense to move the CONFIG_SOC_ stuff out from ARM, RISC-V, etc., into something that's not CPU architecture-specific. But for the time being, that seems premature. Might as well have it be driven by an actual use-case. - Paul
On Sat, Jun 08, 2019 at 10:50:14PM -0700, Paul Walmsley wrote: > Once there are SoC variants that have different CPU cores, but with the > remaining chip integration the same, I think it would make sense to move > the CONFIG_SOC_ stuff out from ARM, RISC-V, etc., into something that's > not CPU architecture-specific. But for the time being, that seems > premature. Might as well have it be driven by an actual use-case. We've already had a few SOC families with the same periphals glue and either m68k/powerpc, powerpc/mips or mips/arm/arm64 CPUs, so this isn't exactly new. Not really sure the grouping adds that much value, though.
diff --git a/arch/riscv/boot/dts/Makefile b/arch/riscv/boot/dts/Makefile new file mode 100644 index 000000000000..dcc3ada78455 --- /dev/null +++ b/arch/riscv/boot/dts/Makefile @@ -0,0 +1,2 @@ +# SPDX-License-Identifier: GPL-2.0 +subdir-y += sifive