- 28 May, 2016 18 commits
-
-
Andrea Gelmini authored
Signed-off-by:
Andrea Gelmini <andrea.gelmini@gelma.net> Cc: chenhc@lemote.com Cc: james.hogan@imgtec.com Cc: linux-mips@linux-mips.org Cc: trivial@kernel.org Patchwork: https://patchwork.linux-mips.org/patch/13317/Signed-off-by:
Ralf Baechle <ralf@linux-mips.org>
-
Dan Carpenter authored
These should be ">=" instead of ">" or we go past the end of the pvc_lines[] array. Signed-off-by:
Dan Carpenter <dan.carpenter@oracle.com> Cc: linux-mips@linux-mips.org Cc: kernel-janitors@vger.kernel.org Patchwork: https://patchwork.linux-mips.org/patch/6124/Signed-off-by:
-
Álvaro Fernández Rojas authored
Signed-off-by:
Álvaro Fernández Rojas <noltari@gmail.com> Cc: john@phrozen.org Cc: linux-mips@linux-mips.org Cc: linux-kernel@vger.kernel.org Patchwork: https://patchwork.linux-mips.org/patch/13308/Signed-off-by:
-
Álvaro Fernández Rojas authored
Signed-off-by:
-
Álvaro Fernández Rojas authored
Signed-off-by:
-
James Hogan authored
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: bad50d79 ("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:
-
Matt Redfearn authored
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:
-
Matt Redfearn authored
The SegCtl registers are standard for MIPSr3..MIPSr5. Add definitions of these registers and use them rather than constants Signed-off-by:
-
Purna Chandra Mandal authored
Update binding example based on new clock binding scheme. [1] Documentation/devicetree/bindings/clock/microchip,pic32.txt Signed-off-by:
Purna Chandra Mandal <purna.mandal@microchip.com> Acked-by:
Rob Herring <robh@kernel.org> Cc: Linus Walleij <linus.walleij@linaro.org> Cc: Kumar Gala <galak@codeaurora.org> Cc: Ian Campbell <ijc+devicetree@hellion.org.uk> Cc: linux-gpio@vger.kernel.org Cc: Mark Rutland <mark.rutland@arm.com> Cc: Alexandre Courbot <gnurou@gmail.com> Cc: linux-kernel@vger.kernel.org Cc: linux-mips@linux-mips.org Cc: devicetree@vger.kernel.org Patchwork: https://patchwork.linux-mips.org/patch/13270/Signed-off-by:
-
Purna Chandra Mandal authored
Update binding example based on new clock binding scheme. [1] Documentation/devicetree/bindings/clock/microchip,pic32.txt Signed-off-by:
-
Purna Chandra Mandal authored
Update binding example based on new clock binding scheme. [1] Documentation/devicetree/bindings/clock/microchip,pic32.txt Signed-off-by:
-
Purna Chandra Mandal authored
Update binding example based on new clock binding scheme. [1] Documentation/devicetree/bindings/clock/microchip,pic32.txt Signed-off-by:
-
Purna Chandra Mandal authored
Update binding example based on new clock binding scheme. [1] Documentation/devicetree/bindings/clock/microchip,pic32.txt Signed-off-by:
-
Purna Chandra Mandal authored
Update binding example based on new clock binding documentation. [1] Documentation/devicetree/bindings/clock/microchip,pic32.txt Signed-off-by:
-
James Hogan authored
Commit 12822570 ("MIPS: Separate XPA CPU feature into LPA and MVH") wasn't fully applied, possibly due to a conflict with commit f270d881 ("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: 12822570 ("MIPS: Separate XPA CPU feature into LPA and MVH") Signed-off-by:
-
Paul Burton authored
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:
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:
-
Paul Burton authored
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 authored
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:
-
- 17 May, 2016 7 commits
-
-
Purna Chandra Mandal authored
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:
-
Felix Fietkau authored
ath79_ddr_pci_win_base has the type void __iomem *, so register offsets need to be a multiple of 4. Cc: Alban Bedel <albeu@free.fr> Fixes: 24b0e3e8 ("MIPS: ath79: Improve the DDR controller interface") Signed-off-by:
Felix Fietkau <nbd@nbd.name> Cc: sergei.shtylyov@cogentembedded.com Cc: linux-mips@linux-mips.org Patchwork: https://patchwork.linux-mips.org/patch/13258/Signed-off-by:
-
Felix Fietkau authored
AR913x, AR724x and AR933x are the only SoCs where the ath79_ddr_wb_flush_base starts at 0x7c, all newer SoCs use 0x9c Invert the logic to make the code compatible with AR95xx Signed-off-by:
-
James Hogan authored
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: 7eb91118 ("MIPS: Add guest CP0 accessors") Signed-off-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:
-
James Hogan authored
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: 4e88a862 ("MIPS: Add cases for CPU_I6400") Signed-off-by:
-
Maciej W. Rozycki authored
Fix a modular `declance' regression caused by LMO commit bb46bf30d13f ("DECstation SCSI driver clean-ups.") Signed-off-by:Maciej W. Rozycki <macro@linux-mips.org> Cc: linux-mips@linux-mips.org Patchwork: https://patchwork.linux-mips.org/patch/13256/Signed-off-by:
-
Maciej W. Rozycki authored
Fix a build regression from commit c9017757 ("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:
-
- 13 May, 2016 15 commits
-
-
Tony Wu authored
Fix mips_cm_lock_other compilation error when MIPS_CM is not selected. This was introduced in commit 23d5de8e (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:
-
James Hogan authored
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:
-
Maarten ter Huurne authored
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:
-
Maarten ter Huurne authored
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 authored
AVT2 was a prototype board of which about 5 were made, none of which are in use anymore. Signed-off-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:
-
James Hartley authored
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:
-
Florian Fainelli authored
The CPU actually runs at 1405Mhz which gives us a 175625000 Hz MIPS timer frequency (CPU frequency / 8). Fixes: e4c7d009 ("MIPS: BMIPS: Add BCM7435 dtsi") Signed-off-by:
Florian Fainelli <f.fainelli@gmail.com> Cc: linux-mips@linux-mips.org Cc: john@phrozen.org Cc: cernekee@gmail.com Cc: jaedon.shin@gmail.com Patchwork: https://patchwork.linux-mips.org/patch/13132/Signed-off-by:
-
Sashka Nochkin authored
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:
-
Paul Burton authored
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:Michal Toman <michal.toman@imgtec.com> Fixes: bf82cb30 ("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:
-
James Hogan authored
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 authored
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 authored
The sampling of the GIC counter on Malta after observing a rising edge of the RTC update flag differs slightly between the first and second sample, with the first sample also calling gic_start_count(). The two samples should really be taken as similarly as possible to get the most accurate figure, so move the gic_start_count() call before detecting the rising edge. Signed-off-by:
-
Paul Burton authored
Commit 9791554b ("MIPS,prctl: add PR_[GS]ET_FP_MODE prctl options for MIPS") added support for the PR_SET_FP_MODE prctl, which allows a userland program to modify its FP mode at runtime. This is most notably required if dynamic linking leads to the FP mode requirement changing at runtime from that indicated in the initial executable's ELF header. In order to avoid overhead in the general FP context restore code, it aimed to have threads in the process become unable to enable the FPU during a mode switch & have the thread calling the prctl syscall wait for all other threads in the process to be context switched at least once. Once that happens we can know that no thread in the process whose mode will be switched has live FP context, and it's safe to perform the mode switch. However in the (rare) case of modeswitches occurring in multithreaded programs this can lead to indeterminate delays for the thread invoking the prctl syscall, and the code monitoring for those context switches was woefully inadequate for all but the simplest cases. Fix this by broadcasting an IPI if other CPUs may have live FP context for an affected thread, with a handler causing those CPUs to relinquish their FPU ownership. Threads will then be allowed to continue running but will stall on the wait_on_atomic_t in enable_restore_fp_context if they attempt to use FP again whilst the mode switch is still in progress. The end result is less fragile poking at scheduler context switch counts & a more expedient completion of the mode switch. Signed-off-by:
-
Paul Burton authored
Whilst a PR_SET_FP_MODE prctl is performed there are decisions made based upon whether the task is executing on the current CPU. This may change if we're preempted, so disable preemption to avoid such changes for the lifetime of the mode switch. Signed-off-by:
Aurelien Jarno <aurelien@aurel32.net> Cc: Adam Buchbinder <adam.buchbinder@gmail.com> Cc: James Hogan <james.hogan@imgtec.com> Cc: stable <stable@vger.kernel.org> # v4.0+ Cc: linux-mips@linux-mips.org Cc: linux-kernel@vger.kernel.org Patchwork: https://patchwork.linux-mips.org/patch/13144/Signed-off-by:
-
Paul Burton authored
If an address error exception occurs for a LDXC1 or SDXC1 instruction, within the cop1x opcode space, allow it to be passed through to the FPU emulator rather than resulting in a SIGILL. This causes LDXC1 & SDXC1 to be handled in a manner consistent with the more common LDC1 & SDC1 instructions. Signed-off-by:
-
