Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > linux.kernel > #1647960
| From | Arnd Bergmann <arnd@arndb.de> |
|---|---|
| Newsgroups | linux.kernel |
| Subject | Re: [PATCH 2/7] RISC-V: arch/riscv Makefile and Kconfigs |
| Date | 2017-05-23 13:50 +0200 |
| Message-ID | <tKgu6-2DN-3@gated-at.bofh.it> (permalink) |
| References | <tK6bn-4ju-3@gated-at.bofh.it> <tK6bo-4ju-27@gated-at.bofh.it> |
| Organization | linux.* mail to news gateway |
On Tue, May 23, 2017 at 2:41 AM, Palmer Dabbelt <palmer@dabbelt.com> wrote:
> ---
> arch/riscv/.gitignore | 35 ++++
> arch/riscv/Kconfig | 300 +++++++++++++++++++++++++++++++++++
> arch/riscv/Makefile | 64 ++++++++
> arch/riscv/configs/riscv32_spike | 47 ++++++
> arch/riscv/configs/riscv64_freedom-u | 52 ++++++
> arch/riscv/configs/riscv64_qemu | 64 ++++++++
> arch/riscv/configs/riscv64_spike | 45 ++++++
> 7 files changed, 607 insertions(+)
> create mode 100644 arch/riscv/.gitignore
> create mode 100644 arch/riscv/Kconfig
> create mode 100644 arch/riscv/Makefile
> create mode 100644 arch/riscv/configs/riscv32_spike
> create mode 100644 arch/riscv/configs/riscv64_freedom-u
> create mode 100644 arch/riscv/configs/riscv64_qemu
> create mode 100644 arch/riscv/configs/riscv64_spike
>
> diff --git a/arch/riscv/.gitignore b/arch/riscv/.gitignore
> new file mode 100644
> index 000000000000..376d06eb5d52
> --- /dev/null
> +++ b/arch/riscv/.gitignore
> @@ -0,0 +1,35 @@
> +# Now un-ignore all files.
> +!*
> +
> +# But then re-ignore the files listed in the Linux .gitignore
> +# Normal rules
> +#
> +.*
> +*.o
> +*.o.*
> +*.a
This doesn't seem to belong here: There is no reason for riscv
to be different from all other architectures. Is something wrong
with the top-level .gitignore? If so, we should just fix it there.
> diff --git a/arch/riscv/Kconfig b/arch/riscv/Kconfig
> new file mode 100644
> index 000000000000..510ead1d3343
> --- /dev/null
> +++ b/arch/riscv/Kconfig
> @@ -0,0 +1,300 @@
> +#
> +# For a description of the syntax of this configuration file,
> +# see Documentation/kbuild/kconfig-language.txt.
> +#
> +
> +config RISCV
> + def_bool y
> + select OF
> + select OF_EARLY_FLATTREE
> + select OF_IRQ
> + select ARCH_HAS_ATOMIC64_DEC_IF_POSITIVE
> + select ARCH_WANT_FRAME_POINTERS
> + select CLONE_BACKWARDS
> + select COMMON_CLK
> + select GENERIC_CLOCKEVENTS
> + select GENERIC_CPU_DEVICES
> + select GENERIC_IRQ_SHOW
> + select GENERIC_PCI_IOMAP
You normally don't want GENERIC_PCI_IOMAP, unless your
inb()/outb() uses other instructions than your readl()/writel()
> +config MMU
> + def_bool y
Just a general question: has there been any interest in a no-MMU
version?
> +# even on 32-bit, physical (and DMA) addresses are > 32-bits
> +config ARCH_PHYS_ADDR_T_64BIT
> + def_bool y
> +
> +config ARCH_DMA_ADDR_T_64BIT
> + def_bool y
Are you required to use 64-bit addressing for RAM on 32-bit
architectures though? Using 32-bit dma_addr_t and phys_addr_t
when possible makes some code noticeably more efficient.
> +config PGTABLE_LEVELS
> + int
> + default 3 if 64BIT
> + default 2
With 2-level page tables, you usually can't address much more
than 32-bit physical memory anyway, so I'd guess that most
32-bit chips would actually put their RAM under the 4GB boundary.
> +config RV_ATOMIC
> + bool "Use atomic memory instructions (RV32A or RV64A)"
> + default y
> +
> +config RV_SYSRISCV_ATOMIC
> + bool "Include support for atomic operation syscalls"
> + default n
> + help
> + If atomic memory instructions are present, i.e.,
> + CONFIG_RV_ATOMIC, this includes support for the syscall that
> + provides atomic accesses. This is only useful to run
> + binaries that require atomic access but were compiled with
> + -mno-atomic.
> +
> + If CONFIG_RV_ATOMIC is unset, this option is mandatory.
Just express this in Kconfig terms to prevent misconfiguration:
config RV_SYSRISCV_ATOMIC
bool "Include support for atomic operation syscalls" if RV_ATOMIC
default !RV_ATOMIC
I wonder what the cost would be of always providing the syscalls
for compatibility. This is also something worth putting into a VDSO
instead of exposing the syscall:
That way, user space that is built with -mno-atomic can call into
the vdso, which depending on the hardware support will perform
the atomic operation directly or enter the syscall.
> +config PCI_DOMAINS
> + def_bool PCI
> +
> +config PCI_DOMAINS_GENERIC
> + def_bool PCI
> +
> +config PCI_SYSCALL
> + def_bool PCI
I don't think you want PCI_SYSCALL
Arnd
Back to linux.kernel | Previous | Next — Previous in thread | Next in thread | Find similar | Unroll thread
RISC-V Linux Port v1 Palmer Dabbelt <palmer@dabbelt.com> - 2017-05-23 02:50 +0200
[PATCH 5/7] RISC-V: arch/riscv/lib Palmer Dabbelt <palmer@dabbelt.com> - 2017-05-23 02:50 +0200
Re: [PATCH 5/7] RISC-V: arch/riscv/lib Geert Uytterhoeven <geert@linux-m68k.org> - 2017-05-23 12:50 +0200
Re: [PATCH 5/7] RISC-V: arch/riscv/lib Palmer Dabbelt <palmer@dabbelt.com> - 2017-05-24 00:10 +0200
Re: [PATCH 5/7] RISC-V: arch/riscv/lib Arnd Bergmann <arnd@arndb.de> - 2017-05-23 13:30 +0200
[PATCH 2/7] RISC-V: arch/riscv Makefile and Kconfigs Palmer Dabbelt <palmer@dabbelt.com> - 2017-05-23 02:50 +0200
Re: [PATCH 2/7] RISC-V: arch/riscv Makefile and Kconfigs Olof Johansson <olof@lixom.net> - 2017-05-23 03:30 +0200
Re: [PATCH 2/7] RISC-V: arch/riscv Makefile and Kconfigs Randy Dunlap <rdunlap@infradead.org> - 2017-05-23 03:40 +0200
Re: [PATCH 2/7] RISC-V: arch/riscv Makefile and Kconfigs Palmer Dabbelt <palmer@dabbelt.com> - 2017-05-23 06:50 +0200
Re: [PATCH 2/7] RISC-V: arch/riscv Makefile and Kconfigs Palmer Dabbelt <palmer@dabbelt.com> - 2017-05-23 06:50 +0200
Re: [patches] Re: [PATCH 2/7] RISC-V: arch/riscv Makefile and Kconfigs Olof Johansson <olof@lixom.net> - 2017-05-23 07:20 +0200
Re: [patches] Re: [PATCH 2/7] RISC-V: arch/riscv Makefile and Kconfigs Benjamin Herrenschmidt <benh@kernel.crashing.org> - 2017-05-23 23:10 +0200
Re: [PATCH 2/7] RISC-V: arch/riscv Makefile and Kconfigs Olof Johansson <olof@lixom.net> - 2017-05-23 07:30 +0200
Re: [PATCH 2/7] RISC-V: arch/riscv Makefile and Kconfigs Palmer Dabbelt <palmer@dabbelt.com> - 2017-05-23 17:30 +0200
Re: [PATCH 2/7] RISC-V: arch/riscv Makefile and Kconfigs Geert Uytterhoeven <geert@linux-m68k.org> - 2017-05-23 13:00 +0200
Re: [PATCH 2/7] RISC-V: arch/riscv Makefile and Kconfigs Arnd Bergmann <arnd@arndb.de> - 2017-05-23 13:50 +0200
[PATCH 3/7] RISC-V: Device Tree Documentation Palmer Dabbelt <palmer@dabbelt.com> - 2017-05-23 02:50 +0200
Re: [PATCH 3/7] RISC-V: Device Tree Documentation Arnd Bergmann <arnd@arndb.de> - 2017-05-23 14:10 +0200
Re: RISC-V Linux Port v1 Olof Johansson <olof@lixom.net> - 2017-05-23 03:20 +0200
Re: RISC-V Linux Port v1 Randy Dunlap <rdunlap@infradead.org> - 2017-05-23 03:30 +0200
Re: RISC-V Linux Port v1 Palmer Dabbelt <palmer@dabbelt.com> - 2017-05-23 05:40 +0200
Re: RISC-V Linux Port v1 Palmer Dabbelt <palmer@dabbelt.com> - 2017-05-23 05:40 +0200
Re: RISC-V Linux Port v1 Tobias Klauser <tklauser@distanz.ch> - 2017-05-23 08:50 +0200
Re: RISC-V Linux Port v1 Palmer Dabbelt <palmer@dabbelt.com> - 2017-05-23 17:50 +0200
Re: RISC-V Linux Port v1 Randy Dunlap <rdunlap@infradead.org> - 2017-05-23 04:20 +0200
Re: RISC-V Linux Port v1 Palmer Dabbelt <palmer@dabbelt.com> - 2017-05-23 06:50 +0200
Re: [PATCH 6/7] RISC-V: arch/riscv/kernel Olof Johansson <olof@lixom.net> - 2017-05-23 04:20 +0200
Re: [PATCH 4/7] RISC-V: arch/riscv/include Arnd Bergmann <arnd@arndb.de> - 2017-05-23 15:00 +0200
Re: [PATCH 4/7] RISC-V: arch/riscv/include Benjamin Herrenschmidt <benh@kernel.crashing.org> - 2017-05-23 23:30 +0200
Re: [PATCH 6/7] RISC-V: arch/riscv/kernel Arnd Bergmann <arnd@arndb.de> - 2017-05-23 15:40 +0200
csiph-web