linux.git/arch/mips/kernel/traps.c, branch v3.17 Linux kernel source tree MIPS: disable preemption whilst initialising MSA 2014-08-01T22:06:44+00:00 Paul Burton paul.burton@imgtec.com 2014-07-11T15:44:35+00:00 762a1f4388a22690cd4f848ba858e5f02d4bfc22 Preemption must be disabled throughout the process of enabling the FPU, enabling MSA & initialising the vector registers. Without doing so it is possible to lose the FPU or MSA whilst initialising them causing that initialisation to fail. Signed-off-by: Paul Burton <paul.burton@imgtec.com> Cc: linux-mips@linux-mips.org Patchwork: https://patchwork.linux-mips.org/patch/7307/ Signed-off-by: Ralf Baechle <ralf@linux-mips.org> 
Preemption must be disabled throughout the process of enabling the FPU,
enabling MSA & initialising the vector registers. Without doing so it
is possible to lose the FPU or MSA whilst initialising them causing
that initialisation to fail.

Signed-off-by: Paul Burton <paul.burton@imgtec.com>
Cc: linux-mips@linux-mips.org
Patchwork: https://patchwork.linux-mips.org/patch/7307/
Signed-off-by: Ralf Baechle <ralf@linux-mips.org>
MIPS: fix MSA context for tasks which don't use FP first 2014-08-01T22:06:44+00:00 Paul Burton paul.burton@imgtec.com 2014-07-31T13:53:16+00:00 732c0c3c70869af53654db2b56dffdd8d4df5211 If a task does not execute scalar FP instructions prior to using MSA then the flags indicating that the task has live MSA context were not being set. The upper 64b of each vector register would then be lost upon the tasks first context switch after using MSA. Signed-off-by: Paul Burton <paul.burton@imgtec.com> Cc: linux-mips@linux-mips.org Patchwork: https://patchwork.linux-mips.org/patch/7500/ Signed-off-by: Ralf Baechle <ralf@linux-mips.org> 
If a task does not execute scalar FP instructions prior to using MSA
then the flags indicating that the task has live MSA context were not
being set. The upper 64b of each vector register would then be lost
upon the tasks first context switch after using MSA.

Signed-off-by: Paul Burton <paul.burton@imgtec.com>
Cc: linux-mips@linux-mips.org
Patchwork: https://patchwork.linux-mips.org/patch/7500/
Signed-off-by: Ralf Baechle <ralf@linux-mips.org>
MIPS: init upper 64b of vector registers when MSA is first used 2014-08-01T22:06:44+00:00 Paul Burton paul.burton@imgtec.com 2014-07-30T07:53:20+00:00 c9017757c532d48bf43d6e7d3b7282443ad4207b When a task first makes use of MSA we need to ensure that the upper 64b of the vector registers are set to some value such that no information can be leaked to it from the previous task to use MSA context on the CPU. The architecture formerly specified that these bits would be cleared to 0 when a scalar FP instructions wrote to the aliased FP registers, which would have implicitly handled this as the kernel restored scalar FP context. However more recent versions of the specification now state that the value of the bits in such cases is unpredictable. Initialise them explictly to be sure, and set all the bits to 1 rather than 0 for consistency with the least significant 64b. Signed-off-by: Paul Burton <paul.burton@imgtec.com> Cc: linux-mips@linux-mips.org Patchwork: https://patchwork.linux-mips.org/patch/7497/ Signed-off-by: Ralf Baechle <ralf@linux-mips.org> 
When a task first makes use of MSA we need to ensure that the upper
64b of the vector registers are set to some value such that no
information can be leaked to it from the previous task to use MSA
context on the CPU. The architecture formerly specified that these
bits would be cleared to 0 when a scalar FP instructions wrote to the
aliased FP registers, which would have implicitly handled this as the
kernel restored scalar FP context. However more recent versions of the
specification now state that the value of the bits in such cases is
unpredictable. Initialise them explictly to be sure, and set all the
bits to 1 rather than 0 for consistency with the least significant
64b.

Signed-off-by: Paul Burton <paul.burton@imgtec.com>
Cc: linux-mips@linux-mips.org
Patchwork: https://patchwork.linux-mips.org/patch/7497/
Signed-off-by: Ralf Baechle <ralf@linux-mips.org>
MIPS: preserve scalar FP CSR when switching vector context 2014-08-01T22:06:43+00:00 Paul Burton paul.burton@imgtec.com 2014-07-11T15:44:29+00:00 b83406735a4ae0aff4b614664d6a64a0fd6b9917 Switching the vector context implicitly saves & restores the state of the aliased scalar FP data registers, however the scalar FP control & status register is distinct from the MSA control & status register. In order to allow scalar FP to function correctly in programs using MSA, the scalar CSR needs to be saved & restored along with the MSA vector context. Signed-off-by: Paul Burton <paul.burton@imgtec.com> Cc: linux-mips@linux-mips.org Patchwork: https://patchwork.linux-mips.org/patch/7301/ Signed-off-by: Ralf Baechle <ralf@linux-mips.org> 
Switching the vector context implicitly saves & restores the state of
the aliased scalar FP data registers, however the scalar FP control
& status register is distinct from the MSA control & status register.
In order to allow scalar FP to function correctly in programs using
MSA, the scalar CSR needs to be saved & restored along with the MSA
vector context.

Signed-off-by: Paul Burton <paul.burton@imgtec.com>
Cc: linux-mips@linux-mips.org
Patchwork: https://patchwork.linux-mips.org/patch/7301/
Signed-off-by: Ralf Baechle <ralf@linux-mips.org>
MIPS: Use dedicated exception handler if CPU supports RI/XI exceptions 2014-08-01T22:06:39+00:00 Leonid Yegoshin Leonid.Yegoshin@imgtec.com 2014-07-15T13:09:56+00:00 5890f70f15c52d0204a578422f8da828a0ba1096 Use the regular tlb_do_page_fault_0 (no write) handler to handle the RI and XI exceptions. Also skip the RI/XI validation check on TLB load handler since it's redundant when the CPU has unique RI/XI exceptions. Singed-off-by: Leonid Yegoshin <Leonid.Yegoshin@imgtec.com> Signed-off-by: Markos Chandras <markos.chandras@imgtec.com> Cc: linux-mips@linux-mips.org Patchwork: https://patchwork.linux-mips.org/patch/7339/ Signed-off-by: Ralf Baechle <ralf@linux-mips.org> 
Use the regular tlb_do_page_fault_0 (no write) handler to handle
the RI and XI exceptions. Also skip the RI/XI validation check
on TLB load handler since it's redundant when the CPU has
unique RI/XI exceptions.

Singed-off-by: Leonid Yegoshin <Leonid.Yegoshin@imgtec.com>
Signed-off-by: Markos Chandras <markos.chandras@imgtec.com>
Cc: linux-mips@linux-mips.org
Patchwork: https://patchwork.linux-mips.org/patch/7339/
Signed-off-by: Ralf Baechle <ralf@linux-mips.org>
Merge branch '3.15-fixes' into mips-for-linux-next 2014-06-04T20:53:02+00:00 Ralf Baechle ralf@linux-mips.org 2014-06-04T20:53:02+00:00 f8647b506d7116a1a3accd8d618184096e85f50b 






MIPS: Call find_vma with the mmap_sem held
2014-06-03T20:19:09+00:00

Davidlohr Bueso
davidlohr@hp.com

2014-04-20T02:26:28+00:00

f7a89f1b8eb598ac5da61c9795b3d847baa73d12

Performing vma lookups without taking the mm->mmap_sem is asking
for trouble. While doing the search, the vma in question can be
modified or even removed before returning to the caller. Take the
lock (exclusively) in order to avoid races while iterating through
the vmacache and/or rbtree.

Updates two functions:
  - process_fpemu_return()
  - cteon_flush_cache_sigtramp()

Signed-off-by: Davidlohr Bueso <davidlohr@hp.com>
Tested-by: Andreas Herrmann <andreas.herrmann@caviumnetworks.com>
Cc: linux-mips@linux-mips.org
Cc: akpm@linux-foundation.org
Cc: zeus@gnu.org
Cc: aswin@hp.com
Cc: davidlohr@hp.com
Cc: linux-mm@kvack.org
Cc: linux-kernel@vger.kernel.org
Patchwork: http://patchwork.linux-mips.org/patch/6811/
Signed-off-by: Ralf Baechle <ralf@linux-mips.org>





Performing vma lookups without taking the mm->mmap_sem is asking
for trouble. While doing the search, the vma in question can be
modified or even removed before returning to the caller. Take the
lock (exclusively) in order to avoid races while iterating through
the vmacache and/or rbtree.

Updates two functions:
  - process_fpemu_return()
  - cteon_flush_cache_sigtramp()

Signed-off-by: Davidlohr Bueso <davidlohr@hp.com>
Tested-by: Andreas Herrmann <andreas.herrmann@caviumnetworks.com>
Cc: linux-mips@linux-mips.org
Cc: akpm@linux-foundation.org
Cc: zeus@gnu.org
Cc: aswin@hp.com
Cc: davidlohr@hp.com
Cc: linux-mm@kvack.org
Cc: linux-kernel@vger.kernel.org
Patchwork: http://patchwork.linux-mips.org/patch/6811/
Signed-off-by: Ralf Baechle <ralf@linux-mips.org>







Merge branch 'wip-mips-pm' of https://github.com/paulburton/linux into mips-for-linux-next
2014-05-29T13:08:23+00:00

Ralf Baechle
ralf@linux-mips.org

2014-05-28T17:00:14+00:00

2e2d663d2dd64ffe9855be0b35aa221c9b8139f2












MIPS: Fix typo when reporting cache and ftlb errors for ImgTec cores
2014-05-25T10:45:06+00:00

Markos Chandras
markos.chandras@imgtec.com

2014-05-21T11:35:00+00:00

721a9205396c4ef2a811dd665ec2a232163b583d

Introduced by the following two commits:
75b5b5e0a262790fa11043fe45700499c7e3d818
"MIPS: Add support for FTLBs"
6de20451857ed14a4eecc28d08f6de5925d1cf96
"MIPS: Add printing of ES bit for Imgtec cores when cache error occurs"

Signed-off-by: Markos Chandras <markos.chandras@imgtec.com>
Reported-by: Matheus Almeida <Matheus.Almeida@imgtec.com>
Cc: linux-mips@linux-mips.org
Cc: Markos Chandras <markos.chandras@imgtec.com>
Cc: stable@vger.kernel.org # v3.14+
Patchwork: https://patchwork.linux-mips.org/patch/6980/
Signed-off-by: Ralf Baechle <ralf@linux-mips.org>





Introduced by the following two commits:
75b5b5e0a262790fa11043fe45700499c7e3d818
"MIPS: Add support for FTLBs"
6de20451857ed14a4eecc28d08f6de5925d1cf96
"MIPS: Add printing of ES bit for Imgtec cores when cache error occurs"

Signed-off-by: Markos Chandras <markos.chandras@imgtec.com>
Reported-by: Matheus Almeida <Matheus.Almeida@imgtec.com>
Cc: linux-mips@linux-mips.org
Cc: Markos Chandras <markos.chandras@imgtec.com>
Cc: stable@vger.kernel.org # v3.14+
Patchwork: https://patchwork.linux-mips.org/patch/6980/
Signed-off-by: Ralf Baechle <ralf@linux-mips.org>







MIPS: MT: Remove SMTC support
2014-05-23T22:07:01+00:00

Ralf Baechle
ralf@linux-mips.org

2014-05-23T14:29:44+00:00

b633648c5ad3cfbda0b3daea50d2135d44899259

Nobody is maintaining SMTC anymore and there also seems to be no userbase.
Which is a pity - the SMTC technology primarily developed by Kevin D.
Kissell <kevink@paralogos.com> is an ingenious demonstration for the MT
ASE's power and elegance.

Based on Markos Chandras <Markos.Chandras@imgtec.com> patch
https://patchwork.linux-mips.org/patch/6719/ which while very similar did
no longer apply cleanly when I tried to merge it plus some additional
post-SMTC cleanup - SMTC was a feature as tricky to remove as it was to
merge once upon a time.

Signed-off-by: Ralf Baechle <ralf@linux-mips.org>





Nobody is maintaining SMTC anymore and there also seems to be no userbase.
Which is a pity - the SMTC technology primarily developed by Kevin D.
Kissell <kevink@paralogos.com> is an ingenious demonstration for the MT
ASE's power and elegance.

Based on Markos Chandras <Markos.Chandras@imgtec.com> patch
https://patchwork.linux-mips.org/patch/6719/ which while very similar did
no longer apply cleanly when I tried to merge it plus some additional
post-SMTC cleanup - SMTC was a feature as tricky to remove as it was to
merge once upon a time.

Signed-off-by: Ralf Baechle <ralf@linux-mips.org>