Eric Lee / smarc-fsl-linux-kernel

12 Jan, 2012

1 commit

  • 9f13a1fd4   cpu: Register a generic CPU device on architectures that currently do not ... Browse Code »
    43

    frv, h8300, m68k, microblaze, openrisc, score, um and xtensa currently
    do not register a CPU device. Add the config option GENERIC_CPU_DEVICES
    which causes a generic CPU device to be registered for each present CPU,
    and make all these architectures select it.

    Richard Weinberger covered UML and suggested using
    per_cpu.

    Signed-off-by: Ben Hutchings
    Signed-off-by: Linus Torvalds

    Ben Hutchings
     

11 Jan, 2012

1 commit

  • e343a895a   Merge tag 'for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/mst/vhost ... Browse Code »

    lib: use generic pci_iomap on all architectures

    Many architectures don't want to pull in iomap.c,
    so they ended up duplicating pci_iomap from that file.
    That function isn't trivial, and we are going to modify it
    https://lkml.org/lkml/2011/11/14/183
    so the duplication hurts.

    This reduces the scope of the problem significantly,
    by moving pci_iomap to a separate file and
    referencing that from all architectures.

    * tag 'for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/mst/vhost:
    alpha: drop pci_iomap/pci_iounmap from pci-noop.c
    mn10300: switch to GENERIC_PCI_IOMAP
    mn10300: add missing __iomap markers
    frv: switch to GENERIC_PCI_IOMAP
    tile: switch to GENERIC_PCI_IOMAP
    tile: don't panic on iomap
    sparc: switch to GENERIC_PCI_IOMAP
    sh: switch to GENERIC_PCI_IOMAP
    powerpc: switch to GENERIC_PCI_IOMAP
    parisc: switch to GENERIC_PCI_IOMAP
    mips: switch to GENERIC_PCI_IOMAP
    microblaze: switch to GENERIC_PCI_IOMAP
    arm: switch to GENERIC_PCI_IOMAP
    alpha: switch to GENERIC_PCI_IOMAP
    lib: add GENERIC_PCI_IOMAP
    lib: move GENERIC_IOMAP to lib/Kconfig

    Fix up trivial conflicts due to changes nearby in arch/{m68k,score}/Kconfig

    Linus Torvalds
     

30 Dec, 2011

3 commits

  • 4a13c6dc6   m68k: ColdFire with MMU enabled uses same clocking code as non-MMU ... Browse Code »

    We want to use the same timer support code for ColdFire CPU's when
    running with MMU enabled or not. So use the same time_no.c code even
    when the MMU is enabled for ColdFire. This also means we do not want
    CONFIG_ARCH_USES_GETTIMEOFFSET set, since that code is only in time_mm.c.

    Signed-off-by: Greg Ungerer
    Acked-by: Matt Waddel
    Acked-by: Kurt Mahan
    Acked-by: Geert Uytterhoeven

    Greg Ungerer
     
  • 0e6782c88   m68k: compile appropriate mm arch files for ColdFire MMU support ... Browse Code »

    Create a config symbol to enable when using a ColdFire MMU. We then
    use that to only compile the necessary arch mm files.

    Signed-off-by: Greg Ungerer
    Acked-by: Geert Uytterhoeven
    Acked-by: Matt Waddel
    Acked-by: Kurt Mahan

    Greg Ungerer
     
  • e08d703cc   m68k: modify user space access functions to support ColdFire CPUs ... Browse Code »

    Modify the user space access functions to support the ColdFire V4e cores
    running with MMU enabled.

    The ColdFire processors do not support the "moves" instruction used by
    the traditional 680x0 processors for moving data into and out of another
    address space. They only support the notion of a single address space,
    and you use the usual "move" instruction to access that.

    Create a new config symbol (CONFIG_CPU_HAS_ADDRESS_SPACES) to mark the
    CPU types that support separate address spaces, and thus also support
    the sfc/dfc registers and the "moves" instruction that go along with that.

    The code is almost identical for user space access, so lets just use a
    define to choose either the "move" or "moves" in the assembler code.

    Signed-off-by: Greg Ungerer
    Acked-by: Matt Waddel
    Acked-by: Kurt Mahan
    Acked-by: Geert Uytterhoeven

    Greg Ungerer
     

24 Dec, 2011

3 commits

  • 84f3fb7a2   m68k: handle presence of 64bit mul/div instructions cleanly ... Browse Code »

    The traditional 68000 processors and the newer reduced instruction set
    ColdFire processors do not support the 32*32->64 multiply or the 64/32->32
    divide instructions. This is not a difference based on the presence of
    a hardware MMU or not.

    Create a new config symbol to mark that a CPU type doesn't support the
    longer multiply/divide instructions. Use this then as a basis for using
    the fast 64bit based divide (in div64.h) and for linking in the extra
    libgcc functions that may be required (mulsi3, divsi3, etc).

    Signed-off-by: Greg Ungerer
    Acked-by: Geert Uytterhoeven

    Greg Ungerer
     
  • 7f73bafc4   m68k: simpler m68k and ColdFire CPU's can use generic csum code ... Browse Code »

    We have two implementations of the IP checksuming code for the m68k arch.
    One uses the more advanced instructions available in 68020 and above
    processors, the other uses the simpler instructions available on the
    original 68000 processors and the modern ColdFire processors.

    This simpler code is pretty much the same as the generic lib implementation
    of the IP csum functions. So lets just switch over to using that. That
    means we can completely remove the checksum_no.c file, and only have the
    local fast code used for the more complex 68k CPU family members.

    Signed-off-by: Greg Ungerer

    Greg Ungerer
     
  • 5717a02be   m68k: selection of GENERIC_ATOMIC64 is not MMU specific ... Browse Code »

    The selection of the CONFIG_GENERIC_ATOMIC64 option is not specific to the
    MMU being present and enabled. It is a property of certain CPU families.
    So select it based on those CPU types being selected.

    Signed-off-by: Greg Ungerer

    Greg Ungerer
     

25 Nov, 2011

1 commit

09 Nov, 2011

10 commits

18 Oct, 2011

1 commit

  • 0e152d805   m68k: reorganize Kconfig options to improve mmu/non-mmu selections ... Browse Code »

    The current mmu and non-mmu Kconfig files can be merged to form
    a more general selection of options. The current break up of options
    is due to the simple brute force merge from the m68k and m68knommu
    arch directories.

    Many of the options are not at all specific to having the MMU enabled
    or not. They are actually associated with a particular CPU type or
    platform type.

    Ultimately as we support all processors with the MMU disabled we need
    many of these options to be selectable without the MMU option enabled.
    And likewise some of the ColdFire processors, which currently are only
    supported with the MMU disabled, do have MMU hardware, and will need
    to have options selected on CPU type, not MMU disabled.

    This patch removes the old mmu and non-mmu Kconfigs and instead breaks
    up the configuration into four areas: cpu, machine, bus, devices.

    The Kconfig.cpu lists all the options associated with selecting a CPU,
    and includes options specific to each CPU type as well.

    Kconfig.machine lists all options associated with selecting a machine
    type. Almost always the machines selectable is restricted by the chosen
    CPU.

    Kconfig.bus contains options associated with selecting bus types on the
    various machine types. That includes PCI bus, PCMCIA bus, etc.

    Kconfig.devices contains options for drivers and driver associated
    options.

    Signed-off-by: Greg Ungerer

    Greg Ungerer
     

03 Aug, 2011

2 commits

  • d0e323b47   Merge branch 'apei' into apei-release ... Browse Code »

    Some trivial conflicts due to other various merges
    adding to the end of common lists sooner than this one.

    arch/ia64/Kconfig
    arch/powerpc/Kconfig
    arch/x86/Kconfig
    lib/Kconfig
    lib/Makefile

    Signed-off-by: Len Brown

    Len Brown
     
  • df013ffb8   Add Kconfig option ARCH_HAVE_NMI_SAFE_CMPXCHG ... Browse Code »

    cmpxchg() is widely used by lockless code, including NMI-safe lockless
    code. But on some architectures, the cmpxchg() implementation is not
    NMI-safe, on these architectures the lockless code may need a
    spin_trylock_irqsave() based implementation.

    This patch adds a Kconfig option: ARCH_HAVE_NMI_SAFE_CMPXCHG, so that
    NMI-safe lockless code can depend on it or provide different
    implementation according to it.

    On many architectures, cmpxchg is only NMI-safe for several specific
    operand sizes. So, ARCH_HAVE_NMI_SAFE_CMPXCHG define in this patch
    only guarantees cmpxchg is NMI-safe for sizeof(unsigned long).

    Signed-off-by: Huang Ying
    Acked-by: Mike Frysinger
    Acked-by: Paul Mundt
    Acked-by: Hans-Christian Egtvedt
    Acked-by: Benjamin Herrenschmidt
    Acked-by: Chris Metcalf
    Acked-by: Richard Henderson
    CC: Mikael Starvik
    Acked-by: David Howells
    CC: Yoshinori Sato
    CC: Tony Luck
    CC: Hirokazu Takata
    CC: Geert Uytterhoeven
    CC: Michal Simek
    Acked-by: Ralf Baechle
    CC: Kyle McMartin
    CC: Martin Schwidefsky
    CC: Chen Liqin
    CC: "David S. Miller"
    CC: Ingo Molnar
    CC: Chris Zankel
    Signed-off-by: Len Brown

    Huang Ying
     

25 Jul, 2011

1 commit

  • 171d809df   m68k: merge mmu and non-mmu bitops.h ... Browse Code »

    The following patch merges the mmu and non-mmu versions of the m68k
    bitops.h files. Now there is a good deal of difference between the two
    files, but none of it is actually an mmu specific difference. It is
    all about the specific m68k/coldfire varient we are targeting. So it
    makes an awful lot of sense to merge these into a single bitops.h.

    There is a number of ways I can see to factor this code. The approach
    I have taken here is to keep the various versions of each macro/function
    type together. This means that there is some ifdefery with each to handle
    each CPU type.

    I have added some comments in a couple of appropriate places to try
    and make it clear what the differences we are dealing with are.
    Specifically the instruction and addressing mode differences we have
    to deal with.

    The merged form keeps the same underlying optimizations for each CPU
    type for all the general bit clear/set/change and find bit operations.
    It does switch to using the generic le operations though, instead of
    any local varients.

    Build tested on ColdFire, 68328, 68360 (which is cpu32) and 68020+.
    Run tested on ColdFire and ARAnyM.

    Signed-off-by: Greg Ungerer
    Acked-by: Geert Uytterhoeven

    Greg Ungerer
     

24 May, 2011

1 commit

30 Mar, 2011

1 commit

25 Mar, 2011

1 commit

  • 66d857b08   m68k: merge m68k and m68knommu arch directories ... Browse Code »

    There is a lot of common code that could be shared between the m68k
    and m68knommu arch branches. It makes sense to merge the two branches
    into a single directory structure so that we can more easily share
    that common code.

    This is a brute force merge, based on a script from Stephen King
    , which was originally written by Arnd Bergmann
    .

    > The script was inspired by the script Sam Ravnborg used to merge the
    > includes from m68knommu. For those files common to both arches but
    > differing in content, the m68k version of the file is renamed to
    > _mm. and the m68knommu version of the file is moved into the
    > corresponding m68k directory and renamed _no. and a small
    > wrapper file . is used to select between the two version. Files
    > that are common to both but don't differ are removed from the m68knommu
    > tree and files and directories that are unique to the m68knommu tree are
    > moved to the m68k tree. Finally, the arch/m68knommu tree is removed.
    >
    > To select between the the versions of the files, the wrapper uses
    >
    > #ifdef CONFIG_MMU
    > #include _mm.
    > #else
    > #include _no.
    > #endif

    On top of this file merge I have done a simplistic merge of m68k and
    m68knommu Kconfig, which primarily attempts to keep existing options and
    menus in place. Other than a handful of options being moved it produces
    identical .config outputs on m68k and m68knommu targets I tested it on.

    With this in place there is now quite a bit of scope for merge cleanups
    in future patches.

    Signed-off-by: Greg Ungerer

    Greg Ungerer
     

17 Mar, 2011

6 commits

23 Feb, 2011

1 commit

29 Oct, 2010

1 commit

  • 51399a391   Merge branch 'kconfig' of git://git.kernel.org/pub/scm/linux/kernel/git/mmarek/kbuild-2.6 ... Browse Code »

    * 'kconfig' of git://git.kernel.org/pub/scm/linux/kernel/git/mmarek/kbuild-2.6: (38 commits)
    kbuild: convert `arch/tile' to the kconfig mainmenu upgrade
    README: cite nconfig
    Revert "kconfig: Temporarily disable dependency warnings"
    kconfig: Use PATH_MAX instead of 128 for path buffer sizes.
    kconfig: Fix realloc usage()
    kconfig: Propagate const
    kconfig: Don't go out from read config loop when you read new symbol
    kconfig: fix menuconfig on debian lenny
    kbuild: migrate all arch to the kconfig mainmenu upgrade
    kconfig: expand file names
    kconfig: use the file's name of sourced file
    kconfig: constify file name
    kconfig: don't emit warning upon rootmenu's prompt redefinition
    kconfig: replace KERNELVERSION usage by the mainmenu's prompt
    kconfig: delay gconf window initialization
    kconfig: expand by default the rootmenu's prompt
    kconfig: add a symbol string expansion helper
    kconfig: regen parser
    kconfig: implement the `mainmenu' directive
    kconfig: allow PACKAGE to be defined on the compiler's command-line
    ...

    Fix up trivial conflict in arch/mn10300/Kconfig

    Linus Torvalds
     

22 Oct, 2010

1 commit

12 Oct, 2010

1 commit

20 Sep, 2010

1 commit

27 Jul, 2010

1 commit

  • 592913ecb   time: Kill off CONFIG_GENERIC_TIME ... Browse Code »

    Now that all arches have been converted over to use generic time via
    clocksources or arch_gettimeoffset(), we can remove the GENERIC_TIME
    config option and simplify the generic code.

    Signed-off-by: John Stultz
    LKML-Reference:
    Signed-off-by: Thomas Gleixner

    John Stultz
     

27 May, 2010

1 commit

28 Feb, 2010

1 commit