- 11 11月, 2015 1 次提交
-
-
由 James Hogan 提交于
Remove the definition in locore.S and move a few of the other similar definitions in asm/mipsregs.h too. CP0_INTCTL, CP0_SRSCTL, & CP0_SRSMAP are unused so they're just dropped instead. CP0_DDATA_LO is left where it is as I have patches to eliminate its use in locore.S and it otherwise is unlikely to need to be used from assembly code. Signed-off-by: NJames Hogan <james.hogan@imgtec.com> Cc: Ralf Baechle <ralf@linux-mips.org> Cc: Paul Burton <paul.burton@imgtec.com> Cc: Paolo Bonzini <pbonzini@redhat.com> Cc: Gleb Natapov <gleb@kernel.org> Cc: linux-mips@linux-mips.org Cc: kvm@vger.kernel.org Patchwork: https://patchwork.linux-mips.org/patch/11461/Signed-off-by: NRalf Baechle <ralf@linux-mips.org>
-
- 26 10月, 2015 18 次提交
-
-
由 Paul Burton 提交于
If the kernel may make use of 64 bit addresses outside of the compatibility address space then we need to set KX such that those accesses can succeed. Do so for MIPS64 kernels. Signed-off-by: NPaul Burton <paul.burton@imgtec.com> Cc: linux-mips@linux-mips.org Cc: Markos Chandras <markos.chandras@imgtec.com> Cc: linux-kernel@vger.kernel.org Patchwork: https://patchwork.linux-mips.org/patch/11201/Signed-off-by: NRalf Baechle <ralf@linux-mips.org>
-
由 Paul Burton 提交于
Set the Status.BEV bit throughout the early startup of a secondary core such that if an exception occurs the core branches to one of the exception vector entries from cps-vec.S, rather than branching to whatever is set in EBase. Signed-off-by: NPaul Burton <paul.burton@imgtec.com> Cc: linux-mips@linux-mips.org Cc: Markos Chandras <markos.chandras@imgtec.com> Cc: linux-kernel@vger.kernel.org Patchwork: https://patchwork.linux-mips.org/patch/11200/Signed-off-by: NRalf Baechle <ralf@linux-mips.org>
-
由 Paul Burton 提交于
CM3 has 64 bit GCR_ERROR_* registers, but the code in mips_cm_error_report was previously only reading 32 bits of it in MIPS32 kernels. Fix by splitting the reads for CM2 & CM3, and making use of the read64_ variants of the accessor function for CM3. Signed-off-by: NPaul Burton <paul.burton@imgtec.com> Cc: linux-mips@linux-mips.org Cc: linux-kernel@vger.kernel.org Cc: James Hogan <james.hogan@imgtec.com> Cc: Markos Chandras <markos.chandras@imgtec.com> Patchwork: https://patchwork.linux-mips.org/patch/11189/Signed-off-by: NRalf Baechle <ralf@linux-mips.org>
-
由 Paul Burton 提交于
If we run a MIPS32 kernel on a system using CM3 we may still need to access 64 bit GCRs, as will be done in later patches. Allow this by having the read64_gcr_* accessor functions perform 2 x 32 bit reads on those systems. Signed-off-by: NPaul Burton <paul.burton@imgtec.com> Cc: linux-mips@linux-mips.org Cc: linux-kernel@vger.kernel.org Cc: James Hogan <james.hogan@imgtec.com> Cc: Markos Chandras <markos.chandras@imgtec.com> Patchwork: https://patchwork.linux-mips.org/patch/11188/Signed-off-by: NRalf Baechle <ralf@linux-mips.org>
-
由 Paul Burton 提交于
Commit 3885c2b4 ("MIPS: CM: Add support for reporting CM cache errors") added cases for decoding errors reported by CM3, but leaves the buf variable which is printed as a string uninitialised for cause values other than 1, 2 or 3. Fix by ensuring the buf variable is initialised to an empty string in such cases. Signed-off-by: NPaul Burton <paul.burton@imgtec.com> Cc: linux-mips@linux-mips.org Cc: Markos Chandras <markos.chandras@imgtec.com> Cc: linux-kernel@vger.kernel.org Patchwork: https://patchwork.linux-mips.org/patch/11187/Signed-off-by: NRalf Baechle <ralf@linux-mips.org>
-
由 Paul Burton 提交于
Commit 3885c2b4 ("MIPS: CM: Add support for reporting CM cache errors") leads to Malta boards unconditionally reading CM GCRs upon bus errors, regardless of whether a CM is present. This is incorrect & will lead to further exceptions. Fix by moving the GCR reads to after the check for whether a CM is present. Signed-off-by: NPaul Burton <paul.burton@imgtec.com> Cc: linux-mips@linux-mips.org Cc: Markos Chandras <markos.chandras@imgtec.com> Cc: linux-kernel@vger.kernel.org Patchwork: https://patchwork.linux-mips.org/patch/11186/Signed-off-by: NRalf Baechle <ralf@linux-mips.org>
-
由 Paul Burton 提交于
The documentation for mips_cm_is64 implied that the width of the CM GCRs would change depending upon the CPU, which is not true. Reword the explanation to be clearer that the GCR width is purely dependent upon the version of the CM. Signed-off-by: NPaul Burton <paul.burton@imgtec.com> Cc: linux-mips@linux-mips.org Cc: linux-kernel@vger.kernel.org Cc: James Hogan <james.hogan@imgtec.com> Cc: Markos Chandras <markos.chandras@imgtec.com> Patchwork: https://patchwork.linux-mips.org/patch/11185/Signed-off-by: NRalf Baechle <ralf@linux-mips.org>
-
由 Paul Burton 提交于
A boundary exists beyond which the timer frequency becomes high enough that timer interrupts saturate the system and either cause it to slow to a crawl or stop functioning entirely. Where that boundary lies depends upon a number of factors such as the overhead of each interrupt and the overall speed of the CPU, but correlates strongly with the clock frequency at which the CPU runs. When running on emulators during bringup or debug of a CPU that clock frequency is very low, which results in the boundary at which the timer frequency becomes unsustainable being very low. The current minimum of 48Hz pushes against boundary in certain situations in current systems. Allow the kernel to be configured for a 24Hz timer frequency in order to avoid problems on such slow running systems. Signed-off-by: NPaul Burton <paul.burton@imgtec.com> Cc: linux-mips@linux-mips.org Cc: linux-kernel@vger.kernel.org Patchwork: https://patchwork.linux-mips.org/patch/11184/Signed-off-by: NRalf Baechle <ralf@linux-mips.org>
-
由 Paul Burton 提交于
Rather than #ifdef on CONFIG_KVM_GUEST & redefine the guest kseg0 base locally, make use of the CAC_BASE macro which has the correct value in both cases. Signed-off-by: NPaul Burton <paul.burton@imgtec.com> Cc: James Hogan <james.hogan@imgtec.com> Cc: linux-mips@linux-mips.org Cc: Leonid Yegoshin <Leonid.Yegoshin@imgtec.com> Cc: Maciej W. Rozycki <macro@linux-mips.org> Cc: linux-kernel@vger.kernel.org Cc: Markos Chandras <markos.chandras@imgtec.com> Patchwork: https://patchwork.linux-mips.org/patch/11183/Signed-off-by: NRalf Baechle <ralf@linux-mips.org>
-
由 Thierry Reding 提交于
The board code never sets up a leds-pwm device, so including the header is not necessary. Signed-off-by: NThierry Reding <thierry.reding@gmail.com> Acked-by: NLars-Peter Clausen <lars@metafoo.de> Cc: Lars-Peter Clausen <lars@metafoo.de> Cc: linux-mips@linux-mips.org Cc: linux-kernel@vger.kernel.org Patchwork: https://patchwork.linux-mips.org/patch/11262/Signed-off-by: NRalf Baechle <ralf@linux-mips.org>
-
由 Thierry Reding 提交于
Associate the PWM with the pwm-beeper device using a PWM lookup table. This will eventually allow the legacy function calls to pwm_request() to be removed from all consumer drivers. Signed-off-by: NThierry Reding <thierry.reding@gmail.com> Cc: Lars-Peter Clausen <lars@metafoo.de> Cc: linux-mips@linux-mips.org Cc: linux-kernel@vger.kernel.org Patchwork: https://patchwork.linux-mips.org/patch/11261/Signed-off-by: NRalf Baechle <ralf@linux-mips.org>
-
由 Ralf Baechle 提交于
ARCH_USE_BUILTIN_BSWAP will use __builtin_bswap16(), __builtin_bswap32() and __builtin_bswap64() where available. This allows better instruction scheduling. On pre-R2 processors it will result in 32 bit and 64 bit swapping being performed in a call to a __bswapsi2() rsp. __bswapdi2() functions, so we add these, too. For a 4.2 kernel with GCC 4.9 this yields the following kernel sizes: text data bss dec hex filename 3996071 155804 88992 4240867 40b5e3 vmlinux ip22 baseline 3985687 159900 88992 4234579 409d53 vmlinux ip22 + bswap patch 6913157 378552 251024 7542733 7317cd vmlinux ip27 baseline 6878581 378552 251024 7508157 7290bd vmlinux ip27 + bswap patch 5773777 268752 187424 6229953 5f0fc1 vmlinux malta baseline 5773401 268752 187424 6229577 5f0e49 vmlinux malta + bswap patch Presumably the code size improvments yield better cache hit rate thus better performance compensating for the extra function call but this will still need to be benchmarked. Signed-off-by: NRalf Baechle <ralf@linux-mips.org>
-
由 Paul Burton 提交于
When debugging or examining the performance of a system it can be useful to examine the effect of L2 prefetching. Provide an optional debugfs entry to allow a user to enable or disable L2 prefetching. Signed-off-by: NPaul Burton <paul.burton@imgtec.com> Cc: Maciej W. Rozycki <macro@linux-mips.org> Cc: linux-mips@linux-mips.org Cc: linux-kernel@vger.kernel.org Patchwork: https://patchwork.linux-mips.org/patch/11182/Signed-off-by: NRalf Baechle <ralf@linux-mips.org>
-
由 Paul Burton 提交于
We have many extern declarations of mips_debugfs_dir through arch/mips/ in various C files. Unify them by declaring mips_debugfs_dir in a header, including it in each affected C file & removing the duplicate declarations. Signed-off-by: NPaul Burton <paul.burton@imgtec.com> Cc: linux-mips@linux-mips.org Cc: Steven J. Hill <Steven.Hill@imgtec.com> Cc: Alexander Sverdlin <alexander.sverdlin@nokia.com> Cc: Masahiro Yamada <yamada.masahiro@socionext.com> Cc: Leonid Yegoshin <Leonid.Yegoshin@imgtec.com> Cc: Maciej W. Rozycki <macro@linux-mips.org> Cc: linux-kernel@vger.kernel.org Cc: Joe Perches <joe@perches.com> Cc: Jaedon Shin <jaedon.shin@gmail.com> Cc: James Hogan <james.hogan@imgtec.com> Cc: David Daney <david.daney@cavium.com> Cc: Zubair Lutfullah Kakakhel <Zubair.Kakakhel@imgtec.com> Cc: Markos Chandras <markos.chandras@imgtec.com> Cc: James Cowgill <James.Cowgill@imgtec.com> Patchwork: https://patchwork.linux-mips.org/patch/11181/Signed-off-by: NRalf Baechle <ralf@linux-mips.org>
-
由 Paul Burton 提交于
On systems with CM 2.5 & beyond there may be L2 prefetch units present which are not enabled by default. Detect them, configuring & enabling prefetching when available. Signed-off-by: NPaul Burton <paul.burton@imgtec.com> Cc: linux-mips@linux-mips.org Cc: Leonid Yegoshin <Leonid.Yegoshin@imgtec.com> Cc: linux-kernel@vger.kernel.org Cc: James Hogan <james.hogan@imgtec.com> Cc: Markos Chandras <markos.chandras@imgtec.com> Patchwork: https://patchwork.linux-mips.org/patch/11180/Signed-off-by: NRalf Baechle <ralf@linux-mips.org>
-
由 Paul Burton 提交于
Introduce new functions in struct bcache_ops to enable & disable L2 cache prefetching, and to retrieve the current state of L2 prefetching. This will be used in later patches. Signed-off-by: NPaul Burton <paul.burton@imgtec.com> Cc: linux-mips@linux-mips.org Cc: linux-kernel@vger.kernel.org Patchwork: https://patchwork.linux-mips.org/patch/11179/Signed-off-by: NRalf Baechle <ralf@linux-mips.org>
-
由 Paul Burton 提交于
When debugging it can be helpful to change the policy for compiler use of MIPSr6 compact branches, in order to rule out or home in on their involvement in bugs. Allow the GCC -mcompact-branches= flag to be set via Kconfig under the "Kernel hacking" menu. Signed-off-by: NPaul Burton <paul.burton@imgtec.com> Cc: linux-mips@linux-mips.org Cc: linux-kernel@vger.kernel.org Patchwork: https://patchwork.linux-mips.org/patch/11178/Signed-off-by: NRalf Baechle <ralf@linux-mips.org>
-
由 Andrzej Hajda 提交于
Unsigned values cannot be lesser than zero. The problem has been detected using proposed semantic patch scripts/coccinelle/tests/unsigned_lesser_than_zero.cocci [1]. [ralf@linux-mips.org: Chris Dearman's original commit 9318c51a ([MIPS] MIPS32/MIPS64 secondary cache management) introduced these less than zero checks in 2.6.18.] [1]: http://permalink.gmane.org/gmane.linux.kernel/2038576Signed-off-by: NAndrzej Hajda <a.hajda@samsung.com> Cc: linux-kernel@vger.kernel.org Cc: Bartlomiej Zolnierkiewicz <b.zolnierkie@samsung.com> Cc: Marek Szyprowski <m.szyprowski@samsung.com> Cc: Markos Chandras <markos.chandras@imgtec.com> Cc: Chris Dearman <chris.dearman@imgtec.com> Cc: linux-mips@linux-mips.org Patchwork: https://patchwork.linux-mips.org/patch/11165/Signed-off-by: NRalf Baechle <ralf@linux-mips.org>
-
- 06 10月, 2015 1 次提交
-
-
由 Ben Hutchings 提交于
All architectures must now define ioremap_uc(), but MIPS currently only has ioremap_nocache(). Fixes: 4c73e892 ("arch/*/io.h: Add ioremap_uc() to all architectures") Signed-off-by: NBen Hutchings <ben@decadent.org.uk> Cc: Luis R. Rodriguez <mcgrof@suse.com> Cc: linux-mips@linux-mips.org Patchwork: https://patchwork.linux-mips.org/patch/11263/Signed-off-by: NRalf Baechle <ralf@linux-mips.org>
-
- 05 10月, 2015 2 次提交
-
-
由 Yousong Zhou 提交于
Some GCC versions (e.g. 4.8.3) can incorrectly inline a function with MIPS32 instructions into another function with MIPS16 code [1], causing the assembler to genereate incorrect binary code or fail right away complaining about unrecognized opcode. In the case of __arch_swab{16,32}, when inlined by the compiler with flags `-mips32r2 -mips16 -Os', the assembler can fail with the following error. {standard input}:79: Error: unrecognized opcode `wsbh $2,$2' For performance concerns and to workaround the issue already existing in older compilers, just ignore these 2 functions when compiling with mips16 enabled. [1] Inlining nomips16 function into mips16 function can result in undefined builtins, https://gcc.gnu.org/bugzilla/show_bug.cgi?id=55777Signed-off-by: NYousong Zhou <yszhou4tech@gmail.com> Cc: Maciej W. Rozycki <macro@linux-mips.org> Cc: linux-mips@linux-mips.org Patchwork: https://patchwork.linux-mips.org/patch/11241/Signed-off-by: NRalf Baechle <ralf@linux-mips.org>
-
由 Yousong Zhou 提交于
This reverts commit e0d8b2ec. For at least GCC 4.8.3, adding nomips16 function attribute still cannot prevent it from being inlined in mips16 context. So revert it first in preparation for a better workaround. [1] Inlining nomips16 function into mips16 function can result in undefined builtins, https://gcc.gnu.org/bugzilla/show_bug.cgi?id=55777Signed-off-by: NYousong Zhou <yszhou4tech@gmail.com> Cc: Maciej W. Rozycki <macro@linux-mips.org> Cc: linux-mips@linux-mips.org Patchwork: https://patchwork.linux-mips.org/patch/11240/Signed-off-by: NRalf Baechle <ralf@linux-mips.org>
-
- 04 10月, 2015 1 次提交
-
-
由 Markos Chandras 提交于
The MIPS syscall handler code used to return -ENOSYS on invalid syscalls. Whilst this is expected, it caused problems for seccomp filters because the said filters never had the change to run since the code returned -ENOSYS before triggering them. This caused problems on the chromium testsuite for filters looking for invalid syscalls. This has now changed and the seccomp filters are always run even if the syscall is invalid. We return -ENOSYS once we return from the seccomp filters. Moreover, similar codepaths have been merged in the process which simplifies somewhat the overall syscall code. Signed-off-by: NMarkos Chandras <markos.chandras@imgtec.com> Cc: linux-mips@linux-mips.org Patchwork: https://patchwork.linux-mips.org/patch/11236/Signed-off-by: NRalf Baechle <ralf@linux-mips.org>
-
- 03 10月, 2015 3 次提交
-
-
由 Matt Bennett 提交于
During development it was found that a number of builds would panic during the kernel init process, more specifically in 'delayed_fput()'. The panic showed the kernel trying to access a memory address of '0xb7fdc00' while traversing the 'delayed_fput_list' structure. Comparing this memory address to the value of the pointer used on builds that did not panic confirmed that the pointer on crashing builds must have been corrupted at some stage earlier in the init process. By traversing the list earlier and earlier in the code it was found that 'plat_mem_setup()' was responsible for corrupting the list. Specifically the line: memory = cvmx_bootmem_phy_alloc(mem_alloc_size, __pa_symbol(&__init_end), -1, 0x100000, CVMX_BOOTMEM_FLAG_NO_LOCKING); Which would eventually call: cvmx_bootmem_phy_set_size(new_ent_addr, cvmx_bootmem_phy_get_size (ent_addr) - (desired_min_addr - ent_addr)); Where 'new_ent_addr'=0x4800000 (the address of 'delayed_fput_list') and the second argument (size)=0xb7fdc00 (the address causing the kernel panic). The job of this part of 'plat_mem_setup()' is to allocate chunks of memory for the kernel to use. At the start of each chunk of memory the size of the chunk is written, hence the value 0xb7fdc00 is written onto memory at 0x4800000, therefore the kernel panics when it goes back to access 'delayed_fput_list' later on in the initialisation process. On builds that were not crashing it was found that the compiler had placed 'delayed_fput_list' at 0x4800008, meaning it wasn't corrupted (but something else in memory was overwritten). As can be seen in the first function call above the code begins to allocate chunks of memory beginning from the symbol '__init_end'. The MIPS linker script (vmlinux.lds.S) however defines the .bss section to begin after '__init_end'. Therefore memory within the .bss section is allocated to the kernel to use (System.map shows 'delayed_fput_list' and other kernel structures to be in .bss). To stop the kernel panic (and the .bss section being corrupted) memory should begin being allocated from the symbol '_end'. Signed-off-by: NMatt Bennett <matt.bennett@alliedtelesis.co.nz> Acked-by: NDavid Daney <david.daney@cavium.com> Cc: linux-mips@linux-mips.org Cc: aleksey.makarov@auriga.com Patchwork: https://patchwork.linux-mips.org/patch/11251/Signed-off-by: NRalf Baechle <ralf@linux-mips.org>
-
由 Paul Burton 提交于
Commit 1a3d5957 ("MIPS: Tidy up FPU context switching") removed FP context saving from the asm-written resume function in favour of reusing existing code to perform the same task. However it only removed the FP context saving code from the r4k_switch.S implementation of resume. Remove it from the r2300_switch.S implementation too in order to prevent attempting to save the FP context twice, which would likely lead to an exception from the second save because the FPU had already been disabled by the first save. This patch has only been build tested, using rbtx49xx_defconfig. Fixes: 1a3d5957 ("MIPS: Tidy up FPU context switching") Signed-off-by: NPaul Burton <paul.burton@imgtec.com> Cc: linux-mips@linux-mips.org Cc: Maciej W. Rozycki <macro@linux-mips.org> Cc: linux-kernel@vger.kernel.org Cc: Manuel Lauss <manuel.lauss@gmail.com> Patchwork: https://patchwork.linux-mips.org/patch/11167/Signed-off-by: NRalf Baechle <ralf@linux-mips.org>
-
由 Paul Burton 提交于
Commit 1a3d5957 ("MIPS: Tidy up FPU context switching") removed FP context saving from the asm-written resume function in favour of reusing existing code to perform the same task. However it only removed the FP context saving code from the r4k_switch.S implementation of resume. Octeon uses its own implementation in octeon_switch.S, so remove FP context saving there too in order to prevent attempting to save context twice. That formerly led to an exception from the second save as follows because the FPU had already been disabled by the first save: do_cpu invoked from kernel context![#1]: CPU: 0 PID: 2 Comm: kthreadd Not tainted 4.3.0-rc2-dirty #2 task: 800000041f84a008 ti: 800000041f864000 task.ti: 800000041f864000 $ 0 : 0000000000000000 0000000010008ce1 0000000000100000 ffffffffbfffffff $ 4 : 800000041f84a008 800000041f84ac08 800000041f84c000 0000000000000004 $ 8 : 0000000000000001 0000000000000000 0000000000000000 0000000000000001 $12 : 0000000010008ce3 0000000000119c60 0000000000000036 800000041f864000 $16 : 800000041f84ac08 800000000792ce80 800000041f84a008 ffffffff81758b00 $20 : 0000000000000000 ffffffff8175ae50 0000000000000000 ffffffff8176c740 $24 : 0000000000000006 ffffffff81170300 $28 : 800000041f864000 800000041f867d90 0000000000000000 ffffffff815f3fa0 Hi : 0000000000fa8257 Lo : ffffffffe15cfc00 epc : ffffffff8112821c resume+0x9c/0x200 ra : ffffffff815f3fa0 __schedule+0x3f0/0x7d8 Status: 10008ce2 KX SX UX KERNEL EXL Cause : 1080002c (ExcCode 0b) PrId : 000d0601 (Cavium Octeon+) Modules linked in: Process kthreadd (pid: 2, threadinfo=800000041f864000, task=800000041f84a008, tls=0000000000000000) Stack : ffffffff81604218 ffffffff815f7e08 800000041f84a008 ffffffff811681b0 800000041f84a008 ffffffff817e9878 0000000000000000 ffffffff81770000 ffffffff81768340 ffffffff81161398 0000000000000001 0000000000000000 0000000000000000 ffffffff815f4424 0000000000000000 ffffffff81161d68 ffffffff81161be8 0000000000000000 0000000000000000 0000000000000000 0000000000000000 0000000000000000 0000000000000000 ffffffff8111e16c 0000000000000000 0000000000000000 0000000000000000 0000000000000000 0000000000000000 0000000000000000 0000000000000000 0000000000000000 0000000000000000 0000000000000000 0000000000000000 0000000000000000 0000000000000000 0000000000000000 0000000000000000 0000000000000000 ... Call Trace: [<ffffffff8112821c>] resume+0x9c/0x200 [<ffffffff815f3fa0>] __schedule+0x3f0/0x7d8 [<ffffffff815f4424>] schedule+0x34/0x98 [<ffffffff81161d68>] kthreadd+0x180/0x198 [<ffffffff8111e16c>] ret_from_kernel_thread+0x14/0x1c Tested using cavium_octeon_defconfig on an EdgeRouter Lite. Fixes: 1a3d5957 ("MIPS: Tidy up FPU context switching") Reported-by: NAaro Koskinen <aaro.koskinen@nokia.com> Signed-off-by: NPaul Burton <paul.burton@imgtec.com> Cc: linux-mips@linux-mips.org Cc: Aleksey Makarov <aleksey.makarov@auriga.com> Cc: linux-kernel@vger.kernel.org Cc: Chandrakala Chavva <cchavva@caviumnetworks.com> Cc: David Daney <david.daney@cavium.com> Cc: Leonid Rosenboim <lrosenboim@caviumnetworks.com> Patchwork: https://patchwork.linux-mips.org/patch/11166/Signed-off-by: NRalf Baechle <ralf@linux-mips.org>
-
- 02 10月, 2015 1 次提交
-
-
由 Ralf Baechle 提交于
The entire bpf_jit_asm.S is written in noreorder mode because "we know better" according to a comment. This also prevented the assembler from throwing in the required NOPs for MIPS I processors which have no load-use interlock, thus the load's consumer might end up using the old value of the register from prior to the load. Fixed by putting the assembler in reorder mode for just the affected load instructions. This is not enough for gas to actually try to be clever by looking at the next instruction and inserting a nop only when needed but as the comment said "we know better", so getting gas to unconditionally emit a NOP is just right in this case and prevents adding further ifdefery. Signed-off-by: NRalf Baechle <ralf@linux-mips.org>
-
- 01 10月, 2015 5 次提交
-
-
由 Ralf Baechle 提交于
FEXPORT also marks the symbol as code using .type symbol, @function. Without objdump -d will output only a hexdump for code following the affected symbols. Signed-off-by: NRalf Baechle <ralf@linux-mips.org>
-
由 Alban Bedel 提交于
Somehow the wrong version of the patch to remove the use of custom gpio.h on mips has been merged. This patch add the missing fixes for a build error on jz4740 because linux/gpio.h doesn't provide any machine specfics definitions anymore. Signed-off-by: NAlban Bedel <albeu@free.fr> Cc: Paul Burton <paul.burton@imgtec.com> Cc: Lars-Peter Clausen <lars@metafoo.de> Cc: Brian Norris <computersforpeace@gmail.com> Cc: Thomas Gleixner <tglx@linutronix.de> Cc: Linus Walleij <linus.walleij@linaro.org> Cc: linux-mips@linux-mips.org Cc: linux-kernel@vger.kernel.org Patchwork: https://patchwork.linux-mips.org/patch/11089/Signed-off-by: NRalf Baechle <ralf@linux-mips.org>
-
由 Paul Burton 提交于
The CONFIG_MIPS_MT symbol can be selected by CONFIG_MIPS_VPE_LOADER in addition to CONFIG_MIPS_MT_SMP. We only want MT code in the CPS SMP boot vector if we're using MT for SMP. Thus switch the config symbol we ifdef against to CONFIG_MIPS_MT_SMP. Signed-off-by: NPaul Burton <paul.burton@imgtec.com> Cc: Markos Chandras <markos.chandras@imgtec.com> Cc: James Hogan <james.hogan@imgtec.com> Cc: <stable@vger.kernel.org> # 3.16+ Cc: linux-mips@linux-mips.org Cc: linux-kernel@vger.kernel.org Patchwork: https://patchwork.linux-mips.org/patch/10867/Signed-off-by: NRalf Baechle <ralf@linux-mips.org>
-
由 Paul Burton 提交于
The MT-specific code in mips_cps_boot_vpes can safely be omitted from kernels which don't support MT, with the default VPE==0 case being used as it would be after the has_mt (Config3.MT) check failed at runtime. Discarding the code entirely will save us a few bytes & allow cleaner handling of MT ASE instructions by later patches. Signed-off-by: NPaul Burton <paul.burton@imgtec.com> Cc: Markos Chandras <markos.chandras@imgtec.com> Cc: James Hogan <james.hogan@imgtec.com> Cc: <stable@vger.kernel.org> # 3.16+ Cc: linux-mips@linux-mips.org Cc: linux-kernel@vger.kernel.org Patchwork: https://patchwork.linux-mips.org/patch/10866/Signed-off-by: NRalf Baechle <ralf@linux-mips.org>
-
由 Paul Burton 提交于
The has_mt macro ended with a branch, leaving its callers with a delay slot that would be executed if Config3.MT is not set. However it would not be executed if Config3 (or earlier Config registers) don't exist which makes it somewhat inconsistent at best. Fill the delay slot in the macro & fix the mips_cps_boot_vpes caller appropriately. Signed-off-by: NPaul Burton <paul.burton@imgtec.com> Cc: Markos Chandras <markos.chandras@imgtec.com> Cc: James Hogan <james.hogan@imgtec.com> Cc: <stable@vger.kernel.org> # 3.16+ Cc: linux-mips@linux-mips.org Cc: linux-kernel@vger.kernel.org Patchwork: https://patchwork.linux-mips.org/patch/10865/Signed-off-by: NRalf Baechle <ralf@linux-mips.org>
-
- 30 9月, 2015 2 次提交
-
-
由 James Hogan 提交于
If there is a DMA zone (usually 24bit = 16MB I believe), but no DMA32 zone, as is the case for some 32-bit kernels, then massage_gfp_flags() will cause DMA memory allocated for devices with a 32..63-bit coherent_dma_mask to fall back to using __GFP_DMA, even though there may only be 32-bits of physical address available anyway. Correct that case to compare against a mask the size of phys_addr_t instead of always using a 64-bit mask. Signed-off-by: NJames Hogan <james.hogan@imgtec.com> Fixes: a2e715a8 ("MIPS: DMA: Fix computation of DMA flags from device's coherent_dma_mask.") Cc: Ralf Baechle <ralf@linux-mips.org> Cc: linux-mips@linux-mips.org Cc: <stable@vger.kernel.org> # 2.6.36+ Patchwork: https://patchwork.linux-mips.org/patch/9610/Signed-off-by: NRalf Baechle <ralf@linux-mips.org>
-
由 Ralf Baechle 提交于
Signed-off-by: NRalf Baechle <ralf@linux-mips.org>
-
- 27 9月, 2015 4 次提交
-
-
由 Paul Burton 提交于
MAARs should be initialised on each CPU (or rather, core) in the system in order to achieve consistent behaviour & performance. Previously they have only been initialised on the boot CPU which leads to performance problems if tasks are later scheduled on a secondary CPU, particularly if those tasks make use of unaligned vector accesses where some CPUs don't handle any cases in hardware for non-speculative memory regions. Fix this by recording the MAAR configuration from the boot CPU and applying it to secondary CPUs as part of their bringup. Reported-by: NDoug Gilmore <doug.gilmore@imgtec.com> Signed-off-by: NPaul Burton <paul.burton@imgtec.com> Cc: linux-mips@linux-mips.org Cc: Rusty Russell <rusty@rustcorp.com.au> Cc: Steven J. Hill <Steven.Hill@imgtec.com> Cc: Andrew Bresticker <abrestic@chromium.org> Cc: Bjorn Helgaas <bhelgaas@google.com> Cc: David Hildenbrand <dahi@linux.vnet.ibm.com> Cc: linux-kernel@vger.kernel.org Cc: Aaro Koskinen <aaro.koskinen@iki.fi> Cc: James Hogan <james.hogan@imgtec.com> Cc: Ingo Molnar <mingo@kernel.org> Cc: Markos Chandras <markos.chandras@imgtec.com> Cc: Hemmo Nieminen <hemmo.nieminen@iki.fi> Cc: Alex Smith <alex.smith@imgtec.com> Cc: Peter Zijlstra (Intel) <peterz@infradead.org> Patchwork: https://patchwork.linux-mips.org/patch/11239/Signed-off-by: NRalf Baechle <ralf@linux-mips.org>
-
由 Paul Burton 提交于
Verifying that the MAAR configuration is as expected is useful when debugging the performance of a system. Print out the memory regions configured via MAAR along with their attributes. Signed-off-by: NPaul Burton <paul.burton@imgtec.com> Cc: linux-mips@linux-mips.org Cc: Steven J. Hill <Steven.Hill@imgtec.com> Cc: David Hildenbrand <dahi@linux.vnet.ibm.com> Cc: linux-kernel@vger.kernel.org Cc: Peter Zijlstra (Intel) <peterz@infradead.org> Patchwork: https://patchwork.linux-mips.org/patch/11238/Signed-off-by: NRalf Baechle <ralf@linux-mips.org>
-
由 Paul Burton 提交于
maar_init was previously only compiled when CONFIG_NEED_MULTIPLE_NODES was not set, which has been fine since it is only called from the standard implementation of mem_init which has the same condition. In preparation for calling it from the SMP startup code on secondary CPUs, move maar_init outside of the #ifndef such that it is always compiled. Signed-off-by: NPaul Burton <paul.burton@imgtec.com> Cc: Markos Chandras <markos.chandras@imgtec.com> Cc: linux-mips@linux-mips.org Cc: Steven J. Hill <Steven.Hill@imgtec.com> Cc: David Hildenbrand <dahi@linux.vnet.ibm.com> Cc: linux-kernel@vger.kernel.org Cc: Ingo Molnar <mingo@kernel.org> Patchwork: https://patchwork.linux-mips.org/patch/11237/Signed-off-by: NRalf Baechle <ralf@linux-mips.org>
-
由 Paul Burton 提交于
The VP ID of a given CPU may not match up with the CPU number used by Linux. For example, if the width of the VP part of the VP ID is wider than log2(number of VPs per core) and the system has multiple cores then this will be the case. Alternatively, if a pre-r6 system implements the MT ASE with multiple VPEs per core and Linux is built without support for the MT ASE then the numbers won't match up either. Provide a function to convert from CPU number to VP ID. Signed-off-by: NPaul Burton <paul.burton@imgtec.com> Acked-by: NThomas Gleixner <tglx@linutronix.de> Cc: linux-mips@linux-mips.org Cc: linux-kernel@vger.kernel.org Cc: James Hogan <james.hogan@imgtec.com> Cc: Markos Chandras <markos.chandras@imgtec.com> Patchwork: https://patchwork.linux-mips.org/patch/11211/Signed-off-by: NRalf Baechle <ralf@linux-mips.org>
-
- 25 9月, 2015 1 次提交
-
-
由 David Hildenbrand 提交于
We observed some performance degradation on s390x with dynamic halt polling. Until we can provide a proper fix, let's enable halt_poll_ns as default only for supported architectures. Architectures are now free to set their own halt_poll_ns default value. Signed-off-by: NDavid Hildenbrand <dahi@linux.vnet.ibm.com> Signed-off-by: NPaolo Bonzini <pbonzini@redhat.com>
-
- 23 9月, 2015 1 次提交
-
-
由 James Hogan 提交于
R6 removed the Config4.MMUExtDef field, with the low 16 bits only allowed to contain FTLB fields, and commit e87569cd ("MIPS: cpu-probe: Fix VTLB/FTLB configuration for R6") updated the probing of this field to assume an FTLB is always present for R6. However the FTLB may still be absent. The presence of those fields is actually specified by the MMU type in the Config.MT field, so use that (the new cpu_has_ftlb) to determine whether the FTLB is actually present. Fixes: e87569cd ("MIPS: cpu-probe: Fix VTLB/FTLB configuration for R6") Signed-off-by: NJames Hogan <james.hogan@imgtec.com> Cc: Ralf Baechle <ralf@linux-mips.org> Cc: Markos Chandras <markos.chandras@imgtec.com> Cc: linux-mips@linux-mips.org Patchwork: https://patchwork.linux-mips.org/patch/11160/Signed-off-by: NRalf Baechle <ralf@linux-mips.org>
-