[v3,1/5] arch: riscv: add support for building DTB files from DT source data
diff mbox series

Message ID 20190602080500.31700-2-paul.walmsley@sifive.com
State New, archived
Headers show
Series
  • arch: riscv: add board and SoC DT file support
Related show

Commit Message

Paul Walmsley June 2, 2019, 8:04 a.m. UTC
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

Comments

Loys Ollivier June 4, 2019, 2:37 p.m. UTC | #1
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 ?
Paul Walmsley June 7, 2019, 5:12 a.m. UTC | #2
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
Loys Ollivier June 7, 2019, 9:49 a.m. UTC | #3
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
Palmer Dabbelt June 8, 2019, 5:56 p.m. UTC | #4
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
Paul Walmsley June 9, 2019, 5:50 a.m. UTC | #5
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
Christoph Hellwig June 9, 2019, 7:49 a.m. UTC | #6
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.

Patch
diff mbox series

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