The versions of the __write_{32,64}bit_gc0_register() macros for when
there is no virt support in the assembler use the "J" inline asm
constraint to allow integer zero, but this needs to be accompanied by
the "z" formatting string so that it turns into $0. Fix both macros to
do this.
Fixes: bad50d7925 ("MIPS: Fix VZ probe gas errors with binutils <2.24")
Signed-off-by: James Hogan <james.hogan@imgtec.com>
Cc: linux-mips@linux-mips.org
Patchwork: https://patchwork.linux-mips.org/patch/13289/
Signed-off-by: Ralf Baechle <ralf@linux-mips.org>
When starting secondary VPEs which support EVA and the SegCtl registers,
copy the memory segmentation configuration from the running VPE to ensure
that all VPEs in the core have a consistent virtual memory map.
The EVA configuration of secondary cores is dealt with when starting the
core via the CM.
Signed-off-by: Matt Redfearn <matt.redfearn@imgtec.com>
Cc: Paul Burton <paul.burton@imgtec.com>
Cc: linux-mips@linux-mips.org
Cc: linux-kernel@vger.kernel.org
Patchwork: https://patchwork.linux-mips.org/patch/13291/
Signed-off-by: Ralf Baechle <ralf@linux-mips.org>
The SegCtl registers are standard for MIPSr3..MIPSr5. Add definitions of
these registers and use them rather than constants
Signed-off-by: Matt Redfearn <matt.redfearn@imgtec.com>
Cc: Joshua Kinard <kumba@gentoo.org>
Cc: James Hogan <james.hogan@imgtec.com>
Cc: Chris Packham <judge.packham@gmail.com>
Cc: Paul Burton <paul.burton@imgtec.com>
Cc: linux-mips@linux-mips.org
Cc: linux-kernel@vger.kernel.org
Patchwork: https://patchwork.linux-mips.org/patch/13290/
Signed-off-by: Ralf Baechle <ralf@linux-mips.org>
Commit 12822570a2 ("MIPS: Separate XPA CPU feature into LPA and MVH")
wasn't fully applied, possibly due to a conflict with commit
f270d881fa ("MIPS: Detect MIPSr6 Virtual Processor support"). This
left decode_config5() referring to the non-existent MIPS_CPU_XPA, which
breaks the build when XPA is enabled:
arch/mips/kernel/cpu-probe.c In function ‘decode_config5’:
arch/mips/kernel/cpu-probe.c:838:17: error: ‘MIPS_CPU_XPA’ undeclared (first use in this function)
c->options |= MIPS_CPU_XPA;
^
Apply the missing hunk, dropping the CONFIG_XPA ifdef and setting the
MIPS_CPU_MVH option when Config5.MVH is set.
Fixes: 12822570a2 ("MIPS: Separate XPA CPU feature into LPA and MVH")
Signed-off-by: James Hogan <james.hogan@imgtec.com>
Cc: Paul Burton <paul.burton@imgtec.com>
Cc: linux-mips@linux-mips.org
Link: https://patchwork.linux-mips.org/patch/13112/
Patchwork: https://patchwork.linux-mips.org/patch/13277/
Signed-off-by: Ralf Baechle <ralf@linux-mips.org>
When EIC mode is in use (cpu_has_veic is true) enable it on each CPU
during GIC initialisation. Otherwise there may be a mismatch between the
hardware default interrupt model & that expected by the kernel.
Signed-off-by: Paul Burton <paul.burton@imgtec.com>
Reviewed-by: Matt Redfearn <matt.redfearn@imgtec.com>
Tested-by: Matt Redfearn <matt.redfearn@imgtec.com>
Acked-by: Thomas Gleixner <tglx@linutronix.de>
Cc: Paul Burton <paul.burton@imgtec.com>
Cc: Marc Zyngier <marc.zyngier@arm.com>
Cc: Jason Cooper <jason@lakedaemon.net>
Cc: Thomas Gleixner <tglx@linutronix.de>
Cc: linux-kernel@vger.kernel.org
Cc: linux-mips@linux-mips.org
Patchwork: https://patchwork.linux-mips.org/patch/13274/
Signed-off-by: Ralf Baechle <ralf@linux-mips.org>
When using an external interrupt controller (EIC) the interrupt mask
bits in the cop0 Status register are reused for the Interrupt Priority
Level, and any interrupts with a priority lower than the field will be
ignored. Clear the field to 0 by default such that all interrupts are
serviced.
Signed-off-by: Paul Burton <paul.burton@imgtec.com>
Reviewed-by: Matt Redfearn <matt.redfearn@imgtec.com>
Tested-by: Matt Redfearn <matt.redfearn@imgtec.com>
Cc: Qais Yousef <qsyousef@gmail.com>
Cc: Thomas Gleixner <tglx@linutronix.de>
Cc: linux-mips@linux-mips.org
Cc: linux-kernel@vger.kernel.org
Patchwork: https://patchwork.linux-mips.org/patch/13273/
Signed-off-by: Ralf Baechle <ralf@linux-mips.org>
When using an external interrupt controller (EIC) the interrupt mask
bits in the cop0 Status register are reused for the Interrupt Priority
Level, and any interrupts with a priority lower than the field will be
ignored. Clear the field to 0 by default such that all interrupts are
serviced. Without doing so we default to arbitrarily ignoring all or
some subset of interrupts.
Signed-off-by: Paul Burton <paul.burton@imgtec.com>
Reviewed-by: Matt Redfearn <matt.redfearn@imgtec.com>
Tested-by: Matt Redfearn <matt.redfearn@imgtec.com>
Cc: Guenter Roeck <linux@roeck-us.net>
Cc: Sergei Shtylyov <sergei.shtylyov@cogentembedded.com>
Cc: Joe Perches <joe@perches.com>
Cc: James Hogan <james.hogan@imgtec.com>
Cc: linux-mips@linux-mips.org
Cc: linux-kernel@vger.kernel.org
Patchwork: https://patchwork.linux-mips.org/patch/13272/
Signed-off-by: Ralf Baechle <ralf@linux-mips.org>
PIC32 clock driver is now implemented as platform driver instead of
as part of of_clk_init(). It meants all the clock modules are available
quite late in the boot sequence. So request for CPU clock by clk_get_sys()
and clk_get_rate() to find c0_timer rate fails.
To fix this use PIC32 specific early clock functions implemented for early
console support.
Signed-off-by: Purna Chandra Mandal <purna.mandal@microchip.com>
Cc: linux-kernel@vger.kernel.org
Cc: linux-mips@linux-mips.org
Cc: Joshua Henderson <digitalpeer@digitalpeer.com>
Patchwork: https://patchwork.linux-mips.org/patch/13262/
Signed-off-by: Ralf Baechle <ralf@linux-mips.org>
The VZ guest register & TLB access macros introduced in commit "MIPS:
Add guest CP0 accessors" use VZ ASE specific instructions that aren't
understood by versions of binutils prior to 2.24.
Add a check for whether the toolchain supports the -mvirt option,
similar to the MSA toolchain check, and implement the accessors using
.word if not.
Due to difficulty in converting compiler specified registers (e.g. "$3")
to usable numbers (e.g. "3") in inline asm, we need to copy to/from a
temporary register, namely the assembler temporary (at/$1), and specify
guest CP0 registers numerically in the gc0 macros.
Fixes: 7eb9111822 ("MIPS: Add guest CP0 accessors")
Signed-off-by: James Hogan <james.hogan@imgtec.com>
Reported-by: Guenter Roeck <linux@roeck-us.net>
Cc: linux-mips@linux-mips.org
Cc: linux-kernel@vger.kernel.org
Cc: linux-next@vger.kernel.org
Cc: linux-mips@linux-mips.org
Patchwork: https://patchwork.linux-mips.org/patch/13255/
Signed-off-by: Ralf Baechle <ralf@linux-mips.org>
Fix perf hardware performance counter event numbers for I6400. This core
does not follow the performance event numbering scheme of previous MIPS
cores. All performance counters (both odd and even) are capable of
counting any of the available events.
Fixes: 4e88a86213 ("MIPS: Add cases for CPU_I6400")
Signed-off-by: James Hogan <james.hogan@imgtec.com>
Cc: Peter Zijlstra <peterz@infradead.org>
Cc: Ingo Molnar <mingo@redhat.com>
Cc: Arnaldo Carvalho de Melo <acme@kernel.org>
Cc: Alexander Shishkin <alexander.shishkin@linux.intel.com>
Cc: linux-mips@linux-mips.org
Cc: linux-kernel@vger.kernel.org
Patchwork: https://patchwork.linux-mips.org/patch/13259/
Signed-off-by: Ralf Baechle <ralf@linux-mips.org>
Fix a build regression from commit c9017757c5 ("MIPS: init upper 64b
of vector registers when MSA is first used"):
arch/mips/built-in.o: In function `enable_restore_fp_context':
traps.c:(.text+0xbb90): undefined reference to `_init_msa_upper'
traps.c:(.text+0xbb90): relocation truncated to fit: R_MIPS_26 against `_init_msa_upper'
traps.c:(.text+0xbef0): undefined reference to `_init_msa_upper'
traps.c:(.text+0xbef0): relocation truncated to fit: R_MIPS_26 against `_init_msa_upper'
to !CONFIG_CPU_HAS_MSA configurations with older GCC versions, which are
unable to figure out that calls to `_init_msa_upper' are indeed dead.
Of the many ways to tackle this failure choose the approach we have
already taken in `thread_msa_context_live'.
[ralf@linux-mips.org: Drop patch segment to junk file.]
Signed-off-by: Maciej W. Rozycki <macro@imgtec.com>
Cc: stable@vger.kernel.org # v3.16+
Cc: linux-mips@linux-mips.org
Patchwork: https://patchwork.linux-mips.org/patch/13271/
Signed-off-by: Ralf Baechle <ralf@linux-mips.org>
Fix mips_cm_lock_other compilation error when MIPS_CM is not selected.
This was introduced in commit 23d5de8efb (MIPS: CM: Introduce core-other
locking functions)
Signed-off-by: Tony Wu <tung7970@gmail.com>
Cc: Paul Burton <paul.burton@imgtec.com>
Cc: James Hogan <james.hogan@imgtec.com>
Cc: linux-mips@linux-mips.org
Patchwork: https://patchwork.linux-mips.org/patch/11698/
Signed-off-by: Ralf Baechle <ralf@linux-mips.org>
The genvdso program modifies the debug and stripped versions of the
VDSOs in place, and errors if the modification has already taken place.
Unfortunately this means that a rebuild which tries to rerun genvdso to
generate vdso*-image.c without also rebuilding vdso.so.dbg (for example
if genvdso.c is modified) hits a build error like this:
arch/mips/vdso/genvdso 'arch/mips/vdso/vdso.so.dbg' already contains a '.MIPS.abiflags' section
This is fixed by reorganising the rules such that unmodified .so files
have a .raw suffix, and these are copied in the same rule that runs
genvdso on the copies.
I.e. previously we had:
cmd_vdsold:
link objects -> vdso.so.dbg
cmd_genvdso:
strip vdso.so.dbg -> vdso.so
run genvdso -> vdso-image.c
and modify vdso.so.dbg and vdso.so in place
Now we have:
cmd_vdsold:
link objects -> vdso.so.dbg.raw
a new cmd_objcopy based strip rule (inspired by ARM):
strip vdso.so.dbg.raw -> vdso.so.raw
cmd_genvdso:
copy vdso.so.dbg.raw -> vdso.so.dbg
copy vdso.so.raw -> vdso.so
run genvdso -> vdso-image.c
and modify vdso.so.dbg and vdso.so in place
Signed-off-by: James Hogan <james.hogan@imgtec.com>
Cc: linux-mips@linux-mips.org
Patchwork: https://patchwork.linux-mips.org/patch/13250/
Signed-off-by: Ralf Baechle <ralf@linux-mips.org>
The ohci-platform driver can control the clock, while usb-nop-xceiv
as the PHY can control the vbus regulator. So this JZ4740-specific
glue is not needed anymore.
Signed-off-by: Maarten ter Huurne <maarten@treewalker.org>
Acked-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Cc: Lars-Peter Clausen <lars@metafoo.de>
Cc: Paul Cercueil <paul@crapouillou.net>
Cc: linux-mips@linux-mips.org
Cc: linux-kernel@vger.kernel.org
Patchwork: https://patchwork.linux-mips.org/patch/13105/
Signed-off-by: Ralf Baechle <ralf@linux-mips.org>
The DT fragment will select the ohci-platform driver, since that can
handle the JZ4740 OHCI just fine. While I don't have a JZ4740-based
board with anything connected to the USB host controller, I did test
the generic OHCI driver successfully on a JZ4770-based board.
The device is disabled by default; boards that want to use it can
override the "status" property. The mass-production Qi LB60 boards
don't use the USB host controller.
Signed-off-by: Maarten ter Huurne <maarten@treewalker.org>
Cc: Lars-Peter Clausen <lars@metafoo.de>
Cc: Paul Cercueil <paul@crapouillou.net>
Cc: linux-mips@linux-mips.org
Cc: linux-kernel@vger.kernel.org
Patchwork: https://patchwork.linux-mips.org/patch/13104/
Signed-off-by: Ralf Baechle <ralf@linux-mips.org>
AVT2 was a prototype board of which about 5 were made, none of which
are in use anymore.
Signed-off-by: Maarten ter Huurne <maarten@treewalker.org>
Acked-by: Lars-Peter Clausen <lars@metafoo.de>
Cc: Paul Cercueil <paul@crapouillou.net>
Cc: linux-mips@linux-mips.org
Cc: linux-kernel@vger.kernel.org
Patchwork: https://patchwork.linux-mips.org/patch/13103/
Signed-off-by: Ralf Baechle <ralf@linux-mips.org>
Now that there are different revisions of the Pistachio SoC
in circulation, add this information to the boot log to make
it easier for users to determine which hardware they have.
Signed-off-by: James Hartley <james.hartley@imgtec.com>
Signed-off-by: Ionela Voinescu <ionela.voinescu@imgtec.com>
Cc: Andrew Bresticker <abrestic@chromium.org>
Cc: Jonas Gorski <jogo@openwrt.org>
Cc: James Hogan <james.hogan@imgtec.com>
Cc: linux-mips@linux-mips.org
Cc: linux-kernel@vger.kernel.org
Patchwork: https://patchwork.linux-mips.org/patch/13130/
Signed-off-by: Ralf Baechle <ralf@linux-mips.org>
Mediatek MT7620 SoC has syscfg0 bits where it sets the type of memory being used.
However, sometimes those bits are not set properly (reading "11"). In this case, the SoC assumes SDRAM.
The patch below reflects that.
Signed-off-by: Sashka Nochkin <linux-mips@durdom.com>
Cc: linux-mips@linux-mips.org
Patchwork: https://patchwork.linux-mips.org/patch/13135/
Signed-off-by: Ralf Baechle <ralf@linux-mips.org>
If a kernel doesn't support MSA context (ie. CONFIG_CPU_HAS_MSA=n) then
it will only keep 64 bits per FP register in thread context, and the
calls to set_fpr64 in restore_msa_extcontext will overrun the end of the
FP register context into the FCSR & MSACSR values. GCC 6.x has become
smart enough to detect this & complain like so:
arch/mips/kernel/signal.c: In function 'protected_restore_fp_context':
./arch/mips/include/asm/processor.h:114:17: error: array subscript is above array bounds [-Werror=array-bounds]
fpr->val##width[FPR_IDX(width, idx)] = val; \
~~~~~~~~~~~~~~~^~~~~~~~~~~~~~~~~~~~~
./arch/mips/include/asm/processor.h:118:1: note: in expansion of macro 'BUILD_FPR_ACCESS'
BUILD_FPR_ACCESS(64)
The only way to trigger this code to run would be for a program to set
up an artificial extended MSA context structure following a sigframe &
execute sigreturn. Whilst this doesn't allow a program to write to any
state that it couldn't already, it makes little sense to allow this
"restoration" of MSA context in a system that doesn't support MSA.
Fix this by killing a program with SIGSYS if it tries something as crazy
as "restoring" fake MSA context in this way, also fixing the build error
& allowing for most of restore_msa_extcontext to be optimised out of
kernels without support for MSA.
Signed-off-by: Paul Burton <paul.burton@imgtec.com>
Reported-by: Michal Toman <michal.toman@imgtec.com>
Fixes: bf82cb30c7 ("MIPS: Save MSA extended context around signals")
Tested-by: Aaro Koskinen <aaro.koskinen@iki.fi>
Cc: James Hogan <james.hogan@imgtec.com>
Cc: Michal Toman <michal.toman@imgtec.com>
Cc: linux-mips@linux-mips.org
Cc: stable <stable@vger.kernel.org> # v4.3+
Patchwork: https://patchwork.linux-mips.org/patch/13164/
Signed-off-by: Ralf Baechle <ralf@linux-mips.org>
Calculate the MIPS clockevent device's min_delta_ns dynamically based on
the time it takes to perform the mips_next_event() sequence.
Virtualisation in particular makes the current fixed min_delta of 0x300
inappropriate under some circumstances, as the CP0_Count and CP0_Compare
registers may be being emulated by the hypervisor, and the frequency may
not correspond directly to the CPU frequency.
We actually use twice the median of multiple 75th percentiles of
multiple measurements of how long the mips_next_event() sequence takes,
in order to fairly efficiently eliminate outliers due to unexpected
hypervisor latency (which would need handling with retries when it
occurs during normal operation anyway).
Signed-off-by: James Hogan <james.hogan@imgtec.com>
Cc: Daniel Lezcano <daniel.lezcano@linaro.org>
Cc: Thomas Gleixner <tglx@linutronix.de>
Cc: linux-mips@linux-mips.org
Cc: linux-kernel@vger.kernel.org
Patchwork: https://patchwork.linux-mips.org/patch/13176/
Signed-off-by: Ralf Baechle <ralf@linux-mips.org>
When estimating the clock frequency based on the RTC, take seconds into
account in case the Update In Progress (UIP) bit wasn't seen. This can
happen in virtual machines (which may get pre-empted by the hypervisor
at inopportune times) with QEMU emulating the RTC (and in fact not
setting the UIP bit for very long), especially on slow hosts such as
FPGA systems and hardware emulators. This results in several seconds
actually having elapsed before seeing the UIP bit instead of just one
second, and exaggerated timer frequencies.
While updating the comments, they're also fixed to match the code in
that the rising edge of the update flag is detected first, not the
falling edge.
The rising edge gives a more precise point to read the counters in a
virtualised system than the falling edge, resulting in a more accurate
frequency.
It does however mean that we have to also wait for the falling edge
before doing the read of the RTC seconds register, otherwise it seems to
be possible in slow hardware emulation to stray into the interval when
the RTC time is undefined during the update (at least 244uS after the
rising edge of the update flag). This can result in both seconds values
reading the same, and it wrapping to 60 seconds, vastly underestimating
the frequency.
Signed-off-by: James Hogan <james.hogan@imgtec.com>
Cc: James Hogan <james.hogan@imgtec.com>
Cc: linux-mips@linux-mips.org
Patchwork: https://patchwork.linux-mips.org/patch/13174/
Signed-off-by: Ralf Baechle <ralf@linux-mips.org>
Andrea Gelmini