1. 16 2月, 2013 25 次提交
  2. 11 2月, 2013 8 次提交
    • V
      ARC: Timers/counters/delay management · d8005e6b
      Vineet Gupta 提交于
      ARC700 includes 2 in-core 32bit timers TIMER0 and TIMER1.
      Both have exactly same capabilies.
      
      * programmable to count from TIMER<n>_CNT to TIMER<n>_LIMIT
      * for count 0 and LIMIT ~1, provides a free-running counter by
          auto-wrapping when limit is reached.
      * optionally interrupt when LIMIT is reached (oneshot event semantics)
      * rearming the interrupt provides periodic semantics
      * run at CPU clk
      
      ARC Linux uses TIMER0 for clockevent (periodic/oneshot) and TIMER1 for
      clocksource (free-running clock).
      
      Newer cores provide RTSC insn which gives a 64bit cpu clk snapshot hence
      is more apt for clocksource when available.
      
      SMP poses a bit of challenge for global timekeeping clocksource /
      sched_clock() backend:
       -TIMER1 based local clocks are out-of-sync hence can't be used
        (thus we default to jiffies based cs as well as sched_clock() one/both
        of which platform can override with it's specific hardware assist)
       -RTSC is only allowed in SMP if it's cross-core-sync (Kconfig glue
        ensures that) and thus usable for both requirements.
      Signed-off-by: NVineet Gupta <vgupta@synopsys.com>
      Cc: Thomas Gleixner <tglx@linutronix.de>
      d8005e6b
    • V
      ARC: Process-creation/scheduling/idle-loop · bf90e1ea
      Vineet Gupta 提交于
      Signed-off-by: NVineet Gupta <vgupta@synopsys.com>
      Cc: Al Viro <viro@ZenIV.linux.org.uk>
      Cc: Thomas Gleixner <tglx@linutronix.de>
      bf90e1ea
    • V
      ARC: Syscall support (no-legacy-syscall ABI) · 4adeefe1
      Vineet Gupta 提交于
      This includes support for generic clone/for/vfork/execve
      Signed-off-by: NVineet Gupta <vgupta@synopsys.com>
      Cc: Arnd Bergmann <arnd@arndb.de>
      Cc: Al Viro <viro@ZenIV.linux.org.uk>
      Acked-by: NArnd Bergmann <arnd@arndb.de>
      4adeefe1
    • V
      ARC: Non-MMU Exception Handling · 054419ed
      Vineet Gupta 提交于
      Signed-off-by: NVineet Gupta <vgupta@synopsys.com>
      054419ed
    • V
      ARC: Interrupt Handling · bacdf480
      Vineet Gupta 提交于
      This contains:
      -bootup arch IRQ init: init_IRQ(), arc_init_IRQ()
      -generic IRQ subsystem glue: arch_do_IRQ()
      -basic IRQ chip setup for in-core intc
      Signed-off-by: NVineet Gupta <vgupta@synopsys.com>
      Cc: Thomas Gleixner <tglx@linutronix.de>
      bacdf480
    • V
      ARC: Low level IRQ/Trap/Exception Handling · 9d42c84f
      Vineet Gupta 提交于
      Signed-off-by: NVineet Gupta <vgupta@synopsys.com>
      Cc: Al Viro <viro@ZenIV.linux.org.uk>
      9d42c84f
    • V
      ARC: irqflags - Interrupt enabling/disabling at in-core intc · ac4c244d
      Vineet Gupta 提交于
      ARC700 has an in-core intc which provides 2 priorities (a.k.a.) "levels"
      of interrupts (per IRQ) hencforth referred to as L1/L2 interrupts.
      
      CPU flags register STATUS32 has Interrupt Enable bits per level (E1/E2)
      to globally enable (or disable) all IRQs at a level. Hence the
      implementation of arch_local_irq_{save,restore,enable,disable}( )
      
      The STATUS32 reg can be r/w only using the AUX Interface of ARC, hence
      the use of LR/SR instructions. Further, E1/E2 bits in there can only be
      updated using the FLAG insn.
      
      The intc supports 32 interrupts - and per IRQ enabling is controlled by
      a bit in the AUX_IENABLE register, hence the implmentation of
      arch_{,un}mask_irq( ) routines.
      Signed-off-by: NVineet Gupta <vgupta@synopsys.com>
      Cc: Thomas Gleixner <tglx@linutronix.de>
      ac4c244d
    • V
      ARC: Build system: Makefiles, Kconfig, Linker script · cfdbc2e1
      Vineet Gupta 提交于
      Arnd in his review pointed out that arch Kconfig organisation has several
      deficiencies:
      
      * Build time entries for things which can be runtime extracted from DT
        (e.g. SDRAM size, core clk frequency..)
      * Not multi-platform-image-build friendly (choice .. endchoice constructs)
      * cpu variants support (750/770) is exclusive.
      
      The first 2 have been fixed in subsequent patches.
      Due to the nature of the 750 and 770, it is not possible to build for
      both together, w/o special runtime glue code which would hurt
      performance.
      Signed-off-by: NVineet Gupta <vgupta@synopsys.com>
      Cc: Arnd Bergmann <arnd@arndb.de>
      Cc: Sam Ravnborg <sam@ravnborg.org>
      Acked-by: NSam Ravnborg <sam@ravnborg.org>
      cfdbc2e1