Skip to content

R
raspberrypi-kernel

openeuler / raspberrypi-kernel

通知 13
Star 1
Fork 0
R
raspberrypi-kernel
切换分支/标签
  1. 13 2月, 2007 3 次提交
  3. 12 2月, 2007 3 次提交
  5. 10 2月, 2007 1 次提交
  7. 08 2月, 2007 4 次提交
  9. 07 2月, 2007 11 次提交
    • K
      [POWERPC] Fixup error handling when emulating a floating point instruction · 5fad293b
      由 Kumar Gala 提交于 
      When we do full FP emulation its possible that we need to post a SIGFPE based
on the results of the emulation.  The previous code ignored this case completely.

Additionally, the Soft_emulate_8xx case had two issues.  One, we should never
generate a SIGFPE since the code only does data movement.  Second, we were
interpreting the return codes incorrectly, it returns 0 on success, 1 on
illop and -EFAULT on a data access error.
Signed-off-by: NKumar Gala <galak@kernel.crashing.org>
      5fad293b
    • K
      [POWERPC] Enable interrupts if we are doing fp math emulation · 04903a30
      由 Kumar Gala 提交于 
      Anytime we are emulating an instruction we are going to be doing some form of
get_user() to get the instruction image to decode.  Since get_user() might
sleep we need to ensure we have interrupts enabled or we might see something
like:

Debug: sleeping function called from invalid context at arch/powerpc/kernel/traps.c:697
in_atomic():0, irqs_disabled():1
Call Trace:
[D6023EB0] [C0007F84] show_stack+0x58/0x174 (unreliable)
[D6023EE0] [C0022C34] __might_sleep+0xbc/0xd0
[D6023EF0] [C000D158] program_check_exception+0x1d8/0x4fc
[D6023F40] [C000E744] ret_from_except_full+0x0/0x4c
--- Exception: 700 at 0x102a7100
    LR = 0xdb9ef04

However, we want to ensure that interrupts are disabled when handling a trap
exception that might be used for a kernel breakpoint.  This is why ProgramCheck
is marked as EXC_XFER_STD instead of EXC_XFER_EE.
Signed-off-by: NKumar Gala <galak@kernel.crashing.org>
      04903a30
    • K
      [POWERPC] Added kprobes support to ppc32 · 82090035
      由 Kumar Gala 提交于 
      Added kprobes to ppc32 platforms that have use single_step_exception.  This
excludes 4xx and anything Book-E since their debug mechanisms for single stepping
are completely different.
Signed-off-by: NKumar Gala <galak@kernel.crashing.org>
      82090035
    • P
      [POWERPC] Clear RI bit in MSR before restoring r13 when returning to userspace · e56a6e20
      由 Paul Mackerras 提交于 
      Some instruction tracing tools use the RI (recoverable interrupt) bit
in the MSR to indicate when it's safe to single-step.  Currently we
clear RI after restoring r13 when returning to userspace.  However,
if we single-step past the point where r13 is restored, we'll corrupt
r13 in the exception entry code and not restore it.  This moves the
clearing of RI to just before r13 is restored so this doesn't happen.
Signed-off-by: NPaul Mackerras <paulus@samba.org>
      e56a6e20
    • L
      [POWERPC] Fix performance monitor exception · 449d846d
      由 Livio Soares 提交于 
      To the issue: some point during 2.6.20 development, Paul Mackerras
introduced the "lazy IRQ  disabling" patch (very cool work,  BTW).
In that patch, the performance monitor unit exception was marked as
"maskable", in the sense that if interrupts were soft-disabled, that
exception could be ignored.  This broke my PowerPC profiling code.
The symptom that I see is that a varying number of interrupts
(from 0 to $n$, typically closer to 0) get delivered, when, in
reality, it should always be very close to $n$.

The issue stems from the way masking is being done.   Masking in
this fashion seems to  work well with the decrementer and external
interrupts, because they are raised again until "really"  handled.
For the PMU, however, this does not apply (at least on my Xserver
machine with a 970FX processor).  If the PMU exception is not handled,
it will _not_ be re-raised (at least on my machine).  The documentation
states that the PMXE bit in MMCR0 is set to 0 when the PMU exception
is raised.  However, software must re-set the bit to re-enable PMU
exceptions.  If the exception is ignored (as currently) not only is
that interrupt lost, but because software does not re-set PMXE, the
PMU registers are "frozen" forever.

[This patch means that performance monitor exceptions are taken and
handled even if irqs are off, as long as some other interrupt hasn't
come along and caused interrupts to be hard-disabled.  In this sense
the PMU exception becomes like an NMI.  The oprofile code for most
powerpc processors does nothing that is unsafe in an NMI context, but
the Cell oprofile code does a spin_lock_irqsave.  However, that turns
out to be OK because Cell doesn't actually use the performance
monitor exception; performance monitor interrupts come in as a
regular interrupt on Cell, so will be disabled when irqs are off.
 -- paulus.]
Signed-off-by: NPaul Mackerras <paulus@samba.org>
      449d846d
    • D
      [POWERPC] Compile fixes for arch/powerpc dcr code · a2c70211
      由 David Gibson 提交于 
      The new dcr code does not currently compile when configured for native
DCR access on ARCH=powerpc.  This patch fixes the problems.
Signed-off-by: NDavid Gibson <dwg@au1.ibm.com>
Signed-off-by: NPaul Mackerras <paulus@samba.org>
      a2c70211
    • O
      [POWERPC] pasemi: Idle loops · 1199919b
      由 Olof Johansson 提交于 
      Powersave support on PA6T. Right now it only uses 'doze' mode, and
will default to no savings (spin).
Signed-off-by: NOlof Johansson <olof@lixom.net>
Acked-by: NArnd Bergmann <arnd@arndb.de>
Signed-off-by: NPaul Mackerras <paulus@samba.org>
      1199919b
    • O
      [POWERPC] pasemi: UART udbg support · 39c870d5
      由 Olof Johansson 提交于 
      Early debug output for PA Semi UART. Uses the 2.05 CI real mode ops.
Signed-off-by: NOlof Johansson <olof@lixom.net>
Signed-off-by: NPaul Mackerras <paulus@samba.org>
      39c870d5
    • I
      [POWERPC] Celleb: support udbg · d7480a9f
      由 Ishizaki Kou 提交于 
      This patch adds udbg support for Celleb platform.
Signed-off-by: NKou Ishizaki <kou.ishizaki@toshiba.co.jp>
Acked-by: NBenjamin Herrenschmidt <benh@kernel.crashing.org>
Signed-off-by: NPaul Mackerras <paulus@samba.org>
      d7480a9f
    • O
      [POWERPC] PA6T PMC support · 6529c13d
      由 Olof Johansson 提交于 
      Support for PA6T-style PMC registers.

PMCs are completely implementation-dependent on PPC, and PA6T numbers them
differently from the IBM model.
Signed-off-by: NOlof Johansson <olof@lixom.net>
Signed-off-by: NPaul Mackerras <paulus@samba.org>
      6529c13d
    • O
      [POWERPC] Add PMC type to cputable · 1bd2e5ae
      由 Olof Johansson 提交于 
      Add cputable entries for which type of PMC implementation the processor
has.

I've only filled in the current 64-bit processors, the unfilled default
value will have same behaviour as before so it can be done over time
as needed.

Also tidy up the dummy_perf implementation a bit, aggregating it into
one function with ifdefs instead of several.
Signed-off-by: NOlof Johansson <olof@lixom.net>
Signed-off-by: NPaul Mackerras <paulus@samba.org>
      1bd2e5ae
  11. 28 1月, 2007 1 次提交
  13. 27 1月, 2007 1 次提交
  15. 26 1月, 2007 1 次提交
  17. 24 1月, 2007 8 次提交
  19. 22 1月, 2007 1 次提交
  21. 12 1月, 2007 1 次提交
    • G
      [PATCH] Change cpu_up and co from __devinit to __cpuinit · b282b6f8
      由 Gautham R Shenoy 提交于 
      Compiling the kernel with CONFIG_HOTPLUG = y and CONFIG_HOTPLUG_CPU = n
with CONFIG_RELOCATABLE = y generates the following modpost warnings

WARNING: vmlinux - Section mismatch: reference to .init.data: from
.text between '_cpu_up' (at offset 0xc0141b7d) and 'cpu_up'
WARNING: vmlinux - Section mismatch: reference to .init.data: from
.text between '_cpu_up' (at offset 0xc0141b9c) and 'cpu_up'
WARNING: vmlinux - Section mismatch: reference to .init.text:__cpu_up
from .text between '_cpu_up' (at offset 0xc0141bd8) and 'cpu_up'
WARNING: vmlinux - Section mismatch: reference to .init.data: from
.text between '_cpu_up' (at offset 0xc0141c05) and 'cpu_up'
WARNING: vmlinux - Section mismatch: reference to .init.data: from
.text between '_cpu_up' (at offset 0xc0141c26) and 'cpu_up'
WARNING: vmlinux - Section mismatch: reference to .init.data: from
.text between '_cpu_up' (at offset 0xc0141c37) and 'cpu_up'

This is because cpu_up, _cpu_up and __cpu_up (in some architectures) are
defined as __devinit
AND
__cpu_up calls some __cpuinit functions.

Since __cpuinit would map to __init with this kind of a configuration,
we get a .text refering .init.data warning.

This patch solves the problem by converting all of __cpu_up, _cpu_up
and cpu_up from __devinit to __cpuinit. The approach is justified since
the callers of cpu_up are either dependent on CONFIG_HOTPLUG_CPU or
are of __init type.

Thus when CONFIG_HOTPLUG_CPU=y, all these cpu up functions would land up
in .text section, and when CONFIG_HOTPLUG_CPU=n, all these functions would
land up in .init section.

Tested on a i386 SMP machine running linux-2.6.20-rc3-mm1.
Signed-off-by: NGautham R Shenoy <ego@in.ibm.com>
Cc: Vivek Goyal <vgoyal@in.ibm.com>
Cc: Mikael Starvik <starvik@axis.com>
Cc: Ralf Baechle <ralf@linux-mips.org>
Cc: Kyle McMartin <kyle@mcmartin.ca>
Cc: Paul Mackerras <paulus@samba.org>
Cc: Benjamin Herrenschmidt <benh@kernel.crashing.org>
Cc: "David S. Miller" <davem@davemloft.net>
Signed-off-by: NAndrew Morton <akpm@osdl.org>
Signed-off-by: NLinus Torvalds <torvalds@osdl.org>
      b282b6f8
  23. 09 1月, 2007 1 次提交
    • D
      [POWERPC] Fix manual assembly WARN_ON() in enter_rtas(). · 007d88d0
      由 David Woodhouse 提交于 
      When we switched over to the generic BUG mechanism we forgot to change
the assembly code which open-codes a WARN_ON() in enter_rtas(), so the
bug table got corrupted.

This patch provides an EMIT_BUG_ENTRY macro for use in assembly code,
and uses it in entry_64.S. Tested with CONFIG_DEBUG_BUGVERBOSE on ppc64
but not without -- I tried to turn it off but it wouldn't go away; I
suspect Aunt Tillie probably needed it.

This version gets __FILE__ and __LINE__ right in the assembly version --
rather than saying include/asm-powerpc/bug.h line 21 every time which is
a little suboptimal.
Signed-off-by: NDavid Woodhouse <dwmw2@infradead.org>
Signed-off-by: NPaul Mackerras <paulus@samba.org>
      007d88d0
  25. 20 12月, 2006 3 次提交
  27. 19 12月, 2006 1 次提交