1. 22 12月, 2018 2 次提交
  2. 21 12月, 2018 1 次提交
  3. 14 12月, 2018 1 次提交
  4. 23 11月, 2018 2 次提交
  5. 01 11月, 2018 1 次提交
  6. 31 10月, 2018 2 次提交
  7. 23 10月, 2018 5 次提交
  8. 02 8月, 2018 3 次提交
  9. 05 7月, 2018 1 次提交
  10. 08 6月, 2018 1 次提交
    • L
      mm: introduce ARCH_HAS_PTE_SPECIAL · 3010a5ea
      Laurent Dufour 提交于
      Currently the PTE special supports is turned on in per architecture
      header files.  Most of the time, it is defined in
      arch/*/include/asm/pgtable.h depending or not on some other per
      architecture static definition.
      
      This patch introduce a new configuration variable to manage this
      directly in the Kconfig files.  It would later replace
      __HAVE_ARCH_PTE_SPECIAL.
      
      Here notes for some architecture where the definition of
      __HAVE_ARCH_PTE_SPECIAL is not obvious:
      
      arm
       __HAVE_ARCH_PTE_SPECIAL which is currently defined in
      arch/arm/include/asm/pgtable-3level.h which is included by
      arch/arm/include/asm/pgtable.h when CONFIG_ARM_LPAE is set.
      So select ARCH_HAS_PTE_SPECIAL if ARM_LPAE.
      
      powerpc
      __HAVE_ARCH_PTE_SPECIAL is defined in 2 files:
       - arch/powerpc/include/asm/book3s/64/pgtable.h
       - arch/powerpc/include/asm/pte-common.h
      The first one is included if (PPC_BOOK3S & PPC64) while the second is
      included in all the other cases.
      So select ARCH_HAS_PTE_SPECIAL all the time.
      
      sparc:
      __HAVE_ARCH_PTE_SPECIAL is defined if defined(__sparc__) &&
      defined(__arch64__) which are defined through the compiler in
      sparc/Makefile if !SPARC32 which I assume to be if SPARC64.
      So select ARCH_HAS_PTE_SPECIAL if SPARC64
      
      There is no functional change introduced by this patch.
      
      Link: http://lkml.kernel.org/r/1523433816-14460-2-git-send-email-ldufour@linux.vnet.ibm.comSigned-off-by: NLaurent Dufour <ldufour@linux.vnet.ibm.com>
      Suggested-by: NJerome Glisse <jglisse@redhat.com>
      Reviewed-by: NJerome Glisse <jglisse@redhat.com>
      Acked-by: NDavid Rientjes <rientjes@google.com>
      Cc: Michal Hocko <mhocko@kernel.org>
      Cc: "Aneesh Kumar K . V" <aneesh.kumar@linux.vnet.ibm.com>
      Cc: Michael Ellerman <mpe@ellerman.id.au>
      Cc: Benjamin Herrenschmidt <benh@kernel.crashing.org>
      Cc: Paul Mackerras <paulus@samba.org>
      Cc: Jonathan Corbet <corbet@lwn.net>
      Cc: Catalin Marinas <catalin.marinas@arm.com>
      Cc: Will Deacon <will.deacon@arm.com>
      Cc: Yoshinori Sato <ysato@users.sourceforge.jp>
      Cc: Rich Felker <dalias@libc.org>
      Cc: David S. Miller <davem@davemloft.net>
      Cc: Thomas Gleixner <tglx@linutronix.de>
      Cc: Ingo Molnar <mingo@redhat.com>
      Cc: Vineet Gupta <vgupta@synopsys.com>
      Cc: Palmer Dabbelt <palmer@sifive.com>
      Cc: Albert Ou <albert@sifive.com>
      Cc: Martin Schwidefsky <schwidefsky@de.ibm.com>
      Cc: Heiko Carstens <heiko.carstens@de.ibm.com>
      Cc: David Rientjes <rientjes@google.com>
      Cc: Robin Murphy <robin.murphy@arm.com>
      Cc: Christophe LEROY <christophe.leroy@c-s.fr>
      Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
      3010a5ea
  11. 05 6月, 2018 1 次提交
    • A
      perf: riscv: preliminary RISC-V support · 178e9fc4
      Alan Kao 提交于
      This patch provide a basic PMU, riscv_base_pmu, which supports two
      general hardware event, instructions and cycles.  Furthermore, this
      PMU serves as a reference implementation to ease the portings in
      the future.
      
      riscv_base_pmu should be able to run on any RISC-V machine that
      conforms to the Priv-Spec.  Note that the latest qemu model hasn't
      fully support a proper behavior of Priv-Spec 1.10 yet, but work
      around should be easy with very small fixes.  Please check
      https://github.com/riscv/riscv-qemu/pull/115 for future updates.
      
      Cc: Nick Hu <nickhu@andestech.com>
      Cc: Greentime Hu <greentime@andestech.com>
      Signed-off-by: NAlan Kao <alankao@andestech.com>
      Signed-off-by: NPalmer Dabbelt <palmer@sifive.com>
      178e9fc4
  12. 19 5月, 2018 3 次提交
  13. 09 5月, 2018 2 次提交
  14. 08 5月, 2018 1 次提交
  15. 25 4月, 2018 1 次提交
  16. 23 4月, 2018 1 次提交
  17. 04 4月, 2018 1 次提交
    • P
      RISC-V: Rename CONFIG_CMDLINE_OVERRIDE to CONFIG_CMDLINE_FORCE · f6a11d9f
      Palmer Dabbelt 提交于
      The device tree code looks for CONFIG_CMDLINE_FORCE, but we were using
      CONFIG_CMDLINE_OVERRIDE.  It looks like this was just a hold over from
      before our device tree conversion -- in fact, we'd already removed the
      support for CONFIG_CMDLINE_OVERRIDE from our arch-specific code so it
      didn't even work any more.
      
      Thanks to Mortiz and Trung for finding the original bug, and for Michael
      for suggeting a better fix.
      
      CC: Trung Tran <trung.tran@ettus.com>
      CC: Michael J Clark <mjc@sifive.com>
      Reviewed-by: NMoritz Fischer <mdf@kernel.org>
      Signed-off-by: NPalmer Dabbelt <palmer@sifive.com>
      f6a11d9f
  18. 03 4月, 2018 4 次提交
  19. 15 3月, 2018 1 次提交
  20. 21 2月, 2018 3 次提交
  21. 31 1月, 2018 2 次提交
    • C
      riscv: add ZONE_DMA32 · 5ec9c4ff
      Christoph Hellwig 提交于
      This patch allows devices that require memory that can be addressed
      using 32-bit addresses to work easily on RISC-V systems.  The newly
      improved dma-direct ops will tap into this pool automatically for
      32-bit addressing.
      
      Based on an earlier patch from Wesley W. Terpstra.
      
      CC: Wesley W. Terpstra <terpstra@sifive.com>
      Signed-off-by: NChristoph Hellwig <hch@lst.de>
      Signed-off-by: NPalmer Dabbelt <palmer@sifive.com>
      5ec9c4ff
    • A
      riscv/ftrace: Add basic support · 10626c32
      Alan Kao 提交于
      This patch contains basic ftrace support for RV64I platform.
      Specifically, function tracer (HAVE_FUNCTION_TRACER), function graph
      tracer (HAVE_FUNCTION_GRAPH_TRACER), and a frame pointer test
      (HAVE_FUNCTION_GRAPH_FP_TEST) are implemented following the
      instructions in Documentation/trace/ftrace-design.txt.
      
      Note that the functions in both ftrace.c and setup.c should not be
      hooked with the compiler's -pg option: to prevent infinite self-
      referencing for the former, and to ignore early setup stuff for the
      latter.
      Signed-off-by: NAlan Kao <alankao@andestech.com>
      Signed-off-by: NPalmer Dabbelt <palmer@sifive.com>
      10626c32
  22. 15 1月, 2018 1 次提交