Skip to content

R
raspberrypi-kernel

openeuler / raspberrypi-kernel

通知 13
Star 1
Fork 0
R
raspberrypi-kernel
切换分支/标签
  1. 28 3月, 2006 1 次提交
    • P
      ppc: Remove CHRP, POWER3 and POWER4 support from arch/ppc · 0a26b136
      由 Paul Mackerras 提交于 
      32-bit CHRP machines are now supported only in arch/powerpc, as are
all 64-bit PowerPC processors.  This means that we don't use
Open Firmware on any platform in arch/ppc any more.

This makes PReP support a single-platform option like every other
platform support option in arch/ppc now, thus CONFIG_PPC_MULTIPLATFORM
is gone from arch/ppc.  CONFIG_PPC_PREP is the option that selects
PReP support and is generally what has replaced
CONFIG_PPC_MULTIPLATFORM within arch/ppc.

_machine is all but dead now, being #defined to 0.

Updated Makefiles, comments and Kconfig options generally to reflect
these changes.
Signed-off-by: NPaul Mackerras <paulus@samba.org>
      0a26b136
  3. 27 3月, 2006 2 次提交
  5. 07 2月, 2006 1 次提交
  7. 15 1月, 2006 1 次提交
    • P
      [PATCH] ppc: Remove powermac support from ARCH=ppc · a7fdd90b
      由 Paul Mackerras 提交于 
      This makes it possible to build kernels for PReP and/or CHRP
with ARCH=ppc by removing the (non-building) powermac support.
It's now also possible to select PReP and CHRP independently.
Powermac users should now build with ARCH=powerpc instead of
ARCH=ppc.  (This does mean that it is no longer possible to
build a 32-bit kernel for a G5.)
Signed-off-by: NPaul Mackerras <paulus@samba.org>
      a7fdd90b
  9. 11 1月, 2006 1 次提交
  11. 09 1月, 2006 1 次提交
  13. 05 12月, 2005 1 次提交
    • P
      ppc: Build in all three of powermac, PREP and CHRP support · b6d78157
      由 Paul Mackerras 提交于 
      This reverts commit da0825fd, making
it so that if you select CONFIG_PPC_MULTIPLATFORM you get support
for PMAC, PREP and CHRP built in.

The reason for not allowing PMAC, PREP and CHRP to be selected
individually for ARCH=ppc is that there is too much interdependency
between them in the platform support code.  For example, CHRP uses
the PMAC nvram code.

Configuring with ARCH=powerpc does allow you to select support for
PMAC and CHRP separately.  Support for PREP is not there yet but
should be there soon.
Signed-off-by: NPaul Mackerras <paulus@samba.org>
      b6d78157
  15. 07 11月, 2005 2 次提交
  17. 26 10月, 2005 2 次提交
  19. 21 9月, 2005 3 次提交
  21. 19 9月, 2005 1 次提交
  23. 15 9月, 2005 1 次提交
    • D
      [LIB]: Consolidate _atomic_dec_and_lock() · 4db2ce01
      由 David S. Miller 提交于 
      Several implementations were essentialy a common piece of C code using
the cmpxchg() macro.  Put the implementation in one spot that everyone
can share, and convert sparc64 over to using this.

Alpha is the lone arch-specific implementation, which codes up a
special fast path for the common case in order to avoid GP reloading
which a pure C version would require.
Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      4db2ce01
  25. 11 9月, 2005 1 次提交
    • P
      [PATCH] ppc32: support hotplug cpu on powermacs · 31139971
      由 Paul Mackerras 提交于 
      This allows cpus to be off-lined on 32-bit SMP powermacs.  When a cpu
is off-lined, it is put into sleep mode with interrupts disabled.  It
can be on-lined again by asserting its soft-reset pin, which is
connected to a GPIO pin.

With this I can off-line the second cpu in my dual G4 powermac, which
means that I can then suspend the machine (the suspend/resume code
refuses to suspend if more than one cpu is online, and making it cope
with multiple cpus is surprisingly messy).
Signed-off-by: NPaul Mackerras <paulus@samba.org>
Signed-off-by: NLinus Torvalds <torvalds@osdl.org>
      31139971
  27. 10 9月, 2005 1 次提交
  29. 08 9月, 2005 1 次提交
    • V
      [PATCH] Kconfig fix (BLK_DEV_FD dependencies) · a08b6b79
      由 viro@ZenIV.linux.org.uk 提交于 
      Sanitized and fixed floppy dependencies: split the messy dependencies for
BLK_DEV_FD by introducing a new symbol (ARCH_MAY_HAVE_PC_FDC), making
BLK_DEV_FD depend on that one and taking declarations of ARCH_MAY_HAVE_PC_FDC
to arch/*/Kconfig.  While we are at it, fixed several obvious cases when
BLK_DEV_FD should have been excluded (architectures lacking asm/floppy.h
are *not* going to have floppy.c compile, let alone work).

If you can come up with better name for that ("this architecture might
have working PC-compatible floppy disk controller"), you are more than
welcome - just s/ARCH_MAY_HAVE_PC_FDC/your_prefered_name/g in the patch
below...
Signed-off-by: NAl Viro <viro@zeniv.linux.org.uk>
Signed-off-by: NLinus Torvalds <torvalds@osdl.org>
      a08b6b79
  31. 05 9月, 2005 8 次提交
  33. 24 8月, 2005 3 次提交
  35. 02 8月, 2005 1 次提交
  37. 28 7月, 2005 3 次提交
  39. 12 7月, 2005 1 次提交
    • S
      [NET]: add a top-level Networking menu to *config · d5950b43
      由 Sam Ravnborg 提交于 
      Create a new top-level menu named "Networking" thus moving
net related options and protocol selection way from the drivers
menu and up on the top-level where they belong.

To implement this all architectures has to source "net/Kconfig" before
drivers/*/Kconfig in their Kconfig file. This change has been
implemented for all architectures.

Device drivers for ordinary NIC's are still to be found
in the Device Drivers section, but Bluetooth, IrDA and ax25
are located with their corresponding menu entries under the new
networking menu item.
Signed-off-by: NSam Ravnborg <sam@ravnborg.org>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      d5950b43
  41. 06 7月, 2005 1 次提交
  43. 26 6月, 2005 2 次提交
    • E
      [PATCH] kexec: kexec ppc support · 70765aa4
      由 Eric W. Biederman 提交于 
      I have tweaked this patch slightly to handle an empty list
of pages to relocate passed to relocate_new_kernel.  And
I have added ppc_md.machine_crash_shutdown.  To keep up with
the changes in the generic kexec infrastructure.

From: Albert Herranz <albert_herranz@yahoo.es>

The following patch adds support for kexec on the ppc32 platform.

Non-OpenFirmware based platforms are likely to work directly without
additional changes on the kernel side.  The kexec-tools userland package
may need to be slightly updated, though.

For OpenFirmware based machines, additional work is still needed on the
kernel side before kexec support is ready.  Benjamin Herrenschmidt is
kindly working on that part.

In order for a ppc platform to use the kexec kernel services it must
implement some ppc_md hooks.  Otherwise, kexec will be explicitly disabled,
as suggested by benh.

There are 3+1 new ppc_md hooks that a platform supporting kexec may
implement.  Two of them are mandatory for kexec to work.  See
include/asm-ppc/machdep.h for details.

- machine_kexec_prepare(image)

  This function is called to make any arrangements to the image before it
  is loaded.

  This hook _MUST_ be provided by a platform in order to activate kexec
  support for that platform.  Otherwise, the platform is considered to not
  support kexec and the kexec_load system call will fail (that makes all
  existing platforms by default non-kexec'able).

- machine_kexec_cleanup(image)

  This function is called to make any cleanups on image after the loaded
  image data it is freed.  This hook is optional.  A platform may or may
  not provide this hook.

- machine_kexec(image)

  This function is called to perform the _actual_ kexec.  This hook
  _MUST_ be provided by a platform in order to activate kexec support for
  that platform.

  If a platform provides machine_kexec_prepare but forgets to provide
  machine_kexec, a kexec will fall back to a reboot.

  A ready-to-use machine_kexec_simple() generic function is provided to,
  hopefully, simplify kexec adoption for embedded platforms.  A platform
  may call this function from its specific machine_kexec hook, like this:

void myplatform_kexec(struct kimage *image)
{
        machine_kexec_simple(image);
}

- machine_shutdown()

  This function is called to perform any machine specific shutdowns, not
  already done by drivers.  This hook is optional.  A platform may or may
  not provide this hook.

An example (trimmed) platform specific module for a platform supporting
kexec through the existing machine_kexec_simple follows:

/* ... */

#ifdef CONFIG_KEXEC
int myplatform_kexec_prepare(struct kimage *image)
{
        /* here, we can place additional preparations
*/
        return 0; /* yes, we support kexec */
}

void myplatform_kexec(struct kimage *image)
{
        machine_kexec_simple(image);
}
#endif /* CONFIG_KEXEC */

/* ... */

void __init
platform_init(unsigned long r3, unsigned long r4,
unsigned long r5,
              unsigned long r6, unsigned long r7)
{

/* ... */

#ifdef CONFIG_KEXEC
        ppc_md.machine_kexec_prepare =
myplatform_kexec_prepare;
        ppc_md.machine_kexec         =
myplatform_kexec;
#endif /* CONFIG_KEXEC */

/* ... */

}

The kexec ppc kernel support has been heavily tested on the GameCube Linux
port, and, as reported in the fastboot mailing list, it has been tested too
on a Moto 82xx ppc by Rick Richardson.
Signed-off-by: NAlbert Herranz <albert_herranz@yahoo.es>
Signed-off-by: NEric Biederman <ebiederm@xmission.com>
Acked-by: NBenjamin Herrenschmidt <benh@kernel.crashing.org>
Signed-off-by: NAndrew Morton <akpm@osdl.org>
Signed-off-by: NLinus Torvalds <torvalds@osdl.org>
      70765aa4
    • K
      [PATCH] ppc32: Add support for Freescale e200 (Book-E) core · 33d9e9b5
      由 Kumar Gala 提交于 
      The e200 core is a Book-E core (similar to e500) that has a unified L1 cache
and is not cache coherent on the bus.  The e200 core also adds a separate
exception level for debug exceptions.  Part of this patch helps to cleanup a
few cases that are true for all Freescale Book-E parts, not just e500.
Signed-off-by: NKim Phillips <kim.phillips@freescale.com>
Signed-off-by: NKumar Gala <kumar.gala@freescale.com>
Signed-off-by: NAndrew Morton <akpm@osdl.org>
Signed-off-by: NLinus Torvalds <torvalds@osdl.org>
      33d9e9b5
  45. 24 6月, 2005 1 次提交