ARC: boot log: eliminate struct cpuinfo_arc #4: boot log per ISA

- boot log now clearly per ISA
- global struct cpuinfo_arc[] elimiated
- local struct struct arcinfo kept for passing info
betw

ARC: boot log: eliminate struct cpuinfo_arc #4: boot log per ISA

- boot log now clearly per ISA
- global struct cpuinfo_arc[] elimiated
- local struct struct arcinfo kept for passing info
between functions

Tested-by: kernel test robot <lkp@intel.com>
Closes: https://lore.kernel.org/oe-kbuild-all/202308162101.Ve5jBg80-lkp@intel.com
Signed-off-by: Vineet Gupta <vgupta@kernel.org>

show more ...

ARC: boot log: eliminate struct cpuinfo_arc #3: don't export

Signed-off-by: Vineet Gupta <vgupta@kernel.org>

ARC: boot log: eliminate struct cpuinfo_arc #2: cache

Signed-off-by: Vineet Gupta <vgupta@kernel.org>

ARC: boot log: eliminate struct cpuinfo_arc #1: mm

This is first step in eliminating struct cpuinfo_arc[NR_CPUS]

Back when we had just ARCompact ISA, the idea was to read/bit-fiddle
the BCRs once a

ARC: boot log: eliminate struct cpuinfo_arc #1: mm

This is first step in eliminating struct cpuinfo_arc[NR_CPUS]

Back when we had just ARCompact ISA, the idea was to read/bit-fiddle
the BCRs once and and cache decoded information in a global struct ready
to use.

With ARCv2 it was modified to contained abstract / ISA agnostic
information.

However with ARCv3 there 's too much disparity to abstract in common
structures. So drop the entire decode once and store paradigm. Afterall
there's only 2 users of this machinery anyways: boot printing and
cat /proc/cpuinfo. None is performance critical to warrant locking away
resident memory per cpu.

This patch is first step in that direction
- decouples struct cpuinfo_arc_mmu from global struct cpuinfo_arc
- mmu code still has a trimmed down static version of
struct cpuinfo_arc_mmu to cache information needed in performance
critical code such as tlb flush routines
- folds read_decode_mmu_bcr() into arc_mmu_mumbojumbo()
- setup_processor() directly calls arc_mmu_init() and not via
arc_cpu_init()

Tested-by: kernel test robot <lkp@intel.com>
Closes: https://lore.kernel.org/oe-kbuild-all/202308151213.qKZPMiyz-lkp@intel.com/
Signed-off-by: Vineet Gupta <vgupta@kernel.org>

show more ...

ARC: allow userspace DSP applications to use AGU extensions

To be able to run DSP-enabled userspace applications with AGU
(address generation unit) extensions we additionally need to
save and restor

ARC: allow userspace DSP applications to use AGU extensions

To be able to run DSP-enabled userspace applications with AGU
(address generation unit) extensions we additionally need to
save and restore following registers at context switch:
* AGU_AP*
* AGU_OS*
* AGU_MOD*

Reviewed-by: Vineet Gupta <vgupta@synopsys.com>
Signed-off-by: Eugeniy Paltsev <Eugeniy.Paltsev@synopsys.com>
Signed-off-by: Vineet Gupta <vgupta@synopsys.com>

show more ...

ARC: add support for DSP-enabled userspace applications

To be able to run DSP-enabled userspace applications we need to
save and restore following DSP-related registers:
At IRQ/exception entry/exit:

ARC: add support for DSP-enabled userspace applications

To be able to run DSP-enabled userspace applications we need to
save and restore following DSP-related registers:
At IRQ/exception entry/exit:
* DSP_CTRL (save it and reset to value suitable for kernel)
* ACC0_LO, ACC0_HI (we already save them as r58, r59 pair)
At context switch:
* ACC0_GLO, ACC0_GHI
* DSP_BFLY0, DSP_FFT_CTRL

Reviewed-by: Vineet Gupta <vgupta@synopsys.com>
Signed-off-by: Eugeniy Paltsev <Eugeniy.Paltsev@synopsys.com>
Signed-off-by: Vineet Gupta <vgupta@synopsys.com>

show more ...

ARC: handle DSP presence in HW

When DSP extensions are present, some of the regular integer instructions
such as DIV, MACD etc are executed in the DSP unit with semantics alterable
by flags in DSP_C

ARC: handle DSP presence in HW

When DSP extensions are present, some of the regular integer instructions
such as DIV, MACD etc are executed in the DSP unit with semantics alterable
by flags in DSP_CTRL aux register. This register is writable by userspace
and thus can potentially affect corresponding instructions in kernel code,
intentionally or otherwise. So safegaurd kernel by effectively disabling
DSP_CTRL upon bootup and every entry to kernel.

Do note that for this config we simply zero out the DSP_CTRL reg assuming
userspace doesn't really care about DSP. The next patch caters to the DSP
aware userspace where this reg is saved/restored upon kernel entry/exit.

Reviewed-by: Vineet Gupta <vgupta@synopsys.com>
Signed-off-by: Eugeniy Paltsev <Eugeniy.Paltsev@synopsys.com>
Signed-off-by: Vineet Gupta <vgupta@synopsys.com>

show more ...

ARCv2: fpu: preserve userspace fpu state

Signed-off-by: Vineet Gupta <vgupta@synopsys.com>

treewide: Replace GPLv2 boilerplate/reference with SPDX - rule 500

Based on 2 normalized pattern(s):

this program is free software you can redistribute it and or modify
it under the terms of th

treewide: Replace GPLv2 boilerplate/reference with SPDX - rule 500

Based on 2 normalized pattern(s):

this program is free software you can redistribute it and or modify
it under the terms of the gnu general public license version 2 as
published by the free software foundation

this program is free software you can redistribute it and or modify
it under the terms of the gnu general public license version 2 as
published by the free software foundation #

extracted by the scancode license scanner the SPDX license identifier

GPL-2.0-only

has been chosen to replace the boilerplate/reference in 4122 file(s).

Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
Reviewed-by: Enrico Weigelt <info@metux.net>
Reviewed-by: Kate Stewart <kstewart@linuxfoundation.org>
Reviewed-by: Allison Randal <allison@lohutok.net>
Cc: linux-spdx@vger.kernel.org
Link: https://lkml.kernel.org/r/20190604081206.933168790@linutronix.de
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

show more ...

ARC: boot log: cut down on verbosity

The syscall ABI has long been fixed, so no need to call that out now.

Also, there's no need to print really fine details such as norm,
barrel-shifter etc. Those

ARC: boot log: cut down on verbosity

The syscall ABI has long been fixed, so no need to call that out now.

Also, there's no need to print really fine details such as norm,
barrel-shifter etc. Those are given in a Linux enabled hardware config.
So now we print just 1 line for all optional "instruction" related
hardware features

|
| ISA Extn : atomic ll64 unalign mpy[opt 9] div_rem

vs. 2 before

|
|ISA Extn : atomic ll64 unalign
| : mpy[opt 9] div_rem norm barrel-shift swap minmax swape

Signed-off-by: Vineet Gupta <vgupta@synopsys.com>

show more ...

ARCv2: boot log: refurbish HS core/release identification

HS core names and releases have so far been identified based solely on
IDENTIFY.ARCVER field. With the future HS releases this will not
be s

ARCv2: boot log: refurbish HS core/release identification

HS core names and releases have so far been identified based solely on
IDENTIFY.ARCVER field. With the future HS releases this will not
be sufficient as same ARCVER 0x54 could be an HS38 or HS48.

So rewrite the code to use a new BCR to identify the cores properly.

Signed-off-by: Vineet Gupta <vgupta@synopsys.com>

show more ...

ARCv2: Add explcit unaligned access support (and ability to disable too)

As of today we enable unaligned access unconditionally on ARCv2.
Do this under a Kconfig option to allow disable it for test,

ARCv2: Add explcit unaligned access support (and ability to disable too)

As of today we enable unaligned access unconditionally on ARCv2.
Do this under a Kconfig option to allow disable it for test, benchmarking
etc. Also while at it

- Select HAVE_EFFICIENT_UNALIGNED_ACCESS
- Although gcc defaults to unaligned access (since GNU 2018.03), add the
right toggles for enabling or disabling as appropriate
- update bootlog to prints both HW feature status (exists, enabled/disabled)
and SW status (used / not used).
- wire up the relaxed memcpy for unaligned access

Signed-off-by: Eugeniy Paltsev <Eugeniy.Paltsev@synopsys.com>
Signed-off-by: Vineet Gupta <vgupta@synopsys.com>
[vgupta: squashed patches, handle gcc -mno-unaligned-access quick]

show more ...

ARCv2: don't assume core 0x54 has dual issue

The first release of core4 (0x54) was dual issue only (HS4x).
Newer releases allow hardware to be configured as single issue (HS3x)
or dual issue.

Preve

ARCv2: don't assume core 0x54 has dual issue

The first release of core4 (0x54) was dual issue only (HS4x).
Newer releases allow hardware to be configured as single issue (HS3x)
or dual issue.

Prevent accessing a HS4x only aux register in HS3x, which otherwise
leads to illegal instruction exceptions

Signed-off-by: Vineet Gupta <vgupta@synopsys.com>

show more ...

ARC: boot log: print Action point details

This now prints the number of action points {2,4,8} and {min,full}
targets supported.

Signed-off-by: Vineet Gupta <vgupta@synopsys.com>

ARCv2: boot log: BPU return stack depth

Signed-off-by: Vineet Gupta <vgupta@synopsys.com>

ARCv2: boot log: updates for HS48: dual-issue, ECC, Loop Buffer

Print the hardware support for ECC, Loop Buffer as well as the runtime
enabled status

Note that unlike the existing boot printing, th

ARCv2: boot log: updates for HS48: dual-issue, ECC, Loop Buffer

Print the hardware support for ECC, Loop Buffer as well as the runtime
enabled status

Note that unlike the existing boot printing, this one is not read from
pre-decoded hardware capabilty info cached in cpuinfo[] struct.
Instead we read the AUX regs on the spot and print it, without botherign
to save anywhere.

There is no point in saving static hardware capabilites in memory when
its use is very sporadic and non-performance critical, mainly for
/proc/cpuinfo. This gets worse in SMP, given it is per-cpu, and pretty
much exactly same across all cpus. So only info needed at runtime
(e.g. TLB geometry) needs to be cached in cpuinfo[]. So going fwd
we will start converting code to this paradigm.

Signed-off-by: Vineet Gupta <vgupta@synopsys.com>

show more ...

ARCv2: boot log: identify HS48 cores (dual issue)

Signed-off-by: Vineet Gupta <vgupta@synopsys.com>

ARC: boot log: decontaminate ARCv2 ISA_CONFIG register

ARCv2 ISA_CONFIG and ARC700_BUILD build config registers are not
compatible. cpuinfo_arc had isa info placeholder which was mashup of bits
form

ARC: boot log: decontaminate ARCv2 ISA_CONFIG register

ARCv2 ISA_CONFIG and ARC700_BUILD build config registers are not
compatible. cpuinfo_arc had isa info placeholder which was mashup of bits
form both.

Untangle this by defining it off of ARCv2 ISA info and it is fine even
for ARC700 since former is a super set of latter (ARC700 buildonly has 2
bits for atomics and stack check).

At runtime, we treat ARCv2 ISA info as a generic placeholder but
populate it correctly depending on ARC700 or HS.

This paves way for adding more HS specific bits in isa info which was
colliding with the extra bits for arc700.

Signed-off-by: Vineet Gupta <vgupta@synopsys.com>

show more ...

ARCv2: intc: Use ARC_REG_STATUS32 for addressing STATUS32 reg

It is better to use it instead of magic numbers.

Signed-off-by: Yuriy Kolerov <yuriy.kolerov@synopsys.com>
Signed-off-by: Vineet Gupta

ARCv2: intc: Use ARC_REG_STATUS32 for addressing STATUS32 reg

It is better to use it instead of magic numbers.

Signed-off-by: Yuriy Kolerov <yuriy.kolerov@synopsys.com>
Signed-off-by: Vineet Gupta <vgupta@synopsys.com>

show more ...

ARC: mm: No need to save cache version in @cpuinfo

Historical MMU revisions have been paired with Cache revision updates
which are captured in MMU and Cache Build Configuration Registers respectivel

ARC: mm: No need to save cache version in @cpuinfo

Historical MMU revisions have been paired with Cache revision updates
which are captured in MMU and Cache Build Configuration Registers respectively.

This was used in boot code to check for configurations mismatches,
speically in simulations (such as running with non existent caches,
non pairing MMU and Cache version etc). This can instead be inferred
from other cache params such as line size. So remove @ver from post
processed @cpuinfo which could be used later to save soem other
interesting info.

Signed-off-by: Vineet Gupta <vgupta@synopsys.com>

show more ...

ARC: breakout timer include code into separate header ...

... which allows for use in drivers/clocksource later

Signed-off-by: Vineet Gupta <vgupta@synopsys.com>

ARC: breakout aux handling into a separate header

ARC timers use aux registers for programming and this paves way for
moving ARC timer drivers into drivers/clocksource

Signed-off-by: Vineet Gupta <

ARC: breakout aux handling into a separate header

ARC timers use aux registers for programming and this paves way for
moving ARC timer drivers into drivers/clocksource

Signed-off-by: Vineet Gupta <vgupta@synopsys.com>

show more ...

ARC: change return value of userspace cmpxchg assist syscall

The original syscall only used to return errno to indicate if cmpxchg
succeeded. It was not returning the "previous" value which typical

ARC: change return value of userspace cmpxchg assist syscall

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: Vineet Gupta <vgupta@synopsys.com>

show more ...

ARC: boot log: refactor cpu name/release printing

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

ARC: boot log: refactor cpu name/release printing

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 <vgupta@synopsys.com>

show more ...

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

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

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

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 <vgupta@synopsys.com>

show more ...