This patch adds support for context switching the MSA vector registers.
These 128 bit vector registers are aliased with the FP registers - an
FP register accesses the least significant bits of the vector register
with which it is aliased (ie. the register with the same index). Due to
both this & the requirement that the scalar FPU must be 64-bit (FR=1) if
enabled at the same time as MSA the kernel will enable MSA & scalar FP
at the same time for tasks which use MSA. If we restore the MSA vector
context then we might as well enable the scalar FPU since the reason it
was left disabled was to allow for lazy FP context restoring - but we
just restored the FP context as it's a subset of the vector context. If
we restore the FP context and have previously used MSA then we have to
restore the whole vector context anyway (see comment in
enable_restore_fp_context for details) so similarly we might as well
enable MSA.
Thus if a task does not use MSA then it will continue to behave as
without this patch - the scalar FP context will be saved & restored as
usual. But if a task executes an MSA instruction then it will save &
restore the vector context forever more.
Signed-off-by: Paul Burton <paul.burton@imgtec.com>
Cc: linux-mips@linux-mips.org
Patchwork: https://patchwork.linux-mips.org/patch/6431/
Signed-off-by: Ralf Baechle <ralf@linux-mips.org>
This patch adds support for probing the MSAP bit within the Config3
register in order to detect the presence of the MSA ASE. Presence of the
ASE will be indicated in /proc/cpuinfo. The value of the MSA
implementation register will be displayed at boot to aid debugging and
verification of a correct setup, as is done for the FPU.
Signed-off-by: Paul Burton <paul.burton@imgtec.com>
Cc: linux-mips@linux-mips.org
Patchwork: https://patchwork.linux-mips.org/patch/6430/
Signed-off-by: Ralf Baechle <ralf@linux-mips.org>
CONFIG_MIPS_CPS is a better option for systems where it is supported,
which as far as I am aware should be all systems where CONFIG_MIPS_CMP
could provide any value (ie. where there are multiple cores for YAMON to
bring up). This option is therefore deprecated, and marked as such. It
is left intact for the time being in order to provide a fallback should
someone find a system where CONFIG_MIPS_CPS will not function (ie. where
the reset vector cannot be moved), and should be removed entirely in the
future assuming that does not happen.
Signed-off-by: Paul Burton <paul.burton@imgtec.com>
Cc: linux-mips@linux-mips.org
Patchwork: https://patchwork.linux-mips.org/patch/6369/
Signed-off-by: Ralf Baechle <ralf@linux-mips.org>
Commit f55afb0969cc "MIPS: Clean up MIPS MT and CMP configuration
options." introduced a dependency upon MIPS_MT_SMP (ie. SMVP) for the
MIPS_CMP (ie. CMP framework support) Kconfig option. It did not specify
why, and that dependency is bogus. It is perfectly valid to have a
multi-core system with the YAMON bootloader but without MT support -
an example of this would be any multi-core proAptiv bitstream running on
a Malta. Forcing MT support to be enabled in a kernel for such a system
is incorrect. I suspect that the dependency was actually meant to
reflect the fact that YAMON will only bind 1 TC per VPE on an MT system,
and only describe those 1:1 TC:VPE pairs as CPUs through the AMON
interface. Thus an SMTC kernel makes little sense on a system using
MIPS_CMP, and the Kconfig dependencies should reflect that rather than
introducing the bogus SMVP dependency.
Signed-off-by: Paul Burton <paul.burton@imgtec.com>
Cc: linux-mips@linux-mips.org
Patchwork: https://patchwork.linux-mips.org/patch/6368/
Signed-off-by: Ralf Baechle <ralf@linux-mips.org>
The prior help text introduced in commit f55afb0969cc "MIPS: Clean up
MIPS MT and CMP configuration options." reads as though this option
enables the kernel to make use of the CM hardware, which is not true.
What it actually does is allow the kernel to interact with the YAMON
bootloader which actually interacts with the CM hardware to bring up
secondary cores. Re-introduce the word "framework" which that commit
removed to avoid misleading people.
Signed-off-by: Paul Burton <paul.burton@imgtec.com>
Cc: linux-mips@linux-mips.org
Patchwork: https://patchwork.linux-mips.org/patch/6367/
Signed-off-by: Ralf Baechle <ralf@linux-mips.org>
This patch simply attempts to register the MIPS Coherent Processing
System SMP implementation when it is enabled. If registering that fails
for some reason (like the Kconfig option being disabled or a lack of
hardware support) then we fall back to the same SMP implementations as
before.
Signed-off-by: Paul Burton <paul.burton@imgtec.com>
Cc: linux-mips@linux-mips.org
Patchwork: https://patchwork.linux-mips.org/patch/6365/
Signed-off-by: Ralf Baechle <ralf@linux-mips.org>
If CONFIG_TRANSPARENT_HUGEPAGE is enabled, but CONFIG_HUGETLB_PAGE is not,
it is possible to end up with a configuration that fails to build with the
following error:
include/linux/huge_mm.h:125:2: error: #error "hugepages can't be allocated by the buddy allocator"
This is due to CONFIG_FORCE_MAX_ZONEORDER defaulting to 11. It already has
ranges that change the valid values when HUGETLB_PAGE is enabled, but this
is not done for TRANSPARENT_HUGEPAGE. Fix by changing the HUGETLB_PAGE
dependencies to MIPS_HUGE_TLB_SUPPORT, which includes both
TRANSPARENT_HUGEPAGE and HUGETLB_PAGE.
Signed-off-by: Alex Smith <alex.smith@imgtec.com>
Reviewed-by: Markos Chandras <markos.chandras@imgtec.com>
Cc: linux-mips@linux-mips.org
Patchwork: https://patchwork.linux-mips.org/patch/6391/
Signed-off-by: Ralf Baechle <ralf@linux-mips.org>
Commit 597ce1723e "MIPS: Support for 64-bit FP with O32 binaries"
introduced support for setting Status.FR=1 for O32 binaries with the
EF_MIPS_FP64 ELF header flag set. Whilst this flag is currently
supported by binutils it does introduce an ABI break within userland.
Objects built with EF_MIPS_FP64 cannot be safely linked with those built
without it since code in either object may assume behaviour specific to
a value of FR.
More recently there has been discussion around avoiding further
fragmentation of the O32 ABI whilst still allowing the use of FR=1 and
features such as MSA which depend upon it. Details of the plan to allow
this are still being worked on, and whilst the kernel will need the
ability to handle FR=1 with O32 tasks it is unclear what else it may
need to provide to a userland which seeks to avoid another ABI break. In
order to prevent the proliferation of userland which may rely upon the
current EF_MIPS_FP64 behaviour this patch marks the kernel support for
it experimental & disables it by default. Under current proposals it is
likely that this support can simply be enabled again later, but possibly
after the introduction of further interfaces with userland and support
for the MIPS R5 UFR feature.
Signed-off-by: Paul Burton <paul.burton@imgtec.com>
Cc: Matthew Fortune <matthew.fortune@imgtec.com>
Cc: linux-mips@linux-mips.org
Cc: Paul Burton <paul.burton@imgtec.com>
Patchwork: https://patchwork.linux-mips.org/patch/6549/
Signed-off-by: Ralf Baechle <ralf@linux-mips.org>
The kernel currently only probes for a MIPS Coherence Manager in the
Malta interrupt code in order to detect & enable the GIC. However CM is
not Malta-specific, so this should really be more generic. This patch
introduces some non-Malta-specific code which probes for a CM and
performs some basic initialisation.
A new header, with temporarily duplicated register definitions, is
introduced in order to:
1) Allow the new definitions to be correct with regards to the
CM documentation, as many of those in gcmpregs.h aren't.
2) Allow switching away from the REG() macro used via a few layers of
nested macros in order to access registers in gcmpregs.h. This
patch instead introduced accessor functions akin to the
{read,write}_c0_* functions used for cop0 registers.
3) Allow users of the CM to be migrated one by one.
4) Switch from the name 'GCMP' to 'CM' since the Coherence Manager is
what this code is actually dealing with.
Signed-off-by: Paul Burton <paul.burton@imgtec.com>
Cc: linux-mips@linux-mips.org
Patchwork: https://patchwork.linux-mips.org/patch/6360/
Signed-off-by: Ralf Baechle <ralf@linux-mips.org>
The GIC IPI functions aren't necessarily specific to the "CMP
framework" SMP implementation, and will be used elsewhere in a
subsequent commit. This patch adds cleaned up GIC IPI functions to a
separate file which is compiled when a new CONFIG_MIPS_GIC_IPI Kconfig
symbol is selected, and selects that symbol for CONFIG_MIPS_CMP.
Signed-off-by: Paul Burton <paul.burton@imgtec.com>
Cc: linux-mips@linux-mips.org
Patchwork: https://patchwork.linux-mips.org/patch/6359/
Signed-off-by: Ralf Baechle <ralf@linux-mips.org>
USB_ARCH_HAS_EHCI, USB_ARCH_HAS_OHCI, and USB_ARCH_HAS_XHCI were just
removed. Selecting them is a nop. The select statements for these
symbols can be removed too.
Signed-off-by: Paul Bolle <pebolle@tiscali.nl>
Acked-by: Alan Stern <stern@rowland.harvard.edu>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Pull MIPS updates from Ralf Baechle:
"The most notable new addition inside this pull request is the support
for MIPS's latest and greatest core called "inter/proAptiv". The
patch series describes this core as follows.
"The interAptiv is a power-efficient multi-core microprocessor
for use in system-on-chip (SoC) applications. The interAptiv combines
a multi-threading pipeline with a coherence manager to deliver improved
computational throughput and power efficiency. The interAptiv can
contain one to four MIPS32R3 interAptiv cores, system level
coherence manager with L2 cache, optional coherent I/O port,
and optional floating point unit."
The platform specific patches touch all 3 Broadcom families. It adds
support for the new Broadcom/Netlogix XLP9xx Soc, building a common
BCM63XX SMP kernel for all BCM63XX SoCs regardless of core type/count
and full gpio button/led descriptions for BCM47xx.
The rest of the series are cleanups and bug fixes that are MIPS
generic and consist largely of changes that Imgtec/MIPS had published
in their linux-mti-3.10.git stable tree. Random other cleanups and
patches preparing code to be merged in 3.15"
* 'upstream' of git://git.linux-mips.org/pub/scm/ralf/upstream-linus: (139 commits)
mips: select ARCH_MIGHT_HAVE_PC_SERIO
mips: delete non-required instances of include <linux/init.h>
MIPS: KVM: remove shadow_tlb code
MIPS: KVM: use common EHINV aware UNIQUE_ENTRYHI
mips/ide: flush dcache also if icache does not snoop dcache
MIPS: BCM47XX: fix position of cpu_wait disabling
MIPS: BCM63XX: select correct MIPS_L1_CACHE_SHIFT value
MIPS: update MIPS_L1_CACHE_SHIFT based on MIPS_L1_CACHE_SHIFT_<N>
MIPS: introduce MIPS_L1_CACHE_SHIFT_<N>
MIPS: ZBOOT: gather string functions into string.c
arch/mips/pci: don't check resource with devm_ioremap_resource
arch/mips/lantiq/xway: don't check resource with devm_ioremap_resource
bcma: gpio: don't cast u32 to unsigned long
ssb: gpio: add own IRQ domain
MIPS: BCM47XX: fix sparse warnings in board.c
MIPS: BCM47XX: add board detection for Linksys WRT54GS V1
MIPS: BCM47XX: fix detection for some boards
MIPS: BCM47XX: Enable buttons support on SSB
MIPS: BCM47XX: Convert WNDR4500 to new syntax
MIPS: BCM47XX: Use "timer" trigger for status LEDs
...
Pull input subsystem updates from Dmitry Torokhov:
"Just a swath of driver fixes and cleanups, no new drivers this time
(although ALPS now supports one of the newer protocols, more to come)"
* 'for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/dtor/input: (57 commits)
Input: wacom - add support for DTU-1031
Input: wacom - fix wacom->shared guards for dual input devices
Input: edt_ft5x06 - use devm_* functions where appropriate
Input: hyperv-keyboard - pass through 0xE1 prefix
Input: logips2pp - fix spelling s/reciver/receiver/
Input: delete non-required instances of include <linux/init.h>
Input: twl4030-keypad - convert to using managed resources
Input: twl6040-vibra - remove unneeded check for CONFIG_OF
Input: twl4030-keypad - add device tree support
Input: twl6040-vibra - add missing of_node_put
Input: twl4030-vibra - add missing of_node_put
Input: i8042 - cleanup SERIO_I8042 dependencies
Input: i8042 - select ARCH_MIGHT_HAVE_PC_SERIO on x86
Input: i8042 - select ARCH_MIGHT_HAVE_PC_SERIO on unicore32
Input: i8042 - select ARCH_MIGHT_HAVE_PC_SERIO on sparc
Input: i8042 - select ARCH_MIGHT_HAVE_PC_SERIO for SH_CAYMAN
Input: i8042 - select ARCH_MIGHT_HAVE_PC_SERIO on powerpc
Input: i8042 - select ARCH_MIGHT_HAVE_PC_SERIO on mips
Input: i8042 - select ARCH_MIGHT_HAVE_PC_SERIO on IA64
Input: i8042 - select ARCH_MIGHT_HAVE_PC_SERIO on ARM/Footbridge
...
Broadcom BCM63xx DSL SoCs have a L1-cache line size of 16 bytes (shift
value of 4) instead of the currently configured 32 bytes L1-cache line
size.
Reported-by: Daniel Gonzalez <dgcbueu@gmail.com>
Signed-off-by: Florian Fainelli <florian@openwrt.org>
All platforms that require a special MIPS_L1_CACHE_SHIFT value have been
updated, such that we can now make MIPS_L1_CACHE_SHIFT default to the
appropriate integer value based on the select MIPS_L1_CACHE_SHIFT_<N>
variable.
Signed-off-by: Florian Fainelli <florian@openwrt.org>
In order to avoid keeping an ever growing list of chips which need to
select a specific MIPS_L1_CACHE_SHIFT value introduce multiple internal
and non-exposed Kconfig symbols for the various MIPS_L1_CACHE_SHIFT
values out there and update the relevant Kconfig symbols to select them.
Signed-off-by: Florian Fainelli <florian@openwrt.org>
Add MSI chip and MSIX chip definitions.
For MSI, we map the link interrupt to a MSI link IRQ which will
do a second level of dispatch based on the MSI status register.
The MSI chip definitions use the MSI enable register to enable
and disable the MSI irqs.
For MSI-X, we split the 32 available MSI-X vectors across the
four PCIe links (8 each). These PIC interrupts generate an IRQ
per link which uses a second level dispatch as well.
The MSI-X chip definition uses the standard functions to enable
and disable interrupts.
Signed-off-by: Jayachandran C <jchandra@broadcom.com>
Signed-off-by: John Crispin <blogic@openwrt.org>
Patchwork: http://patchwork.linux-mips.org/patch/6270/