- 29 Jun, 2017 40 commits
-
-
Aleksandar Markovic authored
Sync the comment with its preprocessor constant counterpart. Signed-off-by:
Aleksandar Markovic <aleksandar.markovic@imgtec.com> Cc: James Hogan <james.hogan@imgtec.com> Cc: Miodrag Dinic <miodrag.dinic@imgtec.com> Cc: Paul Burton <paul.burton@imgtec.com> Cc: Petar Jovanovic <petar.jovanovic@imgtec.com> Cc: Raghu Gandham <raghu.gandham@imgtec.com> Cc: linux-mips@linux-mips.org Cc: linux-kernel@vger.kernel.org Patchwork: https://patchwork.linux-mips.org/patch/16641/Signed-off-by:
Ralf Baechle <ralf@linux-mips.org>
-
Goran Ferenc authored
This patch adds gettimeofday_fallback() function that wraps assembly invocation of gettimeofday() syscall using __NR_gettimeofday. This function is used if pure VDSO implementation gettimeofday() does not succeed for any reason. Its imeplementation is enclosed in "#ifdef CONFIG_MIPS_CLOCK_VSYSCALL" to be in sync with the similar arrangement for __vdso_gettimeofday(). If syscall invocation via __NR_gettimeofday fails, register a3 will be set. So, after the syscall, register a3 is tested and the return valuem is negated if it's set. Signed-off-by:
Goran Ferenc <goran.ferenc@imgtec.com> Signed-off-by:
Miodrag Dinic <miodrag.dinic@imgtec.com> Signed-off-by:
-
Goran Ferenc authored
This patch adds clock_gettime_fallback() function that wraps assembly invocation of clock_gettime() syscall using __NR_clock_gettime. This function is used if pure VDSO implementation of clock_gettime() does not succeed for any reason. For example, it is called if the clkid parameter of clock_gettime() is not one of the clkids listed in the switch-case block of the function __vdso_clock_gettime() (one such case for clkid is CLOCK_BOOTIME). If syscall invocation via __NR_clock_gettime fails, register a3 will be set. So, after the syscall, register a3 is tested and the return value is negated if it's set. Signed-off-by:
-
Goran Ferenc authored
Fix incorrect calculation in do_monotonic() and do_monotonic_coarse() function that in turn caused incorrect values returned by the vdso version of system call clock_gettime() on mips64 if its system clock ID parameter was CLOCK_MONOTONIC or CLOCK_MONOTONIC_COARSE. Consider these variables and their types on mips32 and mips64: tk->wall_to_monotonic.tv_sec s64, s64 (kernel/vdso.c) vdso_data.wall_to_mono_sec u32, u32 (kernel/vdso.c) to_mono_sec u32, u32 (vdso/gettimeofday.c) ts->tv_sec s32, s64 (vdso/gettimeofday.c) For mips64 case, u32 vdso_data.wall_to_mono_sec variable is updated from the 64-bit signed variable tk->wall_to_monotonic.tv_sec (kernel/vdso.c:76) which is a negative number holding the time passed from 1970-01-01 to the time boot started. This 64-bit signed value is currently around 47+ years, in seconds. For instance, let this value be: -1489757461 or 11111111111111111111111111111111 10100111001101000001101011101011 By updating 32-bit vdso_data.wall_to_mono_sec variable, we lose upper 32 bits (signed 1's). to_mono_sec variable is a parameter of do_monotonic() and do_monotonic_coarse() functions which holds vdso_data.wall_to_mono_sec value. Its value needs to be added (or subtracted considering it holds negative value from the tk->wall_to_monotonic.tv_sec) to the current time passed from 1970-01-01 (ts->tv_sec), which is again something like 47+ years, but increased by the time passed from the boot to the current time. ts->tv_sec is 32-bit long in case of 32-bit architecture and 64-bit long in case of 64-bit architecture. Consider the update of ts->tv_sec (vdso/gettimeofday.c:55 & 167): ts->tv_sec += to_mono_sec; mips32 case: This update will be performed correctly, since both ts->tv_sec and to_mono_sec are 32-bit long and the sign in to_mono_sec is preserved. Implicit conversion from u32 to s32 will be done correctly. mips64 case: This update will be wrong, since the implicit conversion will not be done correctly. The reason is that the conversion will be from u32 to s64. This is because to_mono_sec is 32-bit long for both mips32 and mips64 cases and s64..33 bits of converted to_mono_sec variable will be zeros. So, in order to make MIPS64 implementation work properly for MONOTONIC and MONOTONIC_COARSE clock ids on mips64, the size of wall_to_mono_sec variable in mips_vdso_data union and respective parameters in do_monotonic() and do_monotonic_coarse() functions should be changed from u32 to u64. Because of consistency, this size change from u32 and u64 is also done for wall_to_mono_nsec variable and corresponding function parameters. As far as similar situations for other architectures are concerned, let's take a look at arm. Arm has two distinct vdso_data structures for 32-bit & 64-bit cases, and arm's wall_to_mono_sec and wall_to_mono_nsec are u32 for 32-bit and u64 for 64-bit cases. On the other hand, MIPS has only one structure (mips_vdso_data), hence the need for changing the size of above mentioned parameters. Signed-off-by:
-
Paul Burton authored
Use current_cpu_type() to check for 4Kc processors instead of checking the PRID directly. This will allow for the 4Kc case to be optimised out of kernels that can't run on 4KC processors, thanks to __get_cpu_type() and its unreachable() call. Signed-off-by:
Paul Burton <paul.burton@imgtec.com> Cc: linux-mips@linux-mips.org Patchwork: https://patchwork.linux-mips.org/patch/16205/Signed-off-by:
-
Paul Burton authored
CONFIG_MIPS_PGD_C0_CONTEXT, which allows a pointer to the page directory to be stored in the cop0 Context register when enabled, was previously only allowed for MIPSr2. MIPSr6 is just as able to make use of it, so allow it there too. Signed-off-by:
-
Paul Burton authored
In systems where there are multiple actors updating the TLB, the potential exists for a race condition wherein a CPU hits a TLB exception but by the time it reaches a TLBP instruction the affected TLB entry may have been replaced. This can happen if, for example, a CPU shares the TLB between hardware threads (VPs) within a core and one of them replaces the entry that another has just taken a TLB exception for. We handle this race in the case of the Hardware Table Walker (HTW) being the other actor already, but didn't take into account the potential for multiple threads racing. Include the code for aborting TLB exception handling in affected multi-threaded systems, those being the I6400 & I6500 CPUs which share TLB entries between VPs. In the case of using RiXi without dedicated exceptions we have never handled this race even for HTW. This patch adds WARN()s to these cases which ought never to be hit because all CPUs with either HTW or shared FTLB RAMs also include dedicated RiXi exceptions, but the WARN()s will ensure this is always the case. Signed-off-by:
-
Paul Burton authored
Some systems share FTLB RAMs or entries between sibling CPUs (ie. hardware threads, or VP(E)s, within a core). These properties require kernel handling in various places. As a start this patch introduces cpu_has_shared_ftlb_ram & cpu_has_shared_ftlb_entries feature macros which we set appropriately for I6400 & I6500 CPUs. Further patches will make use of these macros as appropriate. Signed-off-by:
-
Paul Burton authored
On pre-r6 systems with the MT ASE the CPS SMP code included checks to halt the VPE running mips_cps_boot_vpes() if its bit in the struct core_boot_config vpe_mask field is clear. This was largely done in order to allow us to start arbitrary VPEs within a core despite the fact that hardware is typically configured to run only VPE0 after powering up a core. VPE0 would start the desired other VPEs, halt itself, and the fact that VPE0 started would be largely hidden & irrelevant. In MIPSr6 multithreading we have control over which VPs start executing when a core powers up via the cores CPC registers accessed remotely through the redirect block. For this reason the MIPSr6 multithreading path in mips_cps_boot_vpes() hasn't bothered up until now to handle halting the VP running it. However it is possible to power up cores entirely in hardware by using a pwr_up pin associated with the core. Unfortunately some systems wire this pin to a logic 1, which means that it is possible for a core to power up at a point that software doesn't expect. The result is that we generally go execute the kernel on a CPU that ought not to be running & the results can be unpredictable. Handle this case by stopping VPs that we don't expect to be running in mips_cps_boot_vpes() - with this change even if a core powers up it will do nothing useful & all VPs within it will stop running before they proceed to run general kernel code & do any damage. Ideally we would produce some sort of warning here, but given the stage of core bringup this happens at that would be non-trivial. We also will only hit this if a core starts up after being offlined via hotplug, and when that happens we will already produce a warning that the CPU didn't power down in cps_cpu_die() which seems sufficient. Signed-off-by:
-
Paul Burton authored
If we get into a state where a core that ought to power down isn't doing so then the current result is that another CPU gets stuck inside cps_cpu_die() waiting for CPU that ought to be powering down to do so. The best case scenario is that we then trigger RCU stall messages or lockup messages, but neither makes it particularly clear what's happening. Handle this more gracefully by introducing a timeout beyond which we warn the user that the core didn't power down & stop waiting for it. This at least allows the CPU running cps_cpu_die() to continue normally, and hopefully presuming the CPU that powered back up is doing nothing harmful the system will continue functioning as normal. Signed-off-by:
-
Paul Burton authored
Systems using the MIPS Coherence Manager (CM) cannot support multi-core SMP with dcache aliasing. This is because CPU caches are VIPT, but interventions in CM-based systems provide only the physical address to remote caches. This means that interventions may behave incorrectly in the presence of an aliasing dcache, since the physical address used when handling an intervention may lead to operation on an aliased cache line rather than the correct line. Prevent us from running into this issue by refusing to boot secondary cores in systems where dcache aliasing may occur. Signed-off-by:
-
Paul Burton authored
Prior to MIPSr6 multithreading is only supported if CONFIG_MIPS_MT_SMP is enabled, so CONFIG_MIPS_MT_SMP selects CONFIG_SYS_SUPPORTS_SCHED_SMT. With MIPSr6 the CONFIG_MIPS_CPS SMP implementation always supports multithreading, so have it select CONFIG_SYS_SUPPORTS_SCHED_SMT in order to allow the scheduler to make better informed decisions on multithreaded MIPSr6 systems (for example those using I6400 or I6500 CPUs). Signed-off-by:
-
Paul Burton authored
Rather than using BUG_ON in the case of an invalid attempt to lock access to a non-zero VP on a pre-CM3 system, use WARN_ON so that we have even the slightest chance of recovery. Signed-off-by:
-
Paul Burton authored
CM3 provides a GCR_CL_OTHER register per VP, rather than only per core. This means that we don't need to prevent other VPs within a core from racing with code that makes use of the core-other register region. Reduce locking overhead by demoting the per-core spinlock providing protection for CM2.5 & lower to a per-CPU/per-VP spinlock for CM3 & higher. Signed-off-by:
-
Paul Burton authored
If we're running on a system with only 1 possible CPU then it makes no sense to reserve or initialise IPIs since we'll never use them. Avoid doing so. Signed-off-by:
-
Maciej W. Rozycki authored
Reduce the log level for branch emulation error messages issued before sending SIGILL by `__compute_return_epc_for_insn' as these are triggered by user software and are not an event that would normally require any attention. The same signal sent from elsewhere does not actually leave any trace in the kernel log at all. Signed-off-by:
Maciej W. Rozycki <macro@imgtec.com> Cc: James Hogan <james.hogan@imgtec.com> Cc: linux-mips@linux-mips.org Patchwork: https://patchwork.linux-mips.org/patch/16402/Signed-off-by:
-
Maciej W. Rozycki authored
Update commit 1ac94400 ("MIPS: math-emu: Add mfhc1 & mthc1 support.") and like done throughout `cop1Emulate' for other cases also for the MFHC1 and MTHC1 instructions return SIGILL right away rather than jumping to a single `return' statement. Signed-off-by:
-
Maciej W. Rozycki authored
This is a user-visible message, so we want it to be spelled correctly. Fixes: 5f9f41c4 ("MIPS: kernel: Prepare the JR instruction for emulation on MIPS R6") Signed-off-by:
-
Maciej W. Rozycki authored
Fix: * commit 8467ca01 ("MIPS: Emulate the new MIPS R6 branch compact (BC) instruction"), * commit 84fef630 ("MIPS: Emulate the new MIPS R6 BALC instruction"), * commit 69b9a2fd ("MIPS: Emulate the new MIPS R6 BEQZC and JIC instructions"), * commit 28d6f93d ("MIPS: Emulate the new MIPS R6 BNEZC and JIALC instructions"), * commit c893ce38 ("MIPS: Emulate the new MIPS R6 BOVC, BEQC and BEQZALC instructions") and send SIGILL rather than returning -SIGILL for R6 branch and jump instructions. Returning -SIGILL is never correct as the API defines this function's result upon error to be -EFAULT and a signal actually issued. Fixes: 8467ca01 ("MIPS: Emulate the new MIPS R6 branch compact (BC) instruction") Fixes: 84fef630 ("MIPS: Emulate the new MIPS R6 BALC instruction") Fixes: 69b9a2fd ("MIPS: Emulate the new MIPS R6 BEQZC and JIC instructions") Fixes: 28d6f93d ("MIPS: Emulate the new MIPS R6 BNEZC and JIALC instructions") Fixes: c893ce38 ("MIPS: Emulate the new MIPS R6 BOVC, BEQC and BEQZALC instructions") Signed-off-by:
-
Maciej W. Rozycki authored
Fix commit 319824ea ("MIPS: kernel: branch: Do not emulate the branch likelies on MIPS R6") and also send SIGILL rather than returning -SIGILL for BLTZAL, BLTZALL, BGEZAL and BGEZALL instruction encodings no longer supported in R6, except where emulated. Returning -SIGILL is never correct as the API defines this function's result upon error to be -EFAULT and a signal actually issued. Fixes: 319824ea ("MIPS: kernel: branch: Do not emulate the branch likelies on MIPS R6") Signed-off-by:
-
Maciej W. Rozycki authored
Use the more accurate `sigill_r2r6' name for the label used in the case of sending SIGILL in the absence of the instruction emulator for an earlier ISA level instruction that has been removed as from the R6 ISA, so that the `sigill_r6' name is freed for the situation where an R6 instruction is not supposed to be interpreted, because the executing processor does not support the R6 ISA. Signed-off-by:
-
Maciej W. Rozycki authored
Fix commit e50c0a8f ("Support the MIPS32 / MIPS64 DSP ASE.") and send SIGILL rather than SIGBUS whenever an unimplemented BPOSGE32 DSP ASE instruction has been encountered in `__compute_return_epc_for_insn' as our Reserved Instruction exception handler would in response to an attempt to actually execute the instruction. Sending SIGBUS only makes sense for the unaligned PC case, since moved to `__compute_return_epc'. Adjust function documentation accordingly, correct formatting and use `pr_info' rather than `printk' as the other exit path already does. Fixes: e50c0a8f ("Support the MIPS32 / MIPS64 DSP ASE.") Signed-off-by:
-
Maciej W. Rozycki authored
Fix a regression introduced with commit fb6883e5 ("MIPS: microMIPS: Support handling of delay slots.") and defer to `__compute_return_epc' if the ISA bit is set in EPC with non-MIPS16, non-microMIPS hardware, which will then arrange for a SIGBUS due to an unaligned instruction reference. Returning EPC here is never correct as the API defines this function's result to be either a negative error code on failure or one of 0 and BRANCH_LIKELY_TAKEN on success. Fixes: fb6883e5 ("MIPS: microMIPS: Support handling of delay slots.") Signed-off-by:
-
Maciej W. Rozycki authored
Complement commit fb6883e5 ("MIPS: microMIPS: Support handling of delay slots.") and actually decode the regular MIPS JALX major instruction opcode, the handling of which has been added with the said commit for EPC calculation in `__compute_return_epc_for_insn'. Fixes: fb6883e5 ("MIPS: microMIPS: Support handling of delay slots.") Signed-off-by:
-
Maciej W. Rozycki authored
Terminate FPU emulation immediately whenever an ISA mode switch has been observed. This is so that we do not interpret machine code in the wrong mode, for example when a regular MIPS FPU instruction has been placed in a delay slot of a jump that switches into the MIPS16 mode, as with the following code (taken from a GCC test suite case): 00400650 <set_fast_math>: 400650: 3c020100 lui v0,0x100 400654: 03e00008 jr ra 400658: 44c2f800 ctc1 v0,c1_fcsr 40065c: 00000000 nop [...] 004012d0 <__libc_csu_init>: 4012d0: f000 6a02 li v0,2 4012d4: f150 0b1c la v1,3f9430 <_DYNAMIC-0x6df0> 4012d8: f400 3240 sll v0,16 4012dc: e269 addu v0,v1 4012de: 659a move gp,v0 4012e0: f00c 64f6 save a0-a2,48,ra,s0-s1 4012e4: 673c move s1,gp 4012e6: f010 9978 lw v1,-32744(s1) 4012ea: d204 sw v0,16(sp) 4012ec: eb40 jalr v1 4012ee: 653b move t9,v1 4012f0: f010 997c lw v1,-32740(s1) 4012f4: f030 9920 lw s1,-32736(s1) 4012f8: e32f subu v1,s1 4012fa: 326b sra v0,v1,2 4012fc: d206 sw v0,24(sp) 4012fe: 220c beqz v0,401318 <__libc_csu_init+0x48> 401300: 6800 li s0,0 401302: 99e0 lw a3,0(s1) 401304: 4801 addiu s0,1 401306: 960e lw a2,56(sp) 401308: 4904 addiu s1,4 40130a: 950d lw a1,52(sp) 40130c: 940c lw a0,48(sp) 40130e: ef40 jalr a3 401310: 653f move t9,a3 401312: 9206 lw v0,24(sp) 401314: ea0a cmp v0,s0 401316: 61f5 btnez 401302 <__libc_csu_init+0x32> 401318: 6476 restore 48,ra,s0-s1 40131a: e8a0 jrc ra Here `set_fast_math' is called from `40130e' (`40130f' with the ISA bit) and emulation triggers for the CTC1 instruction. As it is in a jump delay slot emulation continues from `401312' (`401313' with the ISA bit). However we have no path to handle MIPS16 FPU code emulation, because there are no MIPS16 FPU instructions. So the default emulation path is taken, interpreting a 32-bit word fetched by `get_user' from `401313' as a regular MIPS instruction, which is: 401313: f5ea0a92 sdc1 $f10,2706(t7) This makes the FPU emulator proceed with the supposed SDC1 instruction and consequently makes the program considered here terminate with SIGSEGV. A similar although less severe issue exists with pure-microMIPS processors in the case where similarly an FPU instruction is emulated in a delay slot of a register jump that (incorrectly) switches into the regular MIPS mode. A subsequent instruction fetch from the jump's target is supposed to cause an Address Error exception, however instead we proceed with regular MIPS FPU emulation. For simplicity then, always terminate the emulation loop whenever a mode change is detected, denoted by an ISA mode bit flip. As from commit 377cb1b6 ("MIPS: Disable MIPS16/microMIPS crap for platforms not supporting these ASEs.") the result of `get_isa16_mode' can be hardcoded to 0, so we need to examine the ISA mode bit by hand. This complements commit 102cedc3 ("MIPS: microMIPS: Floating point support.") which added JALX decoding to FPU emulation. Fixes: 102cedc3 ("MIPS: microMIPS: Floating point support.") Signed-off-by:
-
Paul Burton authored
This patch switches MIPS to make use of generically implemented queued spinlocks, rather than the ticket spinlocks used previously. This allows us to drop a whole load of inline assembly, share more generic code, and is also a performance win. Results from running the AIM7 short workload on a MIPS Creator Ci40 (ie. 2 core 2 thread interAptiv CPU clocked at 546MHz) with v4.12-rc4 pistachio_defconfig, with ftrace disabled due to a current bug, and both with & without use of queued rwlocks & spinlocks: Forks | v4.12-rc4 | +qlocks | Change -------|-----------|----------|-------- 10 | 52630.32 | 53316.31 | +1.01% 20 | 51777.80 | 52623.15 | +1.02% 30 | 51645.92 | 52517.26 | +1.02% 40 | 51634.88 | 52419.89 | +1.02% 50 | 51506.75 | 52307.81 | +1.02% 60 | 51500.74 | 52322.72 | +1.02% 70 | 51434.81 | 52288.60 | +1.02% 80 | 51423.22 | 52434.85 | +1.02% 90 | 51428.65 | 52410.10 | +1.02% The kernels used for these tests also had my "MIPS: Hardcode cpu_has_* where known at compile time due to ISA" patch applied, which allows the kernel_uses_llsc checks in cmpxchg() & xchg() to be optimised away at compile time. Signed-off-by: -
Paul Burton authored
This patch switches MIPS to make use of generically implemented queued read/write locks, rather than the custom implementation used previously. This allows us to drop a whole load of inline assembly, share more generic code, and is also a performance win. Results from running the AIM7 short workload on a MIPS Creator Ci40 (ie. 2 core 2 thread interAptiv CPU clocked at 546MHz) with v4.12-rc4 pistachio_defconfig, with ftrace disabled due to a current bug, and both with & without use of queued rwlocks & spinlocks: Forks | v4.12-rc4 | +qlocks | Change -------|-----------|----------|-------- 10 | 52630.32 | 53316.31 | +1.01% 20 | 51777.80 | 52623.15 | +1.02% 30 | 51645.92 | 52517.26 | +1.02% 40 | 51634.88 | 52419.89 | +1.02% 50 | 51506.75 | 52307.81 | +1.02% 60 | 51500.74 | 52322.72 | +1.02% 70 | 51434.81 | 52288.60 | +1.02% 80 | 51423.22 | 52434.85 | +1.02% 90 | 51428.65 | 52410.10 | +1.02% The kernels used for these tests also had my "MIPS: Hardcode cpu_has_* where known at compile time due to ISA" patch applied, which allows the kernel_uses_llsc checks in cmpxchg() & xchg() to be optimised away at compile time. Signed-off-by: -
Paul Burton authored
The __xchg() function declares its first 2 arguments in reverse order compared to the xchg() macro, which is confusing & serves no purpose. Reorder the arguments such that __xchg() & xchg() match. Signed-off-by:
-
Paul Burton authored
Implement support for 1 & 2 byte cmpxchg() using read-modify-write atop a 4 byte cmpxchg(). This allows us to support these atomic operations despite the MIPS ISA only providing 4 & 8 byte atomic operations. This is required in order to support queued rwlocks (qrwlock) in a later patch, since these make use of a 1 byte cmpxchg() in their slow path. Signed-off-by:
-
Paul Burton authored
Implement 1 & 2 byte xchg() using read-modify-write atop a 4 byte cmpxchg(). This allows us to support these atomic operations despite the MIPS ISA only providing for 4 & 8 byte atomic operations. This is required in order to support queued spinlocks (qspinlock) in a later patch, since these make use of a 2 byte xchg() in their slow path. Signed-off-by:
-
Paul Burton authored
Replace the macro definition of __cmpxchg() with an inline function, which is easier to read & modify. The cmpxchg() & cmpxchg_local() macros are adjusted to call the new __cmpxchg() function. Signed-off-by:
-
Paul Burton authored
The __xchg_u32() & __xchg_u64() functions now add very little value. This patch therefore removes them, by: - Moving memory barriers out of them & into xchg(), which also removes the duplication & readies us to support xchg_relaxed() if we wish to. - Calling __xchg_asm() directly from __xchg(). - Performing the check for CONFIG_64BIT being enabled in the size=8 case of __xchg(). Signed-off-by: -
Paul Burton authored
xchg() has up until now simply returned the x parameter in cases where it is called with a pointer to a value of an unsupported size. This will often cause the calling code to hit a failure path, presuming that the value of x differs from the content of the memory pointed at by ptr, but we can do better by producing a compile-time or link-time error such that unsupported calls to xchg() are detectable earlier than runtime. This patch does this in the same was as is already done for cmpxchg(), using a call to a missing function annotated with __compiletime_error(). Signed-off-by:
-
Paul Burton authored
Our cmpxchg() implementation relies upon generating a call to a function which doesn't really exist (__cmpxchg_called_with_bad_pointer) to create a link failure in cases where cmpxchg() is called with a pointer to a value of an unsupported size. The __compiletime_error macro can be used to decorate a function such that a call to it generates a compile-time, rather than a link-time, error. This patch uses __compiletime_error to cause bad cmpxchg() calls to error out at compile time rather than link time, allowing errors to occur more quickly & making it easier to spot where the problem comes from. Signed-off-by:
-
Paul Burton authored
Use a macro to generate the 32 & 64 bit variants of the backing code for xchg(), much as is already done for cmpxchg(). This removes the duplication that could previously be found in __xchg_u32() & __xchg_u64(). Signed-off-by:
-
Paul Burton authored
Prior to this patch the xchg & cmpxchg functions have duplicated code which is for all intents & purposes identical apart from use of a branch-likely instruction in the R10000_LLSC_WAR case & a regular branch instruction in the non-R10000_LLSC_WAR case. This patch removes the duplication, declaring a __scbeqz macro to select the branch instruction suitable for use when checking the result of an sc instruction & making use of it to unify the 2 cases. In __xchg_u{32,64}() this means writing the branch in asm, where it was previously being done in C as a do...while loop for the non-R10000_LLSC_WAR case. As this is a single instruction, and adds consistency with the R10000_LLSC_WAR cases & the cmpxchg() code, this seems worthwhile. Signed-off-by: -
Miodrag Dinic authored
Add handling of missaligned access for DSP load instructions lwx & lhx. Since DSP instructions share SPECIAL3 opcode with other non-DSP instructions, necessary logic was inserted for distinguishing between instructions with SPECIAL3 opcode. For that purpose, the instruction format for DSP instructions is added to arch/mips/include/uapi/asm/inst.h. Signed-off-by:
Aleksandar Markovic <aleksandar.markovic@imgtech.com> Cc: James.Hogan@imgtec.com Cc: Paul.Burton@imgtec.com Cc: Raghu.Gandham@imgtec.com Cc: Leonid.Yegoshin@imgtec.com Cc: Douglas.Leung@imgtec.com Cc: Petar.Jovanovic@imgtec.com Cc: Goran.Ferenc@imgtec.com Cc: linux-mips@linux-mips.org Patchwork: https://patchwork.linux-mips.org/patch/16511/Signed-off-by:
-
Leonid Yegoshin authored
Disable usage of PREF instruction usage by memcpy for MIPS R6. MIPS R6 redefines PREF instruction with smaller offset than ordinary MIPS. However, the memcpy code uses PREF instruction with offsets bigger than +-256 bytes. Malta kernels already disable usage of PREF for memcpy. This was found during adaptation of MIPS R6 for virtual board used by Android emulator. Signed-off-by:
Leonid Yegoshin <Leonid.Yegoshin@imgtec.com> Signed-off-by:
-
Miodrag Dinic authored
Add "-modd-spreg" when compiling the kernel for mips32r6 target. This makes sure the kernel builds properly even with toolchains that use "-mno-odd-spreg" by default. This is the case with Android gcc. Prior to this patch, kernel builds using gcc for Android failed with following error messages, if target architecture is set to mips32r6: arch/mips/kernel/r4k_switch.S: Assembler messages: .../r4k_switch.S:210: Error: float register should be even, was 1 .../r4k_switch.S:212: Error: float register should be even, was 3 .../r4k_switch.S:214: Error: float register should be even, was 5 .../r4k_switch.S:216: Error: float register should be even, was 7 .../r4k_switch.S:218: Error: float register should be even, was 9 .../r4k_switch.S:220: Error: float register should be even, was 11 .../r4k_switch.S:222: Error: float register should be even, was 13 .../r4k_switch.S:224: Error: float register should be even, was 15 .../r4k_switch.S:226: Error: float register should be even, was 17 .../r4k_switch.S:228: Error: float register should be even, was 19 .../r4k_switch.S:230: Error: float register should be even, was 21 .../r4k_switch.S:232: Error: float register should be even, was 23 .../r4k_switch.S:234: Error: float register should be even, was 25 .../r4k_switch.S:236: Error: float register should be even, was 27 .../r4k_switch.S:238: Error: float register should be even, was 29 .../r4k_switch.S:240: Error: float register should be even, was 31 make[2]: *** [arch/mips/kernel/r4k_switch.o] Error 1 Signed-off-by:
-
Miodrag Dinic authored
Implement support for parsing 'memmap' kernel command line parameter. This patch covers parsing of the following two formats for 'memmap' parameter values: - nn[KMG]@ss[KMG] - nn[KMG]$ss[KMG] ([KMG] = K M or G (kilo, mega, giga)) These two allowed formats for parameter value are already documented in file kernel-parameters.txt in Documentation/admin-guide folder. Some architectures already support them, but Mips did not prior to this patch. Excerpt from Documentation/admin-guide/kernel-parameters.txt: memmap=nn[KMG]@ss[KMG] [KNL] Force usage of a specific region of memory. Region of memory to be used is from ss to ss+nn. memmap=nn[KMG]$ss[KMG] Mark specific memory as reserved. Region of memory to be reserved is from ss to ss+nn. Example: Exclude memory from 0x18690000-0x1869ffff memmap=64K$0x18690000 or memmap=0x10000$0x18690000 There is no need to update this documentation file with respect to this patch. Signed-off-by:
-
