lkml.org 
[lkml]   [2017]   [May]   [23]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    From
    Date
    SubjectRe: [PATCH 2/7] RISC-V: arch/riscv Makefile and Kconfigs
    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

    \
     
     \ /
      Last update: 2017-05-23 13:46    [W:4.490 / U:0.076 seconds]
    ©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site