This patch addresses a couple of related problems:

1) The kernel may reside in physical memory outside of the ranges set
   by plat_mem_setup().  If this is the case, init mem cannot be
   reused as it resides outside of the range of pages that the kernel
   memory allocators control.

2) initrd images might be loaded in physical memory outside of the
   ranges set by plat_mem_setup().  The memory likewise cannot be
   reused.  The patch doesn't handle this specific case, but the
   infrastructure is useful for future patches that do.

The crux of the problem is that there are memory regions that need be
memory_present(), but that cannot be free_bootmem() at the time of
arch_mem_init().  We create a new type of memory (BOOT_MEM_INIT_RAM)
for use with add_memory_region().  Then arch_mem_init() adds the init
mem with this type if the init mem is not already covered by existing
ranges.

When memory is being freed into the bootmem allocator, we skip the
BOOT_MEM_INIT_RAM ranges so they are not clobbered, but we do signal
them as memory_present().  This way when they are later freed, the
necessary memory manager structures have initialized and the Sparse
allocater is prevented from crashing.

The Octeon specific code that handled this case is removed, because
the new general purpose code handles the case.

Signed-off-by: David Daney <ddaney@caviumnetworks.com>
To: linux-mips@linux-mips.org
Patchwork: https://patchwork.linux-mips.org/patch/1988/
Signed-off-by: Ralf Baechle <ralf@linux-mips.org>

This allows platforms that are using the swiotlb to initialize it.

Signed-off-by: David Daney <ddaney@caviumnetworks.com>
Patchwork: http://patchwork.linux-mips.org/patch/1638/
Signed-off-by: Ralf Baechle <ralf@linux-mips.org>

Adds a new cpu type for the JZ4740 to the Linux MIPS architecture code.
It also adds the iomem addresses for the different components found on
a JZ4740 SoC.

Signed-off-by: Lars-Peter Clausen <lars@metafoo.de>
Cc: linux-mips@linux-mips.org
Cc: linux-kernel@vger.kernel.org
Patchwork: https://patchwork.linux-mips.org/patch/1464/
Signed-off-by: Ralf Baechle <ralf@linux-mips.org>

Add a new machtype and kernel options for the Lynloong.

Signed-off-by: Wu Zhangjin <wuzhangjin@gmail.com>
Cc: linux-mips@linux-mips.org
Patchwork: http://patchwork.linux-mips.org/patch/657/
Signed-off-by: Ralf Baechle <ralf@linux-mips.org>

Kernel support for this machine is almost the same as Fuloong 2F; the only
difference is that it uses the serial port provided by Loongson 2F processor
as Yeeloong 2F does.

Signed-off-by: Wu Zhangjin <wuzhangjin@gmail.com>
Cc: linux-mips@linux-mips.org
Patchwork: http://patchwork.linux-mips.org/patch/656/
Signed-off-by: Ralf Baechle <ralf@linux-mips.org>

The MIPS-specific macro CL_SIZE is merely aliasing the macro
COMMAND_LINE_SIZE. Other architectures use the latter; also,
COMMAND_LINE_SIZE is documented in kernel-parameters.txt, so
let's use it, and remove the alias.

Signed-off-by: Dmitri Vorobiev <dmitri.vorobiev@movial.com>
Signed-off-by: Ralf Baechle <ralf@linux-mips.org>

The difference between some loongson-based machines is very small, so, if
there is no necessary to add new kernel config options to cope with this
difference, it will be better to share the same kernel image file between
them, benefit from this, the linux distribution developers only have a need
to compile the kernel one time.

This machtype kernel command line argument will be used later to share the
same kernel image file between two different machines(menglong & yeeloong)
made by lemote.

Thanks very much to Zhang Le for cleaning up the machtype implementation.

Signed-off-by: Wu Zhangjin <wuzhangjin@gmail.com>
Signed-off-by: Ralf Baechle <ralf@linux-mips.org>

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