- 03 Sep, 2015 29 commits
-
-
Viresh Kumar authored
Migrate jazz driver to the new 'set-state' interface provided by clockevents core, the earlier 'set-mode' interface is marked obsolete now. This also enables us to implement callbacks for new states of clockevent devices, for example: ONESHOT_STOPPED. We weren't doing anything in the ->set_mode() callback. So, this patch doesn't provide any set-state callbacks. Signed-off-by:
Viresh Kumar <viresh.kumar@linaro.org> Cc: Daniel Lezcano <daniel.lezcano@linaro.org> Cc: linux-mips@linux-mips.org Cc: linaro-kernel@lists.linaro.org Cc: Thomas Gleixner <tglx@linutronix.de> Patchwork: https://patchwork.linux-mips.org/patch/10600/Signed-off-by:
Ralf Baechle <ralf@linux-mips.org>
-
Viresh Kumar authored
Migrate alchemy driver to the new 'set-state' interface provided by clockevents core, the earlier 'set-mode' interface is marked obsolete now. This also enables us to implement callbacks for new states of clockevent devices, for example: ONESHOT_STOPPED. We weren't doing anything in the ->set_mode() callback. So, this patch doesn't provide any set-state callbacks. Signed-off-by:
-
Ralf Baechle authored
Signed-off-by: -
Ralf Baechle authored
Signed-off-by: -
Ralf Baechle authored
Signed-off-by: -
Ralf Baechle authored
Signed-off-by: -
Ralf Baechle authored
Signed-off-by: -
James Hogan authored
The generic field definitions (i.e. present before MIPS32/MIPS64) in mipsregs.h are conventionally not prefixed with MIPS_, so rename the recently added MIPS_ENTRYLO_* definitions for the G, V, D, and C fields to ENTRYLO_*. Also rearrange to put the EntryLo and EntryHi definitions in the right place in the file. Fixes: 8ab6abcb ("MIPS: mipsregs.h: Add EntryLo bit definitions") Reported-by:
Maciej W. Rozycki <macro@linux-mips.org> Signed-off-by:
James Hogan <james.hogan@imgtec.com> Cc: Maciej W. Rozycki <macro@linux-mips.org> Cc: linux-mips@linux-mips.org Patchwork: https://patchwork.linux-mips.org/patch/10725/Signed-off-by:
-
James Hogan authored
The FrameMask register is relevant to the TLB so it should be dumped by dump_tlb_regs(), however it is only present in certain cores (r10000, r12000, r14000, r16000). Add dumping of it, conditional upon current_cpu_type(). Suggested-by:
Joshua Kinard <kumba@gentoo.org> Suggested-by:
-
James Hogan authored
The PageGrain register may not exist if certain architectural features aren't present, therefore only print out its value when dumping the TLB registers if it is expected to contain fields relevant to the TLB. Fixes: d1e9a4f5 ("MIPS: Add SysRq operation to dump TLBs on all CPUs") Reported-by:
-
James Hogan authored
Probe Config3 for small page support. This will be useful to give clues as to whether the PageGrain register exists. Signed-off-by:
-
James Hogan authored
The TLB registers are dumped in a couble of places: - sysrq_tlbdump_single() - when dumping TLB state. - do_mcheck() - in response to a machine check error. The main TLB registers also differ between r3k and r4k, but r4k appears to be assumed. Refactor this code into a dump_tlb_regs() function, implemented for both r3k and r4k, and used by both of the above functions. Fixes: d1e9a4f5 ("MIPS: Add SysRq operation to dump TLBs on all CPUs") Suggested-by:
-
James Hogan authored
Commit d1e9a4f5 ("MIPS: Add SysRq operation to dump TLBs on all CPUs") added the 'x' sysrq key for dumping MIPS TLB entries, but didn't document it in Documentation/sysrq.txt. Add mention of the MIPS use of the 'x' SysRq key. Reported-by:
Jonathan Corbet <corbet@lwn.net> Cc: Maciej W. Rozycki <macro@linux-mips.org> Cc: linux-mips@linux-mips.org Cc: linux-doc@vger.kernel.org Patchwork: https://patchwork.linux-mips.org/patch/10720/Signed-off-by:
-
Markos Chandras authored
Commit c8a34581 ("MIPS: Emulate the BC1{EQ,NE}Z FPU instructions") added support for emulating the new R6 BC1{EQ,NE}Z branches but it missed the case where the instruction that caused the exception was not on a DS. Signed-off-by:
Markos Chandras <markos.chandras@imgtec.com> Fixes: c8a34581 ("MIPS: Emulate the BC1{EQ,NE}Z FPU instructions") Cc: <stable@vger.kernel.org> # 4.0+ Cc: linux-mips@linux-mips.org Patchwork: https://patchwork.linux-mips.org/patch/10738/Signed-off-by:
-
Markos Chandras authored
The mfhc/mthc instructions are supported on MIPS R6 so emulate them if needed. Signed-off-by:
-
Markos Chandras authored
Fix indentation for the final 'else' blocks. Signed-off-by:
-
Markos Chandras authored
The double format (d_fmt) case uses an opening bracket which then closes at the end of the word format (w_fmt). This can be rather confusing so add the closing bracket at the end of the d_fmt case and use another one for the w_fmt one. Signed-off-by:
-
Markos Chandras authored
The MIPS R6 ISA support has been part of mainline since v4.0 and it should be in a good shape nowadays so it is not an experimental feature anymore. Signed-off-by:
-
Ralf Baechle authored
These are bitfields and treating them as signed values doesn't make any sense. Signed-off-by:
Chris Packham <judge.packham@gmail.com>
-
Chris Packham authored
Update __read_32bit_c0_register() and __read_32bit_c0_ctrl_register() to use "unsigned int res;" instead of "int res;". There is little reason to treat these register values as signed. They are either counters (which by definition are unsigned) or are made up of various bit fields to be interpreted as per the CPU datasheet. This has come up via u-boot[1] which sync's asm/mipsregs.h with the kernel. In u-boots case the value read from read_c0_count() is assigned to an unsigned long [2] which triggers a sign extension and causes a bug. U-boot should probably be more explicit about the types used for the timer_read_counter() API but that aside is there any reason to treat these values as signed integers? A quick grep around the arch/mips makes me thing that there may be some bugs lurking when read_c0_count() starts to yield a negative value but I haven't really explored any of them. [1] - http://lists.denx.de/pipermail/u-boot/2015-July/219086.html [2] - http://git.denx.de/?p=u-boot.git;a=blob;f=arch/mips/cpu/time.c#l11Signed-off-by:
-
Paul Burton authored
The default implementation of platform_maar_init is sufficient for Malta boards where we want to allow speculation in the regions of memory corresponding to DDR & disallow it elsewhere. Drop the custom implementation such that the default is used, reducing the duplication of information provided by the Malta platform code. Signed-off-by:
Paul 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/10677/Signed-off-by:
-
Paul Burton authored
Introduce a default weak implementation of platform_maar_init which makes use of the data that platforms already provide to the bootmem allocator. This should hopefully cover the most common configurations, reduce the duplication of information provided by platforms & leaves platforms with the option of providing a custom implementation if required. Signed-off-by:
-
Leonid Yegoshin authored
The MSA architecture specification allows for hardware to not implement unaligned vector memory accesses in some or all cases. A typical example of this is the I6400 core which does not implement unaligned vector memory access when the memory crosses a page boundary. The architecture also requires that such memory accesses complete successfully as far as userland is concerned, so the kernel is required to emulate them. This patch implements support for emulating unaligned MSA ld & st instructions by copying between the user memory & the tasks FP context in struct thread_struct, updating hardware registers from there as appropriate in order to avoid saving & restoring the entire vector context for each unaligned memory access. Tested both using an I6400 CPU and with a QEMU build hacked to produce AdEL exceptions for unaligned vector memory accesses. [paul.burton@imgtec.com: - Remove #ifdef's - Move msa_op into enum major_op rather than #define - Replace msa_{to,from}_wd with {read,write}_msa_wr_{b,h,w,l} and the format-agnostic wrappers, removing the custom endian mangling for big endian systems. - Restructure the msa_op case in emulate_load_store_insn to share more code between the load & store cases. - Avoid the need for a temporary union fpureg on the stack by simply reusing the already suitably aligned context in struct thread_struct. - Use sizeof(*fpr) rather than hardcoding 16 as the size for user memory checks & copies. - Stop recalculating the address of the unaligned vector memory access and rely upon the value read from BadVAddr as we do for other unaligned memory access instructions. - Drop the now unused val8 & val16 fields in union fpureg. - Rewrite commit message. - General formatting cleanups.] Signed-off-by: -
Paul Burton authored
Introduce accessor functions allowing the kernel to access arbitrary vector registers using an arbitrary data format. The accessors are implemented in assembly, using macros to avoid massive duplication, in order to make use of the existing support for MSA with & without toolchain support. The accessors will be used in a later patch. Signed-off-by:
-
Leonid Yegoshin authored
Declare a struct describing the MSA MI10 instruction format used for ld & st instructions, for use by subsequent patches. Signed-off-by:
-
Bjorn Helgaas authored
"__weak" is defined in include/linux/compiler-gcc.h. We shouldn't need an arch-specific definition. Remove the "__weak" definition from arch/mips/include/asm/linkage.h. Signed-off-by:
Bjorn Helgaas <bhelgaas@google.com> Reviewed-by:
-
Bjorn Helgaas authored
Weak header file declarations are error-prone because they make every definition weak, and the linker chooses one based on link order (see 10629d71 ("PCI: Remove __weak annotation from pcibios_get_phb_of_node decl")). mips_cdmm_phys_base() is defined only in arch/mips/mti-malta/malta-memory.c so there's no problem with multiple definitions. But it works better to have a weak default implementation and allow a strong function to override it. Then we don't have to test whether a definition is present, and if there are ever multiple strong definitions, we get a link error instead of calling a random definition. Add a weak mips_cdmm_phys_base() definition and remove the weak annotation from the declaration in arch/mips/include/asm/cdmm.h. Signed-off-by:
-
Bjorn Helgaas authored
Weak header file declarations are error-prone because they make every definition weak, and the linker chooses one based on link order (see 10629d71 ("PCI: Remove __weak annotation from pcibios_get_phb_of_node decl")). The most elegant solution is to have a weak default implementation and allow a strong function to override it. Then we don't have to test whether a definition is present, and if there are ever multiple strong definitions, we get a link error instead of calling a random definition. Add a weak get_c0_fdc_int() definition with the default code and remove the weak annotation from the declaration. Signed-off-by:
-
Bjorn Helgaas authored
Weak header file declarations are error-prone because they make every definition weak, and the linker chooses one based on link order (see 10629d71 ("PCI: Remove __weak annotation from pcibios_get_phb_of_node decl")). get_c0_compare_int() is defined in several files. Each definition is weak, so I assume Kconfig prevents two or more from being included. The caller contains default code used when get_c0_compare_int() isn't defined at all. Add a weak get_c0_compare_int() definition with the default code and remove the weak annotation from the declaration. Then the platform implementations will be strong and will override the weak default. If multiple platforms are ever configured in, we'll get a link error instead of calling a random platform's implementation. Signed-off-by:
-
- 26 Aug, 2015 11 commits
-
-
Bjorn Helgaas authored
Weak header file declarations are error-prone because they make every definition weak, and the linker chooses one based on link order (see 10629d71 ("PCI: Remove __weak annotation from pcibios_get_phb_of_node decl")). That's not a problem for vpe_run() because Kconfig ensures there's never more than one definition: - vpe_run() is defined in arch/mips/kernel/vpe-mt.c if CONFIG_MIPS_VPE_LOADER_MT=y - vpe_run() is defined in arch/mips/mti-malta/malta-amon.c if CONFIG_MIPS_CMP=y - CONFIG_MIPS_VPE_LOADER_MT cannot be set if CONFIG_MIPS_CMP=y But it's simpler to verify correctness if we remove "weak" from the picture and test the config symbols directly. Remove "weak" from the vpe_run() declaration and use #if to test whether a definition should be present. Signed-off-by:
-
Bjorn Helgaas authored
vpe_run() is a weak symbol. If there's no definition of it, its value is zero. If vpe_run is zero, return failure early. We're going to fail anyway, so there's no point in getting a VPE and attempting to load it. Signed-off-by:
-
Bjorn Helgaas authored
Weak header file declarations are error-prone because they make every definition weak, and the linker chooses one based on link order (see 10629d71 ("PCI: Remove __weak annotation from pcibios_get_phb_of_node decl")). platform_maar_init() is defined in: - arch/mips/mm/init.c (where it is marked "weak") - arch/mips/mti-malta/malta-memory.c (without annotation) The "weak" attribute on the platform_maar_init() extern declaration applies to the platform-specific definition in arch/mips/mti-malta/malta-memory.c, so both definitions are weak, and which one we get depends on link order. Remove the "weak" attribute from the declaration. That makes the malta definition strong, so it will always be preferred if it is present. Signed-off-by:
-
Bjorn Helgaas authored
There's only one implementation of mips_cpc_phys_base(), and it's only used within the same file, so it doesn't need to be weak, and it doesn't need an extern declaration. Remove the extern mips_cpc_phys_base() declaration and make it static. [ralf@linux-mips.org: Fixed conflict.] Signed-off-by:
-
Paul Burton authored
The debug.h header provided some MIPS-specific debug macros, which are no longer used at all. Remove them. Signed-off-by:
-
Paul Burton authored
The db_assert call checks whether the bus_num pointer is non-NULL, but does so after said pointer has been dereferenced by the assignment on the previous line. Thus the check is pointless & likely to have been optimised out by the compiler anyway. The check_args function is static & only ever called from the local file with bus_num being a pointer to an on-stack variable, so the check seems somewhat overzealous anyway. Simply remove it. Signed-off-by:
-
Thomas Gleixner authored
The irq argument of most interrupt flow handlers is unused or merily used instead of a local variable. The handlers which need the irq argument can retrieve the irq number from the irq descriptor. Search and update was done with coccinelle and the invaluable help of Julia Lawall. Signed-off-by:
Thomas Gleixner <tglx@linutronix.de> Cc: Julia Lawall <Julia.Lawall@lip6.fr> Cc: Jiang Liu <jiang.liu@linux.intel.com> Cc: linux-mips@linux-mips.org Cc: LKML <linux-kernel@vger.kernel.org> Patchwork: https://patchwork.linux-mips.org/patch/10706/Signed-off-by:
-
Thomas Gleixner authored
The irq argument of most interrupt flow handlers is unused or merily used instead of a local variable. The handlers which need the irq argument can retrieve the irq number from the irq descriptor. Search and update was done with coccinelle and the invaluable help of Julia Lawall. Signed-off-by:
-
Thomas Gleixner authored
The gpio interrupt handling of octeon contains a homebrewn flow handler which calls either handle_level_irq or handle_edge_irq depending on the trigger type. Thats an extra conditional and call in the interrupt handling path. The proper way to handle different types and therefor different flows is to update the handler in the irq_set_type() callback. Remove the extra indirection and add the handler update to octeon_irq_ciu_gpio_set_type(). At mapping time it defaults to handle_level_irq which gets updated if the device tree contains a different trigger type. Signed-off-by:
-
Thomas Gleixner authored
The various interrupt flow handlers in ath79 are cascading interrupt handlers. They all have a disable_irq_nosync()/enable_irq() pair around the generic_handle_irq() call. The value of this disable/enable is zero because its a complete noop: disable_irq_nosync() merily increments the disable count without actually masking the interrupt. enable_irq() soleley decrements the disable count without touching the interrupt chip. The interrupt cannot arrive again because the complete call chain runs with interrupts disabled. Remove it. Signed-off-by:
-
Thomas Gleixner authored
bcsr_csc_handler() is a cascading interrupt handler. It has a disable_irq_nosync()/enable_irq() pair around the generic_handle_irq() call. The value of this disable/enable is zero because its a complete noop: disable_irq_nosync() merily increments the disable count without actually masking the interrupt. enable_irq() soleley decrements the disable count without touching the interrupt chip. The interrupt cannot arrive again because the complete call chain runs with interrupts disabled. Remove it. [ralf@linux-mips.org: Fold in followup fix from Thomas Gleixner.] Signed-off-by:
-
