- 11 Nov, 2015 36 commits
-
-
Bartlomiej Zolnierkiewicz authored
IDE subsystem has been deprecated since 2009 and the majority (if not all) of Linux distributions have switched to use libata for ATA support exclusively. However there are still some users (mostly old or/and embedded non-x86 systems) that have not converted from using IDE subsystem to libata PATA drivers. This doesn't seem to be good thing in the long-term for Linux as while there is less and less PATA systems left in use: * testing efforts are divided between two subsystems * having duplicate drivers for same hardware confuses users This patch converts mpc30x_defconfig to use libata PATA drivers. PS This platform still uses "ide0=base[,ctl[,irq]]" hack in its defconfig. The hack itself has been removed in 2008 and this platform should be converted to using PATA platform host driver (pata_platform) instead. Signed-off-by:
Bartlomiej Zolnierkiewicz <b.zolnierkie@samsung.com> Cc: linux-mips@linux-mips.org Cc: linux-ide@vger.kernel.org Cc: linux-kernel@vger.kernel.org Patchwork: https://patchwork.linux-mips.org/patch/11141/Signed-off-by:
Ralf Baechle <ralf@linux-mips.org>
-
Bartlomiej Zolnierkiewicz authored
IDE subsystem has been deprecated since 2009 and the majority (if not all) of Linux distributions have switched to use libata for ATA support exclusively. However there are still some users (mostly old or/and embedded non-x86 systems) that have not converted from using IDE subsystem to libata PATA drivers. This doesn't seem to be good thing in the long-term for Linux as while there is less and less PATA systems left in use: * testing efforts are divided between two subsystems * having duplicate drivers for same hardware confuses users This patch converts maltaup_xpa_defconfig to use libata PATA drivers (tc86c001 IDE host driver has no corresponding libata driver yet so it is not converted). Signed-off-by:
-
Bartlomiej Zolnierkiewicz authored
IDE subsystem has been deprecated since 2009 and the majority (if not all) of Linux distributions have switched to use libata for ATA support exclusively. However there are still some users (mostly old or/and embedded non-x86 systems) that have not converted from using IDE subsystem to libata PATA drivers. This doesn't seem to be good thing in the long-term for Linux as while there is less and less PATA systems left in use: * testing efforts are divided between two subsystems * having duplicate drivers for same hardware confuses users This patch converts maltaup_defconfig to use libata PATA drivers. Signed-off-by:
-
Bartlomiej Zolnierkiewicz authored
IDE subsystem has been deprecated since 2009 and the majority (if not all) of Linux distributions have switched to use libata for ATA support exclusively. However there are still some users (mostly old or/and embedded non-x86 systems) that have not converted from using IDE subsystem to libata PATA drivers. This doesn't seem to be good thing in the long-term for Linux as while there is less and less PATA systems left in use: * testing efforts are divided between two subsystems * having duplicate drivers for same hardware confuses users This patch converts maltasmvp_eva_defconfig to use libata PATA drivers. Signed-off-by:
-
Bartlomiej Zolnierkiewicz authored
IDE subsystem has been deprecated since 2009 and the majority (if not all) of Linux distributions have switched to use libata for ATA support exclusively. However there are still some users (mostly old or/and embedded non-x86 systems) that have not converted from using IDE subsystem to libata PATA drivers. This doesn't seem to be good thing in the long-term for Linux as while there is less and less PATA systems left in use: * testing efforts are divided between two subsystems * having duplicate drivers for same hardware confuses users This patch converts maltaaprp_defconfig to use libata PATA drivers. Signed-off-by:
-
Bartlomiej Zolnierkiewicz authored
IDE subsystem has been deprecated since 2009 and the majority (if not all) of Linux distributions have switched to use libata for ATA support exclusively. However there are still some users (mostly old or/and embedded non-x86 systems) that have not converted from using IDE subsystem to libata PATA drivers. This doesn't seem to be good thing in the long-term for Linux as while there is less and less PATA systems left in use: * testing efforts are divided between two subsystems * having duplicate drivers for same hardware confuses users This patch converts malta_qemu_32r6_defconfig to use libata PATA drivers. Signed-off-by:
-
Bartlomiej Zolnierkiewicz authored
IDE subsystem has been deprecated since 2009 and the majority (if not all) of Linux distributions have switched to use libata for ATA support exclusively. However there are still some users (mostly old or/and embedded non-x86 systems) that have not converted from using IDE subsystem to libata PATA drivers. This doesn't seem to be good thing in the long-term for Linux as while there is less and less PATA systems left in use: * testing efforts are divided between two subsystems * having duplicate drivers for same hardware confuses users This patch converts malta_kvm_guest_defconfig to use libata PATA drivers (tc86c001 IDE host driver has no corresponding libata driver yet so it is not converted). Signed-off-by:
-
Bartlomiej Zolnierkiewicz authored
IDE subsystem has been deprecated since 2009 and the majority (if not all) of Linux distributions have switched to use libata for ATA support exclusively. However there are still some users (mostly old or/and embedded non-x86 systems) that have not converted from using IDE subsystem to libata PATA drivers. This doesn't seem to be good thing in the long-term for Linux as while there is less and less PATA systems left in use: * testing efforts are divided between two subsystems * having duplicate drivers for same hardware confuses users This patch converts malta_kvm_defconfig to use libata PATA drivers (tc86c001 IDE host driver has no corresponding libata driver yet so it is not converted). Signed-off-by:
-
Bartlomiej Zolnierkiewicz authored
IDE subsystem has been deprecated since 2009 and the majority (if not all) of Linux distributions have switched to use libata for ATA support exclusively. However there are still some users (mostly old or/and embedded non-x86 systems) that have not converted from using IDE subsystem to libata PATA drivers. This doesn't seem to be good thing in the long-term for Linux as while there is less and less PATA systems left in use: * testing efforts are divided between two subsystems * having duplicate drivers for same hardware confuses users This patch converts malta_defconfig to use libata PATA drivers. Signed-off-by:
-
Bartlomiej Zolnierkiewicz authored
IDE subsystem has been deprecated since 2009 and the majority (if not all) of Linux distributions have switched to use libata for ATA support exclusively. However there are still some users (mostly old or/and embedded non-x86 systems) that have not converted from using IDE subsystem to libata PATA drivers. This doesn't seem to be good thing in the long-term for Linux as while there is less and less PATA systems left in use: * testing efforts are divided between two subsystems * having duplicate drivers for same hardware confuses users This patch converts lemote2f_defconfig to use libata PATA drivers. PS This platform uses CS5536 chipset which (due to historical reasons) has basic support in AMD/nVidia PATA host driver and full support in a newer CS5536 PATA one (pata_cs5536). Thus most likely this platform should switch to using the latter host driver. Signed-off-by:
-
Bartlomiej Zolnierkiewicz authored
IDE subsystem has been deprecated since 2009 and the majority (if not all) of Linux distributions have switched to use libata for ATA support exclusively. However there are still some users (mostly old or/and embedded non-x86 systems) that have not converted from using IDE subsystem to libata PATA drivers. This doesn't seem to be good thing in the long-term for Linux as while there is less and less PATA systems left in use: * testing efforts are divided between two subsystems * having duplicate drivers for same hardware confuses users This patch converts lasat_defconfig to use libata PATA drivers. Signed-off-by:
-
Bartlomiej Zolnierkiewicz authored
IDE subsystem has been deprecated since 2009 and the majority (if not all) of Linux distributions have switched to use libata for ATA support exclusively. However there are still some users (mostly old or/and embedded non-x86 systems) that have not converted from using IDE subsystem to libata PATA drivers. This doesn't seem to be good thing in the long-term for Linux as while there is less and less PATA systems left in use: * testing efforts are divided between two subsystems * having duplicate drivers for same hardware confuses users This patch converts fuloong2e_defconfig to use libata PATA drivers. Signed-off-by:
-
Bartlomiej Zolnierkiewicz authored
IDE subsystem has been deprecated since 2009 and the majority (if not all) of Linux distributions have switched to use libata for ATA support exclusively. However there are still some users (mostly old or/and embedded non-x86 systems) that have not converted from using IDE subsystem to libata PATA drivers. This doesn't seem to be good thing in the long-term for Linux as while there is less and less PATA systems left in use: * testing efforts are divided between two subsystems * having duplicate drivers for same hardware confuses users This patch converts e55_defconfig to use libata PATA drivers. PS This platform still uses "ide0=base[,ctl[,irq]]" hack in its defconfig. The hack itself has been removed in 2008 and this platform should be converted to using PATA platform host driver (pata_platform) instead. Cc: Yoichi Yuasa <yoichi_yuasa@tripeaks.co.jp> Signed-off-by:
-
Bartlomiej Zolnierkiewicz authored
IDE subsystem has been deprecated since 2009 and the majority (if not all) of Linux distributions have switched to use libata for ATA support exclusively. However there are still some users (mostly old or/and embedded non-x86 systems) that have not converted from using IDE subsystem to libata PATA drivers. This doesn't seem to be good thing in the long-term for Linux as while there is less and less PATA systems left in use: * testing efforts are divided between two subsystems * having duplicate drivers for same hardware confuses users This patch converts capcella_defconfig to use libata PATA drivers. Signed-off-by:
-
Bartlomiej Zolnierkiewicz authored
IDE subsystem has been deprecated since 2009 and the majority (if not all) of Linux distributions have switched to use libata for ATA support exclusively. However there are still some users (mostly old or/and embedded non-x86 systems) that have not converted from using IDE subsystem to libata PATA drivers. This doesn't seem to be good thing in the long-term for Linux as while there is less and less PATA systems left in use: * testing efforts are divided between two subsystems * having duplicate drivers for same hardware confuses users This patch converts bigsur_defconfig to use libata PATA drivers (tc86c001 IDE host driver has no corresponding libata driver yet so it is not converted). Signed-off-by:
-
Paul Burton authored
Extend the existing support for Hardware Table Walking (HTW) to MIPS64 systems by supporting PMDs & setting the pointer size bit in PWSize, then ceasing to blacklist HTW on MIPS64 systems. Signed-off-by:
Paul Burton <paul.burton@imgtec.com> Cc: linux-mips@linux-mips.org Cc: Steven J. Hill <Steven.Hill@imgtec.com> Cc: Joshua Kinard <kumba@gentoo.org> Cc: Leonid Yegoshin <Leonid.Yegoshin@imgtec.com> Cc: Maciej W. Rozycki <macro@linux-mips.org> Cc: Paul Gortmaker <paul.gortmaker@windriver.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/11224/Signed-off-by:
-
Paul Burton authored
If we fail to register any real SMP implementations, fall back to registering the dummy UP implementation. Otherwise when we build an SMP kernel & run it on a system where the SMP implementations fail to probe (eg. QEMU) the kernel will perform a NULL dereference attempting to call mp_ops->smp_setup() from plat_smp_setup(). Notably this fixes booting kernels with CPS SMP enabled on QEMU, which doesn't currently implement the CM, CPC or GIC. Signed-off-by:
-
Paul Burton authored
Move memory configuration to be performed via device tree for the Malta board. This moves more Malta specific code to malta-dtshim.c, leaving the rest of the mti-malta code a little more board-agnostic. This will be useful to share more code between boards, with the device tree providing the board specifics as intended. Since we can't rely upon Malta boards running a bootloader capable of handling devictrees & filling in the required information, a piece of shim code (malta_dt_shim) is added to consume the (e)memsize variables provided as part of the bootloader environment (or on the kernel command line) then generate the DT memory node using the provided values. Signed-off-by:
-
Paul Burton authored
The fw_getmdesc function & fw_memblock_t abstraction is only used by Malta, and so far as I can tell serves no purpose beyond making the code less clear than it could be. Remove the useless level of abstraction. Signed-off-by:
-
Paul Burton authored
Split the obj-y entries to their own lines such that it's easier to see what's going on when adding or removing entries. Signed-off-by:
-
Paul Burton authored
Commit a68d09a1 ("MIPS: Don't use RI/XI with 32-bit kernels on 64-bit CPUs") prevented use of RIXI on MIPS64 systems, stating that the "TLB handlers cannot handle this case". What they actually couldn't handle was cases where there were less fill bits in the Entry{Lo,Hi} registers than bits used by software in PTEs. The handlers can now deal with this case, so enable RIXI for MIPS32 kernels on MIPS64 systems. Note that beyond the obvious benefits provided by having RIXI on such systems, this is required for systems implementing MIPSr6 where RIXI cannot be disabled. This reverts commit a68d09a1 ("MIPS: Don't use RI/XI with 32-bit kernels on 64-bit CPUs"). Signed-off-by:
-
Paul Burton authored
Commit 748e787e ("MIPS: Optimize TLB refill for RI/XI configurations.") stopped explicitly clearing the bits used by software in PTEs by making use of a rotate instruction that rotates them into the fill bits of the Entry{Lo,Hi} register. This can only work if there are actually enough fill bits in the register to cover the software maintained bits, otherwise we end up writing those bits into the upper bits of the PFN or PFNX field of the Entry{Lo,Hi} register. Fix this by detecting the number of fill bits present in the Entry{Lo,Hi} registers & explicitly clearing the software bits where necessary. Signed-off-by:
-
Paul Burton authored
Tidy up the definition of the EntryLo RI & XI bits using BITS_PER_LONG rather than #ifdef'ing on CONFIG_64BIT, and add a definition for the offset to the PFN field for use by a later patch. Signed-off-by:
-
Paul Burton authored
The code in build_update_entries for 64 bit physical addresses on a MIPS64 CPU and 32 bit physical addresses on a MIPS32 CPU is now identical, with the exception of r4k bug workaround in the latter which would simply not apply to the former. Remove the duplication and some Signed-off-by:
-
Paul Burton authored
The cpu_has_rixi cases in build_update_entries are now identical to the non-RIXI cases with the one exception of the r45k_bvahwbug case which is hardcoded as never happening anyway & presumably was either missed from the RIXI path or would never happen on a CPU with RIXI support. Remove the redundant checks & duplication. Signed-off-by:
-
Paul Burton authored
Make use of build_convert_pte_to_entrylo in the RIXI cases within build_update_entries rather than open-coding it 4 times. Signed-off-by:
-
Paul Burton authored
Prior to release 6 of the MIPS architecture it has been implementation dependent whether masked interrupts cause a wait instruction to return, so the kernel has effectively had to maintain a whitelist of cores upon which it is safe to use the r4k_wait_irqoff cpu_wait implementation. With MIPSr6 this is no longer implementation dependent and r4k_wait_irqoff can always be used. Remove the existing I6400 case which will no longer ever be hit, and was incorrect anyway since I6400 & r6 in general doesn't have the WII bit. Signed-off-by:
-
Paul Burton authored
Ensure the update to which core the core-other GCR regions reflect has taken place before any core-other GCRs are accessed by placing a memory barrier (sync instruction) between the write to the core-other registers and any such GCR accesses. Signed-off-by:
-
Paul Burton authored
Document that CPC core-other accesses must take place within the bounds of the CM lock, and begin using the CM lock functions where we access the GCRs of other cores. This is required because with CM3 the CPC began using GCR_CL_OTHER instead of CPC_CL_OTHER. Signed-off-by:
-
Paul Burton authored
Introduce mips_cm_lock_other & mips_cm_unlock_other, mirroring the existing CPC equivalents, in order to lock access from the current core to another via the core-other GCR region. This hasn't been required in the past but with CM3 the CPC starts using GCR_CL_OTHER rather than CPC_CL_OTHER and this will be required for safety. [ralf@linux-mips.org: Fix merge conflict.] Signed-off-by:
-
Paul Burton authored
The PVPE (or PVP in >= CM3) field is 10 bits wide, but the mask previously only covered the bottom 9 bits. Extend the mask to cover all 10 bits of the field. Signed-off-by:
-
Paul Burton authored
When debugging core bringup it is useful to see the state of the CPC sequencer, so output that value if the core hasn't started within a reasonable amount of time (1 second). This avoids simply appearing to the user to hang if a secondary core fails to start. Signed-off-by:
-
Paul Burton authored
The Config1 register is architecturally defined as required, and is thus present in all systems which may make use of cps-vec.S. Skip the check for its presence via the Config.M bit. Signed-off-by:
-
Paul Burton authored
Rather than patching the start of mips_cps_core_entry to provide the base address of the CM GCRs, simply read that base address from the cop0 CMGCRBase register, converting from the physical address to an uncached virtual address. Signed-off-by:
-
Paul Burton authored
Provide support for outputting early debug information, in the form of various register values should an exception occur, during the early bringup of secondary cores. This code requires an ns16550-compatible UART accessible from the secondary core, and is written in assembly due to the environment in which such early exceptions occur where way may not have a stack, be coherent or even have initialised caches. [ralf@linux-mips.org: Fix merge conflict.] Signed-off-by:
-
James Hogan authored
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:
James 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:
-
- 26 Oct, 2015 4 commits
-
-
Paul Burton authored
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:
-
Paul Burton authored
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:
-
Paul Burton authored
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:
-
Paul Burton authored
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:
-
