linux.git/arch/arc/kernel, branch v4.9-rc3

ARC: module: print pretty section names

2016-10-28T17:10:29+00:00

Now that we have referece to section name string table in
apply_relocate_add(), use it to

 - print the name of section being relocated
 - print symbol with NULL name (since it refers to a section)

before

| Section to fixup 7000a060
| =========================================================
| rela->r_off | rela->addend | sym->st_value | ADDR | VALUE
| =========================================================
|	1c		0		7000e000  7000a07c 7000e000 []
|	40		0		7000a000  7000a0a0 7000a000 []

after

| Section to fixup .eh_frame @7000a060
| =========================================================
| r_off	r_add	st_value ADDRESS  VALUE
| =========================================================
|    1c	0	7000e000 7000a07c 7000e000 [.init.text]
|    40	0	7000a000 7000a0a0 7000a000 [.exit.text]

Signed-off-by: Vineet Gupta

ARC: module: elide loop to save reference to .eh_frame

2016-10-28T17:10:28+00:00

The loop was really needed in .debug_frame regime where wanted make it
as SH_ALLOC so that apply_relocate_add() would process it. That's not
needed for .eh_frame, so we check this in apply_relocate_add() which
gets called for each section.

Note that we need to save reference to "section name strings" section in
module_frob_arch_sections() since apply_relocate_add() doesn't get that

Signed-off-by: Vineet Gupta

ARC: mm: retire ARC_DBG_TLB_MISS_COUNT...

2016-10-28T17:10:28+00:00

... given that we have perf counters abel to do the same thing non
intrusively

Signed-off-by: Vineet Gupta

ARC: boot log: refactor cpu name/release printing

2016-10-28T17:09:07+00:00

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: Vineet Gupta

ARC: boot log: don't assume SWAPE instruction support

2016-10-28T17:09:06+00:00

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: Vineet Gupta

ARC: boot log: refactor printing abt features not captured in BCRs

2016-10-28T17:07:43+00:00

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: Vineet Gupta

ARCv2: boot log: print IOC exists as well as enabled status

2016-10-28T17:06:48+00:00

Previously we would not print the case when IOC existed but was not
enabled.

And while at it, reduce one line off boot printing by consolidating
the Peripheral address space and IO-Coherency which in a way
applies to them

Signed-off-by: Vineet Gupta

ARC: syscall for userspace cmpxchg assist

2016-10-24T16:24:26+00:00

Older ARC700 cores (ARC750 specifically) lack instructions to implement
atomic r-w-w. This is problematic for userspace libraries such as NPTL
which need atomic primitives. So enable them by providing kernel assist.
This is costly but really the only sane soluton (othern than tight
spinning using the otherwise availiable atomic exchange EX instruciton).

Good thing is there are only a few of these cores running Linux out in
the wild.

This only works on UP systems.

Reviewed-by: Colin Ian King 
Signed-off-by: Vineet Gupta

ARC: Adjust cpuinfo for non-continuous cpu ids

2016-10-19T17:01:55+00:00

num_possible_cpus() returns how many CPUs may be present on system.
However we want the highest possible CPU number.
This may be differ in a sparsed possible CPUs map.
Such map achived by OF for plat-eznps.

For example if we have:
possible cpus mask 0,3

Then:
num_possible_cpus() is equal 2
	while
nr_cpu_ids is equal 4.

Only for value 4 c_start() will provide correct cpuinfo at procfs.

Signed-off-by: Noam Camus 
Signed-off-by: Vineet Gupta

ARCv2: intc: untangle SMP, MCIP and IDU

2016-10-16T22:49:07+00:00

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: Vineet Gupta