1. 27 12月, 2019 1 次提交
  2. 07 8月, 2019 1 次提交
  3. 24 3月, 2019 1 次提交
  4. 10 1月, 2019 1 次提交
    • A
      clocksource/drivers/arc_timer: Utilize generic sched_clock · bf75d938
      Alexey Brodkin 提交于
      commit bf287607c80f24387fedb431a346dc67f25be12c upstream.
      
      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>
      Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      bf75d938
  5. 08 12月, 2018 1 次提交
  6. 15 9月, 2018 1 次提交
  7. 28 8月, 2018 1 次提交
  8. 02 8月, 2018 3 次提交
  9. 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
  10. 20 7月, 2018 1 次提交
  11. 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
  12. 19 5月, 2018 1 次提交
  13. 09 5月, 2018 2 次提交
  14. 06 2月, 2018 1 次提交
  15. 09 1月, 2018 1 次提交
  16. 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
  17. 12 10月, 2017 1 次提交
  18. 04 10月, 2017 1 次提交
  19. 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
  20. 04 8月, 2017 1 次提交
  21. 06 5月, 2017 1 次提交
  22. 27 4月, 2017 1 次提交
  23. 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
  24. 29 3月, 2017 1 次提交
  25. 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
  26. 19 1月, 2017 1 次提交
  27. 19 12月, 2016 1 次提交
  28. 01 12月, 2016 2 次提交
  29. 29 10月, 2016 1 次提交
  30. 17 10月, 2016 2 次提交
    • D
      ARC: [build] Support gz, lzma compressed uImage · 27f3d2a3
      Daniel Mentz 提交于
      Add support for lzma compressed uImage.
      
      Support for gzip was already available but could not be enabled because
      we were missing CONFIG_HAVE_KERNEL_GZIP in arch/arc/Kconfig.
      Signed-off-by: NDaniel Mentz <danielmentz@google.com>
      Cc: linux-snps-arc@lists.infradead.org
      Cc: Vineet Gupta <Vineet.Gupta1@synopsys.com>
      Signed-off-by: NVineet Gupta <vgupta@synopsys.com>
      27f3d2a3
    • V
      ARCv2: intc: untangle SMP, MCIP and IDU · 3ce0fefc
      Vineet Gupta 提交于
      The IDU intc is technically part of MCIP (Multi-core IP) hence
      historically was only available in a SMP hardware build (and thus only
      in a SMP kernel build). Now that hardware restriction has been lifted,
      so a UP kernel needs to support it.
      
      This requires breaking mcip.c into parts which are strictly SMP
      (inter-core interrupts) and IDU which in reality is just another
      intc and thus has no bearing on SMP.
      
      This change allows IDU in UP builds and with a suitable device tree, we
      can have the cascaded intc system
      
          ARCv2 core intc <---> ARCv2 IDU intc <---> periperals
      Signed-off-by: NVineet Gupta <vgupta@synopsys.com>
      3ce0fefc
  31. 01 10月, 2016 2 次提交
  32. 02 6月, 2016 1 次提交