Eric Lee / smarc-fsl-linux-kernel

09 Nov, 2009

1 commit

04 Nov, 2009

1 commit

20 Sep, 2009

1 commit

  • caa27b66b   kbuild: use INSTALLKERNEL to select customized installkernel script ... Browse Code »

    Replace the use of CROSS_COMPILE to select a customized
    installkernel script with the possibility to set INSTALLKERNEL
    to select a custom installkernel script when running make:

    make INSTALLKERNEL=arm-installkernel install

    With this patch we are now more consistent across
    different architectures - they did not all support use
    of CROSS_COMPILE.

    The use of CROSS_COMPILE was a hack as this really belongs
    to gcc/binutils and the installkernel script does not change
    just because we change toolchain.

    The use of CROSS_COMPILE caused troubles with an upcoming patch
    that saves CROSS_COMPILE when a kernel is built - it would no
    longer be installable.
    [Thanks to Peter Z. for this hint]

    This patch undos what Ian did in commit:

    0f8e2d62fa04441cd12c08ce521e84e5bd3f8a46
    ("use ${CROSS_COMPILE}installkernel in arch/*/boot/install.sh")

    The patch has been lightly tested on x86 only - but all changes
    looks obvious.

    Acked-by: Peter Zijlstra
    Acked-by: Mike Frysinger [blackfin]
    Acked-by: Russell King [arm]
    Acked-by: Paul Mundt [sh]
    Acked-by: "H. Peter Anvin" [x86]
    Cc: Ian Campbell
    Cc: Tony Luck [ia64]
    Cc: Fenghua Yu [ia64]
    Cc: Hirokazu Takata [m32r]
    Cc: Geert Uytterhoeven [m68k]
    Cc: Kyle McMartin [parisc]
    Cc: Benjamin Herrenschmidt [powerpc]
    Cc: Martin Schwidefsky [s390]
    Cc: Thomas Gleixner [x86]
    Cc: Ingo Molnar [x86]
    Signed-off-by: Sam Ravnborg

    Sam Ravnborg
     

02 May, 2009

1 commit

  • 9c88b06dc   m32r: build fix for __stringify macro ... Browse Code »

    This patch fixes the following build error of 2.6.30-rc3-git2:

    AS arch/m32r/kernel/head.o
    In file included from /include/linux/init.h:7,
    from /arch/m32r/kernel/head.S:11:
    /include/linux/stringify.h:9: error: syntax error in macro parameter list
    /include/linux/stringify.h:10: error: syntax error in macro parameter list

    This build error was caused at __HEAD macro in arch/m32r/kernel/head.S,
    which uses __stringify() macro.

    Remove -traditional option from EXTRA_AFLAGS for the m32r,
    because the __stringify() macro depends on the gcc's variadic macro
    extension function, due to commit:

    Make __stringify support variable argument macros too
    commit: 8f7c2c37319a81ef4c2bfdec67b1ccd5744d97e4

    Signed-off-by: Hirokazu Takata

    Hirokazu Takata
     

26 Jul, 2008

1 commit

  • 2d6ffcca6   inflate: refactor inflate malloc code ... Browse Code »

    Inflate requires some dynamic memory allocation very early in the boot
    process and this is provided with a set of four functions:
    malloc/free/gzip_mark/gzip_release.

    The old inflate code used a mark/release strategy rather than implement
    free. This new version instead keeps a count on the number of outstanding
    allocations and when it hits zero, it resets the malloc arena.

    This allows removing all the mark and release implementations and unifying
    all the malloc/free implementations.

    The architecture-dependent code must define two addresses:
    - free_mem_ptr, the address of the beginning of the area in which
    allocations should be made
    - free_mem_end_ptr, the address of the end of the area in which
    allocations should be made. If set to 0, then no check is made on
    the number of allocations, it just grows as much as needed

    The architecture-dependent code can also provide an arch_decomp_wdog()
    function call. This function will be called several times during the
    decompression process, and allow to notify the watchdog that the system is
    still running. If an architecture provides such a call, then it must
    define ARCH_HAS_DECOMP_WDOG so that the generic inflate code calls
    arch_decomp_wdog().

    Work initially done by Matt Mackall, updated to a recent version of the
    kernel and improved by me.

    [akpm@linux-foundation.org: coding-style fixes]
    Signed-off-by: Thomas Petazzoni
    Cc: Matt Mackall
    Cc: Richard Henderson
    Cc: Ivan Kokshaysky
    Cc: Mikael Starvik
    Cc: Jesper Nilsson
    Cc: Haavard Skinnemoen
    Cc: David Howells
    Cc: Ingo Molnar
    Cc: Thomas Gleixner
    Cc: Andi Kleen
    Cc: "H. Peter Anvin"
    Acked-by: Paul Mundt
    Acked-by: Yoshinori Sato
    Signed-off-by: Andrew Morton
    Signed-off-by: Linus Torvalds

    Thomas Petazzoni
     

06 Feb, 2008

1 commit

09 Dec, 2006

1 commit

  • d93f7de8c   [PATCH] m32r: bootloader support for OPSPUT platform ... Browse Code »

    This patch supports "m32r-g00ff" bootloader for an OPSPUT platform.

    Applying this patch, it is possible to do ATA-boot from an IDE drive or
    HTTP-boot from network by m32r-g00ff.

    * arch/m32r/boot/compressed/m32r_sio.c: Fix hangup on OPSPUT at boot.

    * arch/m32r/kernel/io_opsput.c: IDE support for OPSPUT.
    * arch/m32r/kernel/setup_opsput.c: ditto.
    * include/asm-m32r/ide.h: ditto.

    Signed-off-by: Kazuhiro Inaoka
    Signed-off-by: Hirokazu Takata
    Signed-off-by: Andrew Morton
    Signed-off-by: Linus Torvalds

    Hirokazu Takata
     

01 Jul, 2006

1 commit

07 Jan, 2006

2 commits

  • 9b791d476   [PATCH] m32r: Fix M32104 cache flushing routines ... Browse Code »

    This patch fixes cache memory parameter setting for the M32104 target. So
    far, its performance seemed to have been degraded due to incorrect cache
    parameter setting.

    * arch/m32r/boot/setup.S: Set SFR(Special Fuction Registers) region
    to be non-cachable explicitly.
    * arch/m32r/mm/cache.c: Fix cache flushing routines not to switch off
    the M32104 cache.

    Signed-off-by: Hayato Fujiwara
    Signed-off-by: Hirokazu Takata
    Signed-off-by: Andrew Morton
    Signed-off-by: Linus Torvalds

    Hirokazu Takata
     
  • 9287d95ea   [PATCH] m32r: Support M32104UT target platform ... Browse Code »

    This patch is for supporting a new target platform, Renesas M32104UT
    evaluation board.

    The M32104UT is an eval board based on an uT-Engine specification. This board
    has an MMU-less M32R family processor, M32104.
    http://www-wa0.personal-media.co.jp/pmc/archive/te/te_m32104_e.pdf

    This board is one of the most popular M32R platform, so we have ported
    Linux/M32R to it.

    Signed-off-by: Naoto Sugai
    Signed-off-by: Hirokazu Takata
    Signed-off-by: Andrew Morton
    Signed-off-by: Linus Torvalds

    Hirokazu Takata
     

22 Jun, 2005

1 commit

  • 236808634   [PATCH] m32r: Support M3A-2170(Mappi-III) platform ... Browse Code »

    This patchset is for supporting a new m32r platform, M3A-2170(Mappi-III)
    evaluation board. An M32R chip multiprocessor is equipped on the board.
    http://http://www.linux-m32r.org/eng/platform/platform.html

    * arch/m32r/Kconfig: Support Mappi-III platform.
    * arch/m32r/kernel/Makefile: ditto.
    * arch/m32r/kernel/io_mappi3.c: ditto.
    * arch/m32r/kernel/setup.c: ditto.
    * arch/m32r/kernel/setup_mappi3.c: ditto.
    * include/asm-m32r/m32102.h: ditto.
    * include/asm-m32r/m32r.h: ditto.
    * include/asm-m32r/mappi3/mappi3_pld.h: ditto.

    * include/asm-m32r/ide.h: CF support for Mappi-III.
    * arch/m32r/kernel/setup_mappi3.c: ditto.

    * arch/m32r/mappi3/defconfig.smp: A default config file for Mappi-III.
    * arch/m32r/mappi3/dot.gdbinit: A default .gdbinit file for Mappi-III.

    * arch/m32r/boot/compressed/m32r_sio.c: Modified for Mappi-III
    - At boot time, m32r-g00ff bootloader makes MMU off for Mappi-III,
    on the contrary it makes MMU on for Mappi-II.

    * arch/m32r/kernel/io_mappi2.c: Update comments.
    * arch/m32r/kernel/setup_mappi2.c: ditto.

    Signed-off-by: Mamoru Sakugawa
    Signed-off-by: Hirokazu Takata
    Signed-off-by: Andrew Morton
    Signed-off-by: Linus Torvalds

    Hirokazu Takata
     

17 Apr, 2005

1 commit

  • 1da177e4c   Linux-2.6.12-rc2 ... Browse Code »

    Initial git repository build. I'm not bothering with the full history,
    even though we have it. We can create a separate "historical" git
    archive of that later if we want to, and in the meantime it's about
    3.2GB when imported into git - space that would just make the early
    git days unnecessarily complicated, when we don't have a lot of good
    infrastructure for it.

    Let it rip!

    Linus Torvalds