Skip to content

K
Kernel

openeuler / Kernel
接近 2 年 前同步成功

通知 8
Star 0
Fork 0
K
Kernel
切换分支/标签
  1. 01 12月, 2016 2 次提交
  3. 08 11月, 2016 1 次提交
    • V
      ARC: change return value of userspace cmpxchg assist syscall · e6e335bf
      由 Vineet Gupta 提交于 
      The original syscall only used to return errno to indicate if cmpxchg
succeeded. It was not returning the "previous" value which typical cmpxchg
callers are interested in to build their slowpaths or retry loops.
Given user preemption in syscall return path etc, it is not wise to
check this in userspace afterwards, but should be what kernel actually
observed in the syscall.

So change the syscall interface to always return the previous value and
additionally set Z flag to indicate whether operation succeeded or not
(just like ARM implementation when they used to have this syscall)
The flag approach avoids having to put_user errno which is nice given
the use case for this syscall cares mostly about the "previous" value.
Signed-off-by: NVineet Gupta <vgupta@synopsys.com>
      e6e335bf
  5. 29 10月, 2016 3 次提交
    • V
      ARC: boot log: refactor cpu name/release printing · d975cbc8
      由 Vineet Gupta 提交于 
      The motivation is to identify ARC750 vs. ARC770 (we currently print
generic "ARC700").

A given ARC700 release could be 750 or 770, with same ARCNUM (or family
identifier which is unfortunate). The existing arc_cpu_tbl[] kept a single
concatenated string for core name and release which thus doesn't work
for 750 vs. 770 identification.

So split this into 2 tables, one with core names and other with release.
And while we are at it, get rid of the range checking for family numbers.
We just document the known to exist cores running Linux and ditch
others.

With this in place, we add detection of ARC750 which is
 - cores 0x33 and before
 - cores 0x34 and later with MMUv2
Signed-off-by: NVineet Gupta <vgupta@synopsys.com>
      d975cbc8
    • V
      ARC: boot log: don't assume SWAPE instruction support · a024fd9b
      由 Vineet Gupta 提交于 
      This came to light when helping a customer with oldish ARC750 core who
were getting instruction errors because of lack of SWAPE but boot log
was incorrectly printing it as being present
Signed-off-by: NVineet Gupta <vgupta@synopsys.com>
      a024fd9b
    • V
      ARC: boot log: refactor printing abt features not captured in BCRs · 73e284d2
      由 Vineet Gupta 提交于 
      On older arc700 cores, some of the features configured were not present
in Build config registers. To print about them at boot, we just use the
Kconfig option i.e. whether linux is built to use them or not.
So yes this seems bogus, but what else can be done. Moreover if linux is
booting with these enabled, then the Kconfig info is a good indicator
anyways.

Over time these "hacks" accumulated in read_arc_build_cfg_regs() as well
as arc_cpu_mumbojumbo(). so refactor and move all of those in a single
place: read_arc_build_cfg_regs(). This causes some code redcution too:

| bloat-o-meter2 arch/arc/kernel/setup.o.0 arch/arc/kernel/setup.o.1
| add/remove: 0/0 grow/shrink: 2/1 up/down: 64/-132 (-68)
| function                                     old     new   delta
| setup_processor                              610     670     +60
| cpuinfo_arc700                                76      80      +4
| arc_cpu_mumbojumbo                           752     620    -132
Signed-off-by: NVineet Gupta <vgupta@synopsys.com>
      73e284d2
  7. 01 10月, 2016 1 次提交
  9. 12 3月, 2016 1 次提交
    • V
      ARC: build: Better way to detect ISA compatible toolchain · 20d78037
      由 Vineet Gupta 提交于 
      ARC architecture has 2 instruction sets: ARCompact/ARCv2.
While same gcc supports compiling for either (using appropriate toggles),
we can't use the same toolchain to build kernel because libgcc needs
to be unique and the toolchian (uClibc based) is not multilibed.

uClibc toolchain is convenient since it allows all userspace and
kernel to be built with a single install for an ISA.

This however means 2 gnu installs (with same triplet prefix) are needed
for building for 2 ISA and need to be in PATH.
As developers we keep switching the builds, but would occassionally fail
to update the PATH leading to usage of wrong tools. And this would only
show up at the end of kernel build when linking incompatible libgcc.

So the initial solution was to have gcc define a special preprocessor macro
DEFAULT_CPU_xxx which is unique for default toolchain configuration.
Claudiu proposed using grep for an existing preprocessor macro which is
again uniquely defined per ISA.

Cc: Michal Marek <mmarek@suse.cz>
Suggested-by: NClaudiu Zissulescu <claziss@synopsys.com>
Signed-off-by: NVineet Gupta <vgupta@synopsys.com>
      20d78037
  11. 18 2月, 2016 1 次提交
  13. 29 1月, 2016 1 次提交
  15. 17 10月, 2015 3 次提交
  17. 20 8月, 2015 1 次提交
    • A
      ARCv2: Support IO Coherency and permutations involving L1 and L2 caches · f2b0b25a
      由 Alexey Brodkin 提交于 
      In case of ARCv2 CPU there're could be following configurations
that affect cache handling for data exchanged with peripherals
via DMA:
 [1] Only L1 cache exists
 [2] Both L1 and L2 exist, but no IO coherency unit
 [3] L1, L2 caches and IO coherency unit exist

Current implementation takes care of [1] and [2].
Moreover support of [2] is implemented with run-time check
for SLC existence which is not super optimal.

This patch introduces support of [3] and rework of DMA ops
usage. Instead of doing run-time check every time a particular
DMA op is executed we'll have 3 different implementations of
DMA ops and select appropriate one during init.

As for IOC support for it we need:
 [a] Implement empty DMA ops because IOC takes care of cache
     coherency with DMAed data
 [b] Route dma_alloc_coherent() via dma_alloc_noncoherent()
     This is required to make IOC work in first place and also
     serves as optimization as LD/ST to coherent buffers can be
     srviced from caches w/o going all the way to memory
Signed-off-by: NAlexey Brodkin <abrodkin@synopsys.com>
[vgupta:
  -Added some comments about IOC gains
  -Marked dma ops as static,
  -Massaged changelog a bit]
Signed-off-by: NVineet Gupta <vgupta@synopsys.com>
      f2b0b25a
  19. 03 8月, 2015 1 次提交
  21. 22 6月, 2015 5 次提交
  23. 19 6月, 2015 2 次提交
  25. 13 4月, 2015 3 次提交
  27. 13 10月, 2014 3 次提交
  29. 23 7月, 2014 1 次提交
  31. 26 6月, 2013 1 次提交
    • V
      ARC: pt_regs update #5: Use real ECR for pt_regs->event vs. synth values · 502a0c77
      由 Vineet Gupta 提交于 
      pt_regs->event was set with artificial values to identify the low level
system event (syscall trap / breakpoint trap / exceptions / interrupts)

With r8 saving out of the way, the full word can be used to save real
ECR (Exception Cause Register) which helps idenify the event naturally,
including additional info such as cause code, param.
Only for Interrupts, where ECR is not applicable, do we resort to
synthetic non ECR values.

SAVE_ALL_TRAP/EXCEPTIONS can now be merged as they both use ECR with
different runtime values.

The ptrace helpers now use the sub-fields of ECR to distinguish the
events (e.g. vector 0x25 is trap, param 0 is syscall...)

The following benefits will follow:

(1) This centralizes the location of where ECR is saved and will allow
    the cleanup of task->thread.cause_code ECR placeholder which is set
    in non-uniform way. Then ARC VM code can safely rely on it being
    there for purpose of finer grained VM_EXEC dcache flush (based on
    exec fault: I-TLB Miss)

(2) Further, ECR being passed around from low level handlers as arg can
    be eliminated as it is part of standard reg-file in pt_regs
Signed-off-by: NVineet Gupta <vgupta@synopsys.com>
      502a0c77
  33. 22 6月, 2013 3 次提交
  35. 16 2月, 2013 5 次提交
  37. 11 2月, 2013 2 次提交
    • 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