1. 19 2月, 2019 1 次提交
    • Y
      32-bit userspace ABI: introduce ARCH_32BIT_OFF_T config option · 942fa985
      Yury Norov 提交于
      All new 32-bit architectures should have 64-bit userspace off_t type, but
      existing architectures has 32-bit ones.
      
      To enforce the rule, new config option is added to arch/Kconfig that defaults
      ARCH_32BIT_OFF_T to be disabled for new 32-bit architectures. All existing
      32-bit architectures enable it explicitly.
      
      New option affects force_o_largefile() behaviour. Namely, if userspace
      off_t is 64-bits long, we have no reason to reject user to open big files.
      
      Note that even if architectures has only 64-bit off_t in the kernel
      (arc, c6x, h8300, hexagon, nios2, openrisc, and unicore32),
      a libc may use 32-bit off_t, and therefore want to limit the file size
      to 4GB unless specified differently in the open flags.
      Signed-off-by: NYury Norov <ynorov@caviumnetworks.com>
      Acked-by: NArnd Bergmann <arnd@arndb.de>
      Signed-off-by: NYury Norov <ynorov@marvell.com>
      Signed-off-by: NArnd Bergmann <arnd@arndb.de>
      942fa985
  2. 19 12月, 2018 1 次提交
    • A
      clocksource/drivers/arc_timer: Utilize generic sched_clock · bf287607
      Alexey Brodkin 提交于
      It turned out we used to use default implementation of sched_clock()
      from kernel/sched/clock.c which was as precise as 1/HZ, i.e.
      by default we had 10 msec granularity of time measurement.
      
      Now given ARC built-in timers are clocked with the same frequency as
      CPU cores we may get much higher precision of time tracking.
      
      Thus we switch to generic sched_clock which really reads ARC hardware
      counters.
      
      This is especially helpful for measuring short events.
      That's what we used to have:
      ------------------------------>8------------------------
      $ perf stat /bin/sh -c /root/lmbench-master/bin/arc/hello > /dev/null
      
       Performance counter stats for '/bin/sh -c /root/lmbench-master/bin/arc/hello':
      
               10.000000      task-clock (msec)         #    2.832 CPUs utilized
                       1      context-switches          #    0.100 K/sec
                       1      cpu-migrations            #    0.100 K/sec
                      63      page-faults               #    0.006 M/sec
                 3049480      cycles                    #    0.305 GHz
                 1091259      instructions              #    0.36  insn per cycle
                  256828      branches                  #   25.683 M/sec
                   27026      branch-misses             #   10.52% of all branches
      
             0.003530687 seconds time elapsed
      
             0.000000000 seconds user
             0.010000000 seconds sys
      ------------------------------>8------------------------
      
      And now we'll see:
      ------------------------------>8------------------------
      $ perf stat /bin/sh -c /root/lmbench-master/bin/arc/hello > /dev/null
      
       Performance counter stats for '/bin/sh -c /root/lmbench-master/bin/arc/hello':
      
                3.004322      task-clock (msec)         #    0.865 CPUs utilized
                       1      context-switches          #    0.333 K/sec
                       1      cpu-migrations            #    0.333 K/sec
                      63      page-faults               #    0.021 M/sec
                 2986734      cycles                    #    0.994 GHz
                 1087466      instructions              #    0.36  insn per cycle
                  255209      branches                  #   84.947 M/sec
                   26002      branch-misses             #   10.19% of all branches
      
             0.003474829 seconds time elapsed
      
             0.003519000 seconds user
             0.000000000 seconds sys
      ------------------------------>8------------------------
      
      Note how much more meaningful is the second output - time spent for
      execution pretty much matches number of cycles spent (we're runnign
      @ 1GHz here).
      Signed-off-by: NAlexey Brodkin <abrodkin@synopsys.com>
      Cc: Daniel Lezcano <daniel.lezcano@linaro.org>
      Cc: Vineet Gupta <vgupta@synopsys.com>
      Cc: Thomas Gleixner <tglx@linutronix.de>
      Cc: stable@vger.kernel.org
      Acked-by: NVineet Gupta <vgupta@synopsys.com>
      Signed-off-by: NDaniel Lezcano <daniel.lezcano@linaro.org>
      bf287607
  3. 14 12月, 2018 1 次提交
  4. 06 12月, 2018 1 次提交
  5. 01 12月, 2018 1 次提交
    • K
      ARC: change defconfig defaults to ARCv2 · b7cc40c3
      Kevin Hilman 提交于
      Change the default defconfig (used with 'make defconfig') to the ARCv2
      nsim_hs_defconfig, and also switch the default Kconfig ISA selection to
      ARCv2.
      
      This allows several default defconfigs (e.g. make defconfig, make
      allnoconfig, make tinyconfig) to all work with ARCv2 by default.
      
      Note since we change default architecture from ARCompact to ARCv2
      it's required to explicitly mention architecture type in ARCompact
      defconfigs otherwise ARCv2 will be implied and binaries will be
      generated for ARCv2.
      
      Cc: <stable@vger.kernel.org> # 4.4.x
      Signed-off-by: NKevin Hilman <khilman@baylibre.com>
      Signed-off-by: NAlexey Brodkin <abrodkin@synopsys.com>
      Signed-off-by: NVineet Gupta <vgupta@synopsys.com>
      b7cc40c3
  6. 23 11月, 2018 2 次提交
  7. 13 11月, 2018 1 次提交
    • B
      ARC: remove redundant 'default n' from Kconfig · 2c519f58
      Bartlomiej Zolnierkiewicz 提交于
      'default n' is the default value for any bool or tristate Kconfig
      setting so there is no need to write it explicitly.
      
      Also since commit f467c564 ("kconfig: only write '# CONFIG_FOO
      is not set' for visible symbols") the Kconfig behavior is the same
      regardless of 'default n' being present or not:
      
          ...
          One side effect of (and the main motivation for) this change is making
          the following two definitions behave exactly the same:
      
              config FOO
                      bool
      
              config FOO
                      bool
                      default n
      
          With this change, neither of these will generate a
          '# CONFIG_FOO is not set' line (assuming FOO isn't selected/implied).
          That might make it clearer to people that a bare 'default n' is
          redundant.
          ...
      Signed-off-by: NBartlomiej Zolnierkiewicz <b.zolnierkie@samsung.com>
      Signed-off-by: NVineet Gupta <vgupta@synopsys.com>
      2c519f58
  8. 31 10月, 2018 2 次提交
  9. 20 9月, 2018 2 次提交
    • C
      dma-mapping: consolidate the dma mmap implementations · 58b04406
      Christoph Hellwig 提交于
      The only functional differences (modulo a few missing fixes in the arch
      code) is that architectures without coherent caches need a hook to
      convert a virtual or dma address into a pfn, given that we don't have
      the kernel linear mapping available for the otherwise easy virt_to_page
      call.  As a side effect we can support mmap of the per-device coherent
      area even on architectures not providing the callback, and we make
      previous dangerous default methods dma_common_mmap actually save for
      non-coherent architectures by rejecting it without the right helper.
      
      In addition to that we need a hook so that some architectures can
      override the protection bits when mmaping a dma coherent allocations.
      Signed-off-by: NChristoph Hellwig <hch@lst.de>
      Acked-by: Paul Burton <paul.burton@mips.com> # MIPS parts
      58b04406
    • C
      dma-mapping: merge direct and noncoherent ops · bc3ec75d
      Christoph Hellwig 提交于
      All the cache maintainance is already stubbed out when not enabled,
      but merging the two allows us to nicely handle the case where
      cache maintainance is required for some devices, but not others.
      Signed-off-by: NChristoph Hellwig <hch@lst.de>
      Acked-by: Paul Burton <paul.burton@mips.com> # MIPS parts
      bc3ec75d
  10. 15 9月, 2018 1 次提交
  11. 28 8月, 2018 1 次提交
  12. 02 8月, 2018 3 次提交
  13. 28 7月, 2018 1 次提交
    • E
      ARC: dma [non-IOC] setup SMP_CACHE_BYTES and cache_line_size · eb277739
      Eugeniy Paltsev 提交于
      As for today we don't setup SMP_CACHE_BYTES and cache_line_size for
      ARC, so they are set to L1_CACHE_BYTES by default. L1 line length
      (L1_CACHE_BYTES) might be easily smaller than L2 line (which is
      usually the case BTW). This breaks code.
      
      For example this breaks ethernet infrastructure on HSDK/AXS103 boards
      with IOC disabled, involving manual cache flushes
      Functions which alloc and manage sk_buff packet data area rely on
      SMP_CACHE_BYTES define. In the result we can share last L2 cache
      line in sk_buff linear packet data area between DMA buffer and
      some useful data in other structure. So we can lose this data when
      we invalidate DMA buffer.
      
         sk_buff linear packet data area
                      |
                      |
                      |         skb->end        skb->tail
                      V            |                |
                                   V                V
      ----------------------------------------------.
            packet data            | <tail padding> |  <useful data in other struct>
      ----------------------------------------------.
      
      ---------------------.--------------------------------------------------.
           SLC line        |             SLC (L2 cache) line (128B)           |
      ---------------------.--------------------------------------------------.
              ^                                     ^
              |                                     |
           These cache lines will be invalidated when we invalidate skb
           linear packet data area before DMA transaction starting.
      
      This leads to issues painful to debug as it reproduces only if
      (sk_buff->end - sk_buff->tail) < SLC_LINE_SIZE and
      if we have some useful data right after sk_buff->end.
      
      Fix that by hardcode SMP_CACHE_BYTES to max line length we may have.
      Signed-off-by: NEugeniy Paltsev <Eugeniy.Paltsev@synopsys.com>
      Signed-off-by: NVineet Gupta <vgupta@synopsys.com>
      eb277739
  14. 20 7月, 2018 1 次提交
  15. 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
  16. 19 5月, 2018 1 次提交
  17. 09 5月, 2018 2 次提交
  18. 06 2月, 2018 1 次提交
  19. 09 1月, 2018 1 次提交
  20. 22 11月, 2017 1 次提交
    • V
      ARC: perf: avoid vmalloc backed mmap · 82385732
      Vineet Gupta 提交于
      For non-alising Dcache, vmalloc is not needed.
      
      vmalloc triggers additonal D-TLB Misses in the perf interrupt code path
      making it slightly inefficient as evident from hackbench runs below.
      
      | [ARCLinux]# perf stat -e dTLB-load-misses --repeat 5 hackbench
      | Running with 10*40 (== 400) tasks.
      | Time: 35.060
      | ...
      | Performance counter stats for 'hackbench' (5 runs):
      
      Before:      399235      dTLB-load-misses ( +-  2.08% )
      After :      397676      dTLB-load-misses ( +-  2.27% )
      Acked-by: NPeter Zijlstra (Intel) <peterz@infradead.org>
      Signed-off-by: NVineet Gupta <vgupta@synopsys.com>
      82385732
  21. 12 10月, 2017 1 次提交
  22. 04 10月, 2017 1 次提交
  23. 02 9月, 2017 2 次提交
    • A
      ARC: [plat-hsdk] initial port for HSDK board · a518d637
      Alexey Brodkin 提交于
      This initial port adds support of ARC HS Development Kit board with some
      basic features such serial port, USB, SD/MMC and Ethernet.
      
      Essentially we run Linux kernel on all 4 cores (i.e. utilize SMP) and
      heavily use IO Coherency for speeding-up DMA-aware peripherals.
      
      Note as opposed to other ARC boards we link Linux kernel to
      0x9000_0000 intentionally because cores 1 and 3 configured with DCCM
      situated at our more usual link base 0x8000_0000. We still can use
      memory region starting at 0x8000_0000 as we reallocate DCCM in our
      platform code.
      
      Note that PAE remapping for DMA clients does not work due to an RTL bug,
      so CREG_PAE register must be programmed to all zeroes, otherwise it will
      cause problems with DMA to/from peripherals even if PAE40 is not used.
      Acked-by: NRob Herring <robh@kernel.org>
      Signed-off-by: NAlexey Brodkin <abrodkin@synopsys.com>
      Signed-off-by: NEugeniy Paltsev <Eugeniy.Paltsev@synopsys.com>
      Signed-off-by: NVineet Gupta <vgupta@synopsys.com>
      a518d637
    • E
      ARC: mm: Decouple RAM base address from kernel link address · 9ed68785
      Eugeniy Paltsev 提交于
      	[Needed for HSDK]
      
      Currently the first page of system (hence RAM base) is assumed to be
      @ CONFIG_LINUX_LINK_BASE, where kernel itself is linked.
      
      However is case of HSDK platform, for reasons explained in that patch,
      this is not true. kernel needs to be linked @ 0x9000_0000 while DDR
      is still wired at 0x8000_0000. To properly account for this 256M of RAM,
      we need to introduce a new option and base page frame accountiing off of
      it.
      Signed-off-by: NEugeniy Paltsev <Eugeniy.Paltsev@synopsys.com>
      Signed-off-by: NVineet Gupta <vgupta@synopsys.com>
      [vgupta: renamed  CONFIG_KERNEL_RAM_BASE_ADDRESS => CONFIG_LINUX_RAM_BASE
             : simplified changelog]
      9ed68785
  24. 04 8月, 2017 1 次提交
  25. 06 5月, 2017 1 次提交
  26. 27 4月, 2017 1 次提交
  27. 21 4月, 2017 1 次提交
    • V
      ARCv2: entry: save Accumulator register pair (r58:59) if present · 3d5e8012
      Vineet Gupta 提交于
      Accumulator is present in configs with FPU and/or DSP MPY (mpy > 6)
      
      Instead of doing this in pt_regs (and thus every kernel entry/exit),
      this could have been done in context switch (and for user task only) as
      currently kernel doesn't clobber these registers for its own accord.
      However we will soon start using 64-bit multiply instructions for kernel
      which can clobber these. Also gcc folks also plan to start using these
      as GPRs, hence better to always save/restore them
      Signed-off-by: NVineet Gupta <vgupta@synopsys.com>
      3d5e8012
  28. 29 3月, 2017 1 次提交
  29. 07 2月, 2017 2 次提交
    • V
      ARC: [plat-*] ARC_HAS_COH_CACHES no longer relevant · 8ba605b6
      Vineet Gupta 提交于
      A typical SMP system expects cache coherency. Initial NPS platform
      support was slated to be SMP w/o cache coherency.
      
      However it seems the platform now selects that option, so there is no
      point in keeping it around.
      Signed-off-by: NVineet Gupta <vgupta@synopsys.com>
      8ba605b6
    • Y
      ARCv2: intc: Rework the build time irq count information · f33b8cdd
      Yuriy Kolerov 提交于
      Currently Kconfig knob ARC_NUMBER_OF_INTERRUPTS is used as indicator of
      hard irq count. But it is flawed that it doesn't affect
       - NR_IRQS     : for number of virtual interrupts
       - NR_CPU_IRQS : for number of hardware interrupts
      
      Moreover the actual hardware irq count might still not be same as
      ARC_NUMBER_OF_INTERRUPTS. So use the information availble in the
      Build Configuration Registers and get rid of the Kconfig option.
      
      We still need "some" build time info about irq count to set up
      sufficient number of vector table entries. This is done with a
      sufficiently large NR_CPU_IRQS which will eventually be used soley for
      that purpose (subsequent patches will remove its usage elsewhere)
      
      So to summarize what this patch does:
      
        * NR_CPU_IRQS defines a maximum number of hardware interrupts.
        * Remove ARC_NUMBER_OF_INTERRUPTS option and create interrupts
          table for all possible hardware interrupts.
        * Increase a maximum number of virtual IRQs to 512. ARCv2 can
          support 240 interrupts in the core interrupts controllers
          and 128 interrupts in IDU. Thus 512 virtual IRQs must be
          enough for most configurations of boards.
      
      This patch leads to NR_CPU_IRQS in 2 places, to reduce the overall
      churn. The next patch will remove the 2nd definition anyways.
      Signed-off-by: NYuriy Kolerov <yuriy.kolerov@synopsys.com>
      Signed-off-by: NVineet Gupta <vgupta@synopsys.com>
      [vgupta: reworked the changelog a bit]
      f33b8cdd
  30. 19 1月, 2017 1 次提交
  31. 19 12月, 2016 1 次提交
  32. 01 12月, 2016 1 次提交