- 03 Sep, 2015 40 commits
-
-
Kamlakant Patel authored
This is needed to enable GPIO framework support for Netlogic XLP platform. Signed-off-by:
Kamlakant Patel <kamlakant.patel@broadcom.com> Signed-off-by:
Jayachandran C <jchandra@broadcom.com> Cc: linux-mips@linux-mips.org Patchwork: https://patchwork.linux-mips.org/patch/10818/Signed-off-by:
Ralf Baechle <ralf@linux-mips.org>
-
Kamlakant Patel authored
Add GPIO entries to the Netlogic XLP device tree files. Signed-off-by:
-
Kamlakant Patel authored
Update mips/netlogic/common/irq.c and mips/pci/msi-xlp.c to use chip_data to store interrupt controller data pointer. It uses handler_data now, and that causes errors when an API (like the GPIO subsystem) tries to use the handler data. Signed-off-by:
-
Alban Bedel authored
Currently CONFIG_ARCH_HAVE_CUSTOM_GPIO_H is defined for all MIPS machines, and each machine type provides its own gpio.h. However only a handful really implement the GPIO API, most just forward everythings to gpiolib. The Alchemy machine is notable as it provides a system to allow implementing the GPIO API at the board level. But it is not used by any board currently supported, so it can also be removed. For most machine types we can just remove the custom gpio.h, as well as the custom wrappers if some exists. Some of the code found in the wrappers must be moved to the respective GPIO driver. A few more fixes are need in some drivers as they rely on linux/gpio.h to provides some machine specific definitions, or used asm/gpio.h instead of linux/gpio.h for the gpio API. Signed-off-by:
Alban Bedel <albeu@free.fr> Reviewed-by:
Linus Walleij <linus.walleij@linaro.org> Cc: linux-mips@linux-mips.org Cc: Hauke Mehrtens <hauke@hauke-m.de> Cc: Rafał Miłecki <zajec5@gmail.com> Cc: Bartlomiej Zolnierkiewicz <b.zolnierkie@samsung.com> Cc: Tejun Heo <tj@kernel.org> Cc: Alexandre Courbot <gnurou@gmail.com> Cc: Dmitry Torokhov <dmitry.torokhov@gmail.com> Cc: Florian Fainelli <florian@openwrt.org> Cc: Manuel Lauss <manuel.lauss@gmail.com> Cc: Joe Perches <joe@perches.com> Cc: Daniel Walter <dwalter@google.com> Cc: Sergey Ryazanov <ryazanov.s.a@gmail.com> Cc: Huacai Chen <chenhc@lemote.com> Cc: James Hartley <james.hartley@imgtec.com> Cc: Andrew Bresticker <abrestic@chromium.org> Cc: Paul Burton <paul.burton@imgtec.com> Cc: Jiri Kosina <jkosina@suse.cz> Cc: Bjorn Helgaas <bhelgaas@google.com> Cc: Wolfram Sang <wsa@the-dreams.de> Cc: Randy Dunlap <rdunlap@infradead.org> Cc: Varka Bhadram <varkabhadram@gmail.com> Cc: Masanari Iida <standby24x7@gmail.com> Cc: Tomi Valkeinen <tomi.valkeinen@ti.com> Cc: Michael Buesch <m@bues.ch> Cc: abdoulaye berthe <berthe.ab@gmail.com> Cc: linux-kernel@vger.kernel.org Cc: linux-ide@vger.kernel.org Cc: linux-gpio@vger.kernel.org Cc: linux-input@vger.kernel.org Cc: netdev@vger.kernel.org Patchwork: https://patchwork.linux-mips.org/patch/10828/Signed-off-by:
-
Alban Bedel authored
GPIO drivers should be in drivers/gpio Signed-off-by:
-
Alban Bedel authored
To prepare moving the GPIO driver to drivers/gpio remove the platform specific pinmux API. As it is not used by any board, and such functionality should better be implemented using the pinmux subsystem just removing it seems to be the best option. Signed-off-by:
-
Paul Burton authored
On MIPS64 we have spinlocks that are 32b in size and an efficient cmpxchg64 implementation, so we qualify to make use of cmpxchg backed lockrefs. Select the ARCH_USE_CMPXCHG_LOCKREF Kconfig symbol and provide a trivial implementation of arch_spin_value_unlocked to satisfy the lockref code. Using Linus' simple testcase from http://article.gmane.org/gmane.linux.file-systems/77466 on a dual core system with an in-development MIPS64 CPU running on FPGA I see around an 8% gain: Pre-patch: Total loops: 252698 Total loops: 251482 Total loops: 250806 Total loops: 252885 Total loops: 251666 Post-patch: Total loops: 273728 Total loops: 269932 Total loops: 269341 Total loops: 275004 Total loops: 270208 [ralf@linux-mips.org: Fixed conflict.] Signed-off-by:
Paul Burton <paul.burton@imgtec.com> Cc: linux-mips@linux-mips.org Cc: Steven J. Hill <Steven.Hill@imgtec.com> Cc: linux-kernel@vger.kernel.org Cc: Maciej W. Rozycki <macro@codesourcery.com> Cc: Markos Chandras <markos.chandras@imgtec.com> Patchwork: https://patchwork.linux-mips.org/patch/10810/Signed-off-by:
-
Ralf Baechle authored
MIPS was using finish_arch_switch() as a hook to restore and initialize CPU context for all threads, even newly created kernel and user threads. This is however entirely solvable within switch_to() so get rid of finish_arch_switch() which is in the way of scheduler cleanups. Signed-off-by: -
Alex Smith authored
The Ingenic-specific write combining cache attribute was defined based on CONFIG_MACH_JZ4740 and therefore not used on JZ4780. Change this to CONFIG_MACH_INGENIC so that it gets used on all Ingenic platforms. Signed-off-by:
Alex Smith <alex.smith@imgtec.com> Cc: linux-mips@linux-mips.org Patchwork: https://patchwork.linux-mips.org/patch/10769/Signed-off-by:
-
Alex Smith authored
The generic implementation of dma_map_ops.mmap(), dma_common_mmap(), is not correct for non-coherent devices. It expects to be passed a virtual address previously returned by dma_alloc_coherent(), which for a non-coherent device will return a KSEG1 address. It then attempts to convert that virtual address to a physical address using virt_to_page() which will yield an incorrect address. Also, dma_common_mmap() does not handle the DMA_ATTR_WRITE_COMBINE attribute, and therefore dma_mmap_writecombine() will not actually set the appropriate pgprot_t flags for write combining. This patch adds an implementation of dma_map_ops.mmap() that correctly handles KSEG1 addresses, and enables write combining when requested. Signed-off-by:
-
Alex Smith authored
If pgprot_writecombine is not #defined, asm-generic/pgtable.h will try to provide a default implementation by #defining it to pgprot_noncached. However our implementation is an inline function rather than a #define, so it was never actually used because of the #define in generic code. Add "#define pgprot_writecombine pgprot_writecombine" to prevent generic code from re-defining it. Signed-off-by:
-
Paul Burton authored
CONFIG_MIPS_O32_FP64_SUPPORT and CONFIG_CPU_HAS_MSA are in pretty good shape these days, and in much wider use than they once were. Stop referring to them as EXPERIMENTAL. Signed-off-by:
-
Paul Burton authored
If MSA is supported by both the hardware & the kernel then advertise that support to userland via the AT_HWCAP aux vector. Signed-off-by:
-
Paul Burton authored
When running on a CPU implementing the release 6 of the MIPS32 or MIPS64 ISA, advertise that to userland via the appropriate HWCAP bit. Signed-off-by:
-
Paul Burton authored
In order for userland to determine whether various features are safe to use, it will need to know both that the hardware supports those features and that the kernel is recent enough & configured appropriately to support them. For example under the O32 modeless FP proposal the dynamic linker & ifunc resolvers will need this information. The kernel is the only thing in a position to know availability accurately, so the kernel needs to provide the information to userland. This patch introduces the infrastructure to provide the AT_HWCAP aux vector to userland in order to provide that information. It also defines the 2 currently specified flags, which indicate MIPSr6 & MSA support. Signed-off-by:
-
Paul Burton authored
It is desirable for signal handlers to be allowed to make use of MSA, particularly if auto vectorisation is used when compiling a program. The MSA context must therefore be saved & restored before & after invoking the signal handler. Make use of the extended context structs defined in the preceding patch to save MSA context after the sigframe when appropriate. [ralf@linux-mips.org: Fixed conflicts.] Signed-off-by:
-
Paul Burton authored
The context introduced by MSA needs to be saved around signals. However, we can't increase the size of struct sigcontext because that will change the offset of the signal mask in struct sigframe or struct ucontext. This patch instead places the new context immediately after the struct sigframe for traditional signals, or similarly after struct ucontext for RT signals. The layout of struct sigframe & struct ucontext is identical from their sigcontext fields onwards, so the offset from the sigcontext to the extended context will always be the same regardless of the type of signal. Userland will be able to search through the extended context by using the magic values to detect which types of context are present. Any unrecognised context can be skipped over using the size field of struct extcontext. Once the magic value END_EXTCONTEXT_MAGIC is seen it is known that there are no further extended context structures to examine. This approach is somewhat similar to that taken by ARM to save VFP & other context at the end of struct ucontext. Userland can determine whether extended context is present by checking for the USED_EXTCONTEXT bit in the sc_used_math field of struct sigcontext. Whilst this could potentially change the historic semantics of sc_used_math if further extended context which does not imply FP context were to be introduced in the future, I have been unable to find any userland code making use of sc_used_math at all. Using one of the fields described as unused in struct sigcontext was considered, but the kernel does not already write to those fields so there would be no guarantee of the field being clear on older kernels. Other alternatives would be to have userland check the kernel version, or to have a HWCAP bit indicating presence of extended context. However there is a desire to have the context & information required to decode it be self contained such that, for example, debuggers could decode the saved context easily. [ralf@linux-mips.org: Fixed conflict.] Signed-off-by:
-
Paul Burton authored
The sc_used_math field of struct sigcontext & its variants has traditionally been used as a boolean value indicating only whether or not floating point context is saved within the sigcontext. With various supported FP modes & the ability to switch between them this information will no longer be enough to decode the meaning of the data stored in the sc_fpregs fields of struct sigcontext. To make that possible 3 bits are defined within sc_used_math: - Bit 0 (USED_FP) represents whether FP was used, essentially providing the boolean flag which sc_used_math as a whole provided previously. - Bit 1 (USED_FR1) provides the value of the Status.FR bit at the time the FP context was saved. - Bit 2 (USED_HYBRID_FPRS) indicates whether the FP context was saved under the hybrid FPR scheme. Essentially, when set the odd singles are located in bits 63:32 of the preceding even indexed sc_fpregs element. Any userland that tests whether the sc_used_math field is zero or non-zero will continue to function as expected. Having said that, I could not find any userland which uses the sc_used_math field at all. [ralf@linux-mips.org: Fixed rejects.] Signed-off-by: -
Paul Burton authored
These functions are never called & thus dead code. Remove them. Signed-off-by:
-
Paul Burton authored
Make use of the common FP sigcontext code for O32 binaries running on MIPS64 kernels now that it is taking appropriate offsets into struct sigcontext(32) from struct mips_abi. [ralf@linux-mips.org: Fixed reject.] Signed-off-by:
-
Paul Burton authored
When a task uses 32 bit floating point, the odd indexed 32b register values are stored in bits 63:32 of the preceding even indexed 64b FP register field in saved context. Thus there is no point in preserving the odd indexed 64b register fields since they hold no valid context. This patch will cause them to be skipped, as is already done in arch/mips/kernel/signal32.c. [ralf@linux-mips.org: Fixed reject.] Signed-off-by:
-
Paul Burton authored
In preparation for sharing protected_{save,restore}_fp_context with compat ABIs, move the FP usage checks into said functions. This will both enable that code to be shared, and allow for extensions of it in further patches to also be shared. Signed-off-by: -
Paul Burton authored
When saving FP state to struct sigcontext, make use of the offsets provided by struct mips_abi to obtain appropriate addresses for the sc_fpregs & sc_fpc_csr fields of the sigcontext. This is done only for the native struct sigcontext in this patch (ie. for O32 in CONFIG_32BIT kernels or for N64 in CONFIG_64BIT kernels) but is done in preparation for sharing this code with compat ABIs in further patches. Signed-off-by:
-
Paul Burton authored
Add fields to struct mips_abi, which holds information regarding the kernel-userland ABI regarding signals, to specify the offsets to the FP related fields within the appropriate variant of struct sigcontext. Signed-off-by:
-
Paul Burton authored
The protected_{save,restore}_fp_context functions had effectively different implementations for EVA. Simplify & unify the code somewhat such that EVA configurations simply guarantee the FPU-not-owned path through the standard code path. Signed-off-by: -
Viresh Kumar authored
Migrate sni 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. 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/10612/Signed-off-by:
-
Viresh Kumar authored
Migrate sgidriver 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 authored
Migrate ralink 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. Signed-off-by:
-
Viresh Kumar authored
Migrate loongsoon32 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. Signed-off-by:
-
Viresh Kumar authored
Migrate loongson 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. [ralf@linux-mips.org: Folded in Viresh's followon fix.] Signed-off-by:
-
Viresh Kumar authored
Migrate cevt-txx9 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. Signed-off-by:
-
Viresh Kumar authored
Migrate cevt-rsb1250 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. Signed-off-by:
-
Viresh Kumar authored
Migrate cevt-4k 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 authored
Migrate cevt-gt641xx 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. Signed-off-by:
-
Viresh Kumar authored
Migrate cevt-ds1287 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. Signed-off-by:
-
Viresh Kumar authored
Migrate cevt-bcm1480 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. Read operation on R_SCD_TIMER_CFG and R_SCD_TIMER_INIT registers isn't performed now for many modes as there returned values aren't used. Signed-off-by:
-
Viresh Kumar authored
Migrate jz4740 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. Signed-off-by:
-
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 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:
-
