linux-brain/arch/mips/mti-malta/malta-dtshim.c

334 lines
8.8 KiB
C
Raw Normal View History

// SPDX-License-Identifier: GPL-2.0-or-later
/*
* Copyright (C) 2015 Imagination Technologies
Update MIPS email addresses MIPS will soon not be a part of Imagination Technologies, and as such many @imgtec.com email addresses will no longer be valid. This patch updates the addresses for those who: - Have 10 or more patches in mainline authored using an @imgtec.com email address, or any patches dated within the past year. - Are still with Imagination but leaving as part of the MIPS business unit, as determined from an internal email address list. - Haven't already updated their email address (ie. JamesH) or expressed a desire to be excluded (ie. Maciej). - Acked v2 or earlier of this patch, which leaves Deng-Cheng, Matt & myself. New addresses are of the form firstname.lastname@mips.com, and all verified against an internal email address list. An entry is added to .mailmap for each person such that get_maintainer.pl will report the new addresses rather than @imgtec.com addresses which will soon be dead. Instances of the affected addresses throughout the tree are then mechanically replaced with the new @mips.com address. Signed-off-by: Paul Burton <paul.burton@mips.com> Cc: Deng-Cheng Zhu <dengcheng.zhu@imgtec.com> Cc: Deng-Cheng Zhu <dengcheng.zhu@mips.com> Acked-by: Dengcheng Zhu <dengcheng.zhu@mips.com> Cc: Matt Redfearn <matt.redfearn@imgtec.com> Cc: Matt Redfearn <matt.redfearn@mips.com> Acked-by: Matt Redfearn <matt.redfearn@mips.com> Cc: Andrew Morton <akpm@linux-foundation.org> Cc: linux-kernel@vger.kernel.org Cc: linux-mips@linux-mips.org Cc: trivial@kernel.org Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2017-10-26 09:04:33 +09:00
* Author: Paul Burton <paul.burton@mips.com>
*/
#include <linux/bug.h>
#include <linux/kernel.h>
#include <linux/libfdt.h>
#include <linux/of_fdt.h>
#include <linux/sizes.h>
MIPS: Malta: Use all available DDR by default Malta boards can have more than 256MB DDR available, but we have previously only made use of up to 256MB (ie. the DDR accessible via kseg0) by default, without the user manually specifying mem= kernel parameters. This patch causes all available DDR, as reported by the bootloader via the ememsize or memsize environment variables or optionally on the command line, to be used when possible without the user needing to manually provide the memory ranges. Malta now has 2 subtly different memory maps which have to be taken into account when setting this up. The original memory map (referred to by the code as v1) has up to 2GB of DDR aliased in both the upper & lower halves of the 32 bit physical address space, with a 256MB I/O region obscuring 0x10000000-0x1fffffff only in the lower alias. The revised v2 memory map is flat with up to 4GB DDR starting from 0x0, and the I/O region obscures 256MB of DDR which becomes inacessible. The memory map in use is indicated by a register provided by the rocit2 system controller, which is checked in order to set up the kernels memory ranges accordingly. Signed-off-by: Paul Burton <paul.burton@imgtec.com> Cc: Masahiro Yamada <yamada.masahiro@socionext.com> Cc: Kees Cook <keescook@chromium.org> Cc: Andrew Morton <akpm@linux-foundation.org> Cc: linux-mips@linux-mips.org Cc: linux-kernel@vger.kernel.org Patchwork: https://patchwork.linux-mips.org/patch/14273/ Signed-off-by: Ralf Baechle <ralf@linux-mips.org>
2016-09-20 06:21:22 +09:00
#include <asm/addrspace.h>
#include <asm/bootinfo.h>
#include <asm/fw/fw.h>
MIPS: Malta: Use all available DDR by default Malta boards can have more than 256MB DDR available, but we have previously only made use of up to 256MB (ie. the DDR accessible via kseg0) by default, without the user manually specifying mem= kernel parameters. This patch causes all available DDR, as reported by the bootloader via the ememsize or memsize environment variables or optionally on the command line, to be used when possible without the user needing to manually provide the memory ranges. Malta now has 2 subtly different memory maps which have to be taken into account when setting this up. The original memory map (referred to by the code as v1) has up to 2GB of DDR aliased in both the upper & lower halves of the 32 bit physical address space, with a 256MB I/O region obscuring 0x10000000-0x1fffffff only in the lower alias. The revised v2 memory map is flat with up to 4GB DDR starting from 0x0, and the I/O region obscures 256MB of DDR which becomes inacessible. The memory map in use is indicated by a register provided by the rocit2 system controller, which is checked in order to set up the kernels memory ranges accordingly. Signed-off-by: Paul Burton <paul.burton@imgtec.com> Cc: Masahiro Yamada <yamada.masahiro@socionext.com> Cc: Kees Cook <keescook@chromium.org> Cc: Andrew Morton <akpm@linux-foundation.org> Cc: linux-mips@linux-mips.org Cc: linux-kernel@vger.kernel.org Patchwork: https://patchwork.linux-mips.org/patch/14273/ Signed-off-by: Ralf Baechle <ralf@linux-mips.org>
2016-09-20 06:21:22 +09:00
#include <asm/mips-boards/generic.h>
#include <asm/mips-boards/malta.h>
#include <asm/mips-cps.h>
#include <asm/page.h>
MIPS: Malta: Use all available DDR by default Malta boards can have more than 256MB DDR available, but we have previously only made use of up to 256MB (ie. the DDR accessible via kseg0) by default, without the user manually specifying mem= kernel parameters. This patch causes all available DDR, as reported by the bootloader via the ememsize or memsize environment variables or optionally on the command line, to be used when possible without the user needing to manually provide the memory ranges. Malta now has 2 subtly different memory maps which have to be taken into account when setting this up. The original memory map (referred to by the code as v1) has up to 2GB of DDR aliased in both the upper & lower halves of the 32 bit physical address space, with a 256MB I/O region obscuring 0x10000000-0x1fffffff only in the lower alias. The revised v2 memory map is flat with up to 4GB DDR starting from 0x0, and the I/O region obscures 256MB of DDR which becomes inacessible. The memory map in use is indicated by a register provided by the rocit2 system controller, which is checked in order to set up the kernels memory ranges accordingly. Signed-off-by: Paul Burton <paul.burton@imgtec.com> Cc: Masahiro Yamada <yamada.masahiro@socionext.com> Cc: Kees Cook <keescook@chromium.org> Cc: Andrew Morton <akpm@linux-foundation.org> Cc: linux-mips@linux-mips.org Cc: linux-kernel@vger.kernel.org Patchwork: https://patchwork.linux-mips.org/patch/14273/ Signed-off-by: Ralf Baechle <ralf@linux-mips.org>
2016-09-20 06:21:22 +09:00
#define ROCIT_REG_BASE 0x1f403000
#define ROCIT_CONFIG_GEN1 (ROCIT_REG_BASE + 0x04)
#define ROCIT_CONFIG_GEN1_MEMMAP_SHIFT 8
#define ROCIT_CONFIG_GEN1_MEMMAP_MASK (0xf << 8)
static unsigned char fdt_buf[16 << 10] __initdata __aligned(8);
/* determined physical memory size, not overridden by command line args */
extern unsigned long physical_memsize;
MIPS: Malta: Use all available DDR by default Malta boards can have more than 256MB DDR available, but we have previously only made use of up to 256MB (ie. the DDR accessible via kseg0) by default, without the user manually specifying mem= kernel parameters. This patch causes all available DDR, as reported by the bootloader via the ememsize or memsize environment variables or optionally on the command line, to be used when possible without the user needing to manually provide the memory ranges. Malta now has 2 subtly different memory maps which have to be taken into account when setting this up. The original memory map (referred to by the code as v1) has up to 2GB of DDR aliased in both the upper & lower halves of the 32 bit physical address space, with a 256MB I/O region obscuring 0x10000000-0x1fffffff only in the lower alias. The revised v2 memory map is flat with up to 4GB DDR starting from 0x0, and the I/O region obscures 256MB of DDR which becomes inacessible. The memory map in use is indicated by a register provided by the rocit2 system controller, which is checked in order to set up the kernels memory ranges accordingly. Signed-off-by: Paul Burton <paul.burton@imgtec.com> Cc: Masahiro Yamada <yamada.masahiro@socionext.com> Cc: Kees Cook <keescook@chromium.org> Cc: Andrew Morton <akpm@linux-foundation.org> Cc: linux-mips@linux-mips.org Cc: linux-kernel@vger.kernel.org Patchwork: https://patchwork.linux-mips.org/patch/14273/ Signed-off-by: Ralf Baechle <ralf@linux-mips.org>
2016-09-20 06:21:22 +09:00
enum mem_map {
MEM_MAP_V1 = 0,
MEM_MAP_V2,
};
#define MAX_MEM_ARRAY_ENTRIES 2
static __init int malta_scon(void)
{
int scon = MIPS_REVISION_SCONID;
if (scon != MIPS_REVISION_SCON_OTHER)
return scon;
switch (MIPS_REVISION_CORID) {
case MIPS_REVISION_CORID_QED_RM5261:
case MIPS_REVISION_CORID_CORE_LV:
case MIPS_REVISION_CORID_CORE_FPGA:
case MIPS_REVISION_CORID_CORE_FPGAR2:
return MIPS_REVISION_SCON_GT64120;
case MIPS_REVISION_CORID_CORE_EMUL_BON:
case MIPS_REVISION_CORID_BONITO64:
case MIPS_REVISION_CORID_CORE_20K:
return MIPS_REVISION_SCON_BONITO;
case MIPS_REVISION_CORID_CORE_MSC:
case MIPS_REVISION_CORID_CORE_FPGA2:
case MIPS_REVISION_CORID_CORE_24K:
return MIPS_REVISION_SCON_SOCIT;
case MIPS_REVISION_CORID_CORE_FPGA3:
case MIPS_REVISION_CORID_CORE_FPGA4:
case MIPS_REVISION_CORID_CORE_FPGA5:
case MIPS_REVISION_CORID_CORE_EMUL_MSC:
default:
return MIPS_REVISION_SCON_ROCIT;
}
}
MIPS: Malta: Use all available DDR by default Malta boards can have more than 256MB DDR available, but we have previously only made use of up to 256MB (ie. the DDR accessible via kseg0) by default, without the user manually specifying mem= kernel parameters. This patch causes all available DDR, as reported by the bootloader via the ememsize or memsize environment variables or optionally on the command line, to be used when possible without the user needing to manually provide the memory ranges. Malta now has 2 subtly different memory maps which have to be taken into account when setting this up. The original memory map (referred to by the code as v1) has up to 2GB of DDR aliased in both the upper & lower halves of the 32 bit physical address space, with a 256MB I/O region obscuring 0x10000000-0x1fffffff only in the lower alias. The revised v2 memory map is flat with up to 4GB DDR starting from 0x0, and the I/O region obscures 256MB of DDR which becomes inacessible. The memory map in use is indicated by a register provided by the rocit2 system controller, which is checked in order to set up the kernels memory ranges accordingly. Signed-off-by: Paul Burton <paul.burton@imgtec.com> Cc: Masahiro Yamada <yamada.masahiro@socionext.com> Cc: Kees Cook <keescook@chromium.org> Cc: Andrew Morton <akpm@linux-foundation.org> Cc: linux-mips@linux-mips.org Cc: linux-kernel@vger.kernel.org Patchwork: https://patchwork.linux-mips.org/patch/14273/ Signed-off-by: Ralf Baechle <ralf@linux-mips.org>
2016-09-20 06:21:22 +09:00
static unsigned __init gen_fdt_mem_array(__be32 *mem_array, unsigned long size,
enum mem_map map)
{
unsigned long size_preio;
unsigned entries;
entries = 1;
mem_array[0] = cpu_to_be32(PHYS_OFFSET);
tree-wide: replace config_enabled() with IS_ENABLED() The use of config_enabled() against config options is ambiguous. In practical terms, config_enabled() is equivalent to IS_BUILTIN(), but the author might have used it for the meaning of IS_ENABLED(). Using IS_ENABLED(), IS_BUILTIN(), IS_MODULE() etc. makes the intention clearer. This commit replaces config_enabled() with IS_ENABLED() where possible. This commit is only touching bool config options. I noticed two cases where config_enabled() is used against a tristate option: - config_enabled(CONFIG_HWMON) [ drivers/net/wireless/ath/ath10k/thermal.c ] - config_enabled(CONFIG_BACKLIGHT_CLASS_DEVICE) [ drivers/gpu/drm/gma500/opregion.c ] I did not touch them because they should be converted to IS_BUILTIN() in order to keep the logic, but I was not sure it was the authors' intention. Link: http://lkml.kernel.org/r/1465215656-20569-1-git-send-email-yamada.masahiro@socionext.com Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com> Acked-by: Kees Cook <keescook@chromium.org> Cc: Stas Sergeev <stsp@list.ru> Cc: Matt Redfearn <matt.redfearn@imgtec.com> Cc: Joshua Kinard <kumba@gentoo.org> Cc: Jiri Slaby <jslaby@suse.com> Cc: Bjorn Helgaas <bhelgaas@google.com> Cc: Borislav Petkov <bp@suse.de> Cc: Markos Chandras <markos.chandras@imgtec.com> Cc: "Dmitry V. Levin" <ldv@altlinux.org> Cc: yu-cheng yu <yu-cheng.yu@intel.com> Cc: James Hogan <james.hogan@imgtec.com> Cc: Brian Gerst <brgerst@gmail.com> Cc: Johannes Berg <johannes@sipsolutions.net> Cc: Peter Zijlstra <peterz@infradead.org> Cc: Al Viro <viro@zeniv.linux.org.uk> Cc: Will Drewry <wad@chromium.org> Cc: Nikolay Martynov <mar.kolya@gmail.com> Cc: Huacai Chen <chenhc@lemote.com> Cc: "H. Peter Anvin" <hpa@zytor.com> Cc: Thomas Gleixner <tglx@linutronix.de> Cc: Daniel Borkmann <daniel@iogearbox.net> Cc: Leonid Yegoshin <Leonid.Yegoshin@imgtec.com> Cc: Rafal Milecki <zajec5@gmail.com> Cc: James Cowgill <James.Cowgill@imgtec.com> Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Cc: Ralf Baechle <ralf@linux-mips.org> Cc: Alex Smith <alex.smith@imgtec.com> Cc: Adam Buchbinder <adam.buchbinder@gmail.com> Cc: Qais Yousef <qais.yousef@imgtec.com> Cc: Jiang Liu <jiang.liu@linux.intel.com> Cc: Mikko Rapeli <mikko.rapeli@iki.fi> Cc: Paul Gortmaker <paul.gortmaker@windriver.com> Cc: Denys Vlasenko <dvlasenk@redhat.com> Cc: Brian Norris <computersforpeace@gmail.com> Cc: Hidehiro Kawai <hidehiro.kawai.ez@hitachi.com> Cc: "Luis R. Rodriguez" <mcgrof@do-not-panic.com> Cc: Andy Lutomirski <luto@amacapital.net> Cc: Ingo Molnar <mingo@redhat.com> Cc: Dave Hansen <dave.hansen@linux.intel.com> Cc: "Kirill A. Shutemov" <kirill.shutemov@linux.intel.com> Cc: Roland McGrath <roland@hack.frob.com> Cc: Paul Burton <paul.burton@imgtec.com> Cc: Kalle Valo <kvalo@qca.qualcomm.com> Cc: Viresh Kumar <viresh.kumar@linaro.org> Cc: Tony Wu <tung7970@gmail.com> Cc: Huaitong Han <huaitong.han@intel.com> Cc: Sumit Semwal <sumit.semwal@linaro.org> Cc: Alexei Starovoitov <ast@kernel.org> Cc: Juergen Gross <jgross@suse.com> Cc: Jason Cooper <jason@lakedaemon.net> Cc: "David S. Miller" <davem@davemloft.net> Cc: Oleg Nesterov <oleg@redhat.com> Cc: Andrea Gelmini <andrea.gelmini@gelma.net> Cc: David Woodhouse <dwmw2@infradead.org> Cc: Marc Zyngier <marc.zyngier@arm.com> Cc: Rabin Vincent <rabin@rab.in> Cc: "Maciej W. Rozycki" <macro@imgtec.com> Cc: David Daney <david.daney@cavium.com> Signed-off-by: Andrew Morton <akpm@linux-foundation.org> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2016-08-04 05:45:50 +09:00
if (IS_ENABLED(CONFIG_EVA)) {
/*
* The current Malta EVA configuration is "special" in that it
* always makes use of addresses in the upper half of the 32 bit
* physical address map, which gives it a contiguous region of
* DDR but limits it to 2GB.
*/
mem_array[1] = cpu_to_be32(size);
MIPS: Malta: Use all available DDR by default Malta boards can have more than 256MB DDR available, but we have previously only made use of up to 256MB (ie. the DDR accessible via kseg0) by default, without the user manually specifying mem= kernel parameters. This patch causes all available DDR, as reported by the bootloader via the ememsize or memsize environment variables or optionally on the command line, to be used when possible without the user needing to manually provide the memory ranges. Malta now has 2 subtly different memory maps which have to be taken into account when setting this up. The original memory map (referred to by the code as v1) has up to 2GB of DDR aliased in both the upper & lower halves of the 32 bit physical address space, with a 256MB I/O region obscuring 0x10000000-0x1fffffff only in the lower alias. The revised v2 memory map is flat with up to 4GB DDR starting from 0x0, and the I/O region obscures 256MB of DDR which becomes inacessible. The memory map in use is indicated by a register provided by the rocit2 system controller, which is checked in order to set up the kernels memory ranges accordingly. Signed-off-by: Paul Burton <paul.burton@imgtec.com> Cc: Masahiro Yamada <yamada.masahiro@socionext.com> Cc: Kees Cook <keescook@chromium.org> Cc: Andrew Morton <akpm@linux-foundation.org> Cc: linux-mips@linux-mips.org Cc: linux-kernel@vger.kernel.org Patchwork: https://patchwork.linux-mips.org/patch/14273/ Signed-off-by: Ralf Baechle <ralf@linux-mips.org>
2016-09-20 06:21:22 +09:00
goto done;
}
size_preio = min_t(unsigned long, size, SZ_256M);
mem_array[1] = cpu_to_be32(size_preio);
size -= size_preio;
if (!size)
goto done;
if (map == MEM_MAP_V2) {
/*
* We have a flat 32 bit physical memory map with DDR filling
* all 4GB of the memory map, apart from the I/O region which
* obscures 256MB from 0x10000000-0x1fffffff.
*
* Therefore we discard the 256MB behind the I/O region.
*/
if (size <= SZ_256M)
goto done;
size -= SZ_256M;
/* Make use of the memory following the I/O region */
entries++;
mem_array[2] = cpu_to_be32(PHYS_OFFSET + SZ_512M);
mem_array[3] = cpu_to_be32(size);
} else {
MIPS: Malta: Use all available DDR by default Malta boards can have more than 256MB DDR available, but we have previously only made use of up to 256MB (ie. the DDR accessible via kseg0) by default, without the user manually specifying mem= kernel parameters. This patch causes all available DDR, as reported by the bootloader via the ememsize or memsize environment variables or optionally on the command line, to be used when possible without the user needing to manually provide the memory ranges. Malta now has 2 subtly different memory maps which have to be taken into account when setting this up. The original memory map (referred to by the code as v1) has up to 2GB of DDR aliased in both the upper & lower halves of the 32 bit physical address space, with a 256MB I/O region obscuring 0x10000000-0x1fffffff only in the lower alias. The revised v2 memory map is flat with up to 4GB DDR starting from 0x0, and the I/O region obscures 256MB of DDR which becomes inacessible. The memory map in use is indicated by a register provided by the rocit2 system controller, which is checked in order to set up the kernels memory ranges accordingly. Signed-off-by: Paul Burton <paul.burton@imgtec.com> Cc: Masahiro Yamada <yamada.masahiro@socionext.com> Cc: Kees Cook <keescook@chromium.org> Cc: Andrew Morton <akpm@linux-foundation.org> Cc: linux-mips@linux-mips.org Cc: linux-kernel@vger.kernel.org Patchwork: https://patchwork.linux-mips.org/patch/14273/ Signed-off-by: Ralf Baechle <ralf@linux-mips.org>
2016-09-20 06:21:22 +09:00
/*
* We have a 32 bit physical memory map with a 2GB DDR region
* aliased in the upper & lower halves of it. The I/O region
* obscures 256MB from 0x10000000-0x1fffffff in the low alias
* but the DDR it obscures is accessible via the high alias.
*
* Simply access everything beyond the lowest 256MB of DDR using
* the high alias.
*/
entries++;
mem_array[2] = cpu_to_be32(PHYS_OFFSET + SZ_2G + SZ_256M);
mem_array[3] = cpu_to_be32(size);
}
MIPS: Malta: Use all available DDR by default Malta boards can have more than 256MB DDR available, but we have previously only made use of up to 256MB (ie. the DDR accessible via kseg0) by default, without the user manually specifying mem= kernel parameters. This patch causes all available DDR, as reported by the bootloader via the ememsize or memsize environment variables or optionally on the command line, to be used when possible without the user needing to manually provide the memory ranges. Malta now has 2 subtly different memory maps which have to be taken into account when setting this up. The original memory map (referred to by the code as v1) has up to 2GB of DDR aliased in both the upper & lower halves of the 32 bit physical address space, with a 256MB I/O region obscuring 0x10000000-0x1fffffff only in the lower alias. The revised v2 memory map is flat with up to 4GB DDR starting from 0x0, and the I/O region obscures 256MB of DDR which becomes inacessible. The memory map in use is indicated by a register provided by the rocit2 system controller, which is checked in order to set up the kernels memory ranges accordingly. Signed-off-by: Paul Burton <paul.burton@imgtec.com> Cc: Masahiro Yamada <yamada.masahiro@socionext.com> Cc: Kees Cook <keescook@chromium.org> Cc: Andrew Morton <akpm@linux-foundation.org> Cc: linux-mips@linux-mips.org Cc: linux-kernel@vger.kernel.org Patchwork: https://patchwork.linux-mips.org/patch/14273/ Signed-off-by: Ralf Baechle <ralf@linux-mips.org>
2016-09-20 06:21:22 +09:00
done:
BUG_ON(entries > MAX_MEM_ARRAY_ENTRIES);
return entries;
}
static void __init append_memory(void *fdt, int root_off)
{
__be32 mem_array[2 * MAX_MEM_ARRAY_ENTRIES];
unsigned long memsize;
unsigned mem_entries;
int i, err, mem_off;
MIPS: Malta: Use all available DDR by default Malta boards can have more than 256MB DDR available, but we have previously only made use of up to 256MB (ie. the DDR accessible via kseg0) by default, without the user manually specifying mem= kernel parameters. This patch causes all available DDR, as reported by the bootloader via the ememsize or memsize environment variables or optionally on the command line, to be used when possible without the user needing to manually provide the memory ranges. Malta now has 2 subtly different memory maps which have to be taken into account when setting this up. The original memory map (referred to by the code as v1) has up to 2GB of DDR aliased in both the upper & lower halves of the 32 bit physical address space, with a 256MB I/O region obscuring 0x10000000-0x1fffffff only in the lower alias. The revised v2 memory map is flat with up to 4GB DDR starting from 0x0, and the I/O region obscures 256MB of DDR which becomes inacessible. The memory map in use is indicated by a register provided by the rocit2 system controller, which is checked in order to set up the kernels memory ranges accordingly. Signed-off-by: Paul Burton <paul.burton@imgtec.com> Cc: Masahiro Yamada <yamada.masahiro@socionext.com> Cc: Kees Cook <keescook@chromium.org> Cc: Andrew Morton <akpm@linux-foundation.org> Cc: linux-mips@linux-mips.org Cc: linux-kernel@vger.kernel.org Patchwork: https://patchwork.linux-mips.org/patch/14273/ Signed-off-by: Ralf Baechle <ralf@linux-mips.org>
2016-09-20 06:21:22 +09:00
enum mem_map mem_map;
u32 config;
char *var, param_name[10], *var_names[] = {
"ememsize", "memsize",
};
/* if a memory node already exists, leave it alone */
mem_off = fdt_path_offset(fdt, "/memory");
if (mem_off >= 0)
return;
/* find memory size from the bootloader environment */
for (i = 0; i < ARRAY_SIZE(var_names); i++) {
var = fw_getenv(var_names[i]);
if (!var)
continue;
err = kstrtoul(var, 0, &physical_memsize);
if (!err)
break;
pr_warn("Failed to read the '%s' env variable '%s'\n",
var_names[i], var);
}
if (!physical_memsize) {
pr_warn("The bootloader didn't provide memsize: defaulting to 32MB\n");
physical_memsize = 32 << 20;
}
tree-wide: replace config_enabled() with IS_ENABLED() The use of config_enabled() against config options is ambiguous. In practical terms, config_enabled() is equivalent to IS_BUILTIN(), but the author might have used it for the meaning of IS_ENABLED(). Using IS_ENABLED(), IS_BUILTIN(), IS_MODULE() etc. makes the intention clearer. This commit replaces config_enabled() with IS_ENABLED() where possible. This commit is only touching bool config options. I noticed two cases where config_enabled() is used against a tristate option: - config_enabled(CONFIG_HWMON) [ drivers/net/wireless/ath/ath10k/thermal.c ] - config_enabled(CONFIG_BACKLIGHT_CLASS_DEVICE) [ drivers/gpu/drm/gma500/opregion.c ] I did not touch them because they should be converted to IS_BUILTIN() in order to keep the logic, but I was not sure it was the authors' intention. Link: http://lkml.kernel.org/r/1465215656-20569-1-git-send-email-yamada.masahiro@socionext.com Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com> Acked-by: Kees Cook <keescook@chromium.org> Cc: Stas Sergeev <stsp@list.ru> Cc: Matt Redfearn <matt.redfearn@imgtec.com> Cc: Joshua Kinard <kumba@gentoo.org> Cc: Jiri Slaby <jslaby@suse.com> Cc: Bjorn Helgaas <bhelgaas@google.com> Cc: Borislav Petkov <bp@suse.de> Cc: Markos Chandras <markos.chandras@imgtec.com> Cc: "Dmitry V. Levin" <ldv@altlinux.org> Cc: yu-cheng yu <yu-cheng.yu@intel.com> Cc: James Hogan <james.hogan@imgtec.com> Cc: Brian Gerst <brgerst@gmail.com> Cc: Johannes Berg <johannes@sipsolutions.net> Cc: Peter Zijlstra <peterz@infradead.org> Cc: Al Viro <viro@zeniv.linux.org.uk> Cc: Will Drewry <wad@chromium.org> Cc: Nikolay Martynov <mar.kolya@gmail.com> Cc: Huacai Chen <chenhc@lemote.com> Cc: "H. Peter Anvin" <hpa@zytor.com> Cc: Thomas Gleixner <tglx@linutronix.de> Cc: Daniel Borkmann <daniel@iogearbox.net> Cc: Leonid Yegoshin <Leonid.Yegoshin@imgtec.com> Cc: Rafal Milecki <zajec5@gmail.com> Cc: James Cowgill <James.Cowgill@imgtec.com> Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Cc: Ralf Baechle <ralf@linux-mips.org> Cc: Alex Smith <alex.smith@imgtec.com> Cc: Adam Buchbinder <adam.buchbinder@gmail.com> Cc: Qais Yousef <qais.yousef@imgtec.com> Cc: Jiang Liu <jiang.liu@linux.intel.com> Cc: Mikko Rapeli <mikko.rapeli@iki.fi> Cc: Paul Gortmaker <paul.gortmaker@windriver.com> Cc: Denys Vlasenko <dvlasenk@redhat.com> Cc: Brian Norris <computersforpeace@gmail.com> Cc: Hidehiro Kawai <hidehiro.kawai.ez@hitachi.com> Cc: "Luis R. Rodriguez" <mcgrof@do-not-panic.com> Cc: Andy Lutomirski <luto@amacapital.net> Cc: Ingo Molnar <mingo@redhat.com> Cc: Dave Hansen <dave.hansen@linux.intel.com> Cc: "Kirill A. Shutemov" <kirill.shutemov@linux.intel.com> Cc: Roland McGrath <roland@hack.frob.com> Cc: Paul Burton <paul.burton@imgtec.com> Cc: Kalle Valo <kvalo@qca.qualcomm.com> Cc: Viresh Kumar <viresh.kumar@linaro.org> Cc: Tony Wu <tung7970@gmail.com> Cc: Huaitong Han <huaitong.han@intel.com> Cc: Sumit Semwal <sumit.semwal@linaro.org> Cc: Alexei Starovoitov <ast@kernel.org> Cc: Juergen Gross <jgross@suse.com> Cc: Jason Cooper <jason@lakedaemon.net> Cc: "David S. Miller" <davem@davemloft.net> Cc: Oleg Nesterov <oleg@redhat.com> Cc: Andrea Gelmini <andrea.gelmini@gelma.net> Cc: David Woodhouse <dwmw2@infradead.org> Cc: Marc Zyngier <marc.zyngier@arm.com> Cc: Rabin Vincent <rabin@rab.in> Cc: "Maciej W. Rozycki" <macro@imgtec.com> Cc: David Daney <david.daney@cavium.com> Signed-off-by: Andrew Morton <akpm@linux-foundation.org> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2016-08-04 05:45:50 +09:00
if (IS_ENABLED(CONFIG_CPU_BIG_ENDIAN)) {
/*
* SOC-it swaps, or perhaps doesn't swap, when DMA'ing
* the last word of physical memory.
*/
physical_memsize -= PAGE_SIZE;
}
/* default to using all available RAM */
memsize = physical_memsize;
/* allow the user to override the usable memory */
for (i = 0; i < ARRAY_SIZE(var_names); i++) {
snprintf(param_name, sizeof(param_name), "%s=", var_names[i]);
var = strstr(arcs_cmdline, param_name);
if (!var)
continue;
memsize = memparse(var + strlen(param_name), NULL);
}
/* if the user says there's more RAM than we thought, believe them */
physical_memsize = max_t(unsigned long, physical_memsize, memsize);
MIPS: Malta: Use all available DDR by default Malta boards can have more than 256MB DDR available, but we have previously only made use of up to 256MB (ie. the DDR accessible via kseg0) by default, without the user manually specifying mem= kernel parameters. This patch causes all available DDR, as reported by the bootloader via the ememsize or memsize environment variables or optionally on the command line, to be used when possible without the user needing to manually provide the memory ranges. Malta now has 2 subtly different memory maps which have to be taken into account when setting this up. The original memory map (referred to by the code as v1) has up to 2GB of DDR aliased in both the upper & lower halves of the 32 bit physical address space, with a 256MB I/O region obscuring 0x10000000-0x1fffffff only in the lower alias. The revised v2 memory map is flat with up to 4GB DDR starting from 0x0, and the I/O region obscures 256MB of DDR which becomes inacessible. The memory map in use is indicated by a register provided by the rocit2 system controller, which is checked in order to set up the kernels memory ranges accordingly. Signed-off-by: Paul Burton <paul.burton@imgtec.com> Cc: Masahiro Yamada <yamada.masahiro@socionext.com> Cc: Kees Cook <keescook@chromium.org> Cc: Andrew Morton <akpm@linux-foundation.org> Cc: linux-mips@linux-mips.org Cc: linux-kernel@vger.kernel.org Patchwork: https://patchwork.linux-mips.org/patch/14273/ Signed-off-by: Ralf Baechle <ralf@linux-mips.org>
2016-09-20 06:21:22 +09:00
/* detect the memory map in use */
if (malta_scon() == MIPS_REVISION_SCON_ROCIT) {
/* ROCit has a register indicating the memory map in use */
config = readl((void __iomem *)CKSEG1ADDR(ROCIT_CONFIG_GEN1));
mem_map = config & ROCIT_CONFIG_GEN1_MEMMAP_MASK;
mem_map >>= ROCIT_CONFIG_GEN1_MEMMAP_SHIFT;
} else {
/* if not using ROCit, presume the v1 memory map */
mem_map = MEM_MAP_V1;
}
if (mem_map > MEM_MAP_V2)
panic("Unsupported physical memory map v%u detected",
(unsigned int)mem_map);
/* append memory to the DT */
mem_off = fdt_add_subnode(fdt, root_off, "memory");
if (mem_off < 0)
panic("Unable to add memory node to DT: %d", mem_off);
err = fdt_setprop_string(fdt, mem_off, "device_type", "memory");
if (err)
panic("Unable to set memory node device_type: %d", err);
MIPS: Malta: Use all available DDR by default Malta boards can have more than 256MB DDR available, but we have previously only made use of up to 256MB (ie. the DDR accessible via kseg0) by default, without the user manually specifying mem= kernel parameters. This patch causes all available DDR, as reported by the bootloader via the ememsize or memsize environment variables or optionally on the command line, to be used when possible without the user needing to manually provide the memory ranges. Malta now has 2 subtly different memory maps which have to be taken into account when setting this up. The original memory map (referred to by the code as v1) has up to 2GB of DDR aliased in both the upper & lower halves of the 32 bit physical address space, with a 256MB I/O region obscuring 0x10000000-0x1fffffff only in the lower alias. The revised v2 memory map is flat with up to 4GB DDR starting from 0x0, and the I/O region obscures 256MB of DDR which becomes inacessible. The memory map in use is indicated by a register provided by the rocit2 system controller, which is checked in order to set up the kernels memory ranges accordingly. Signed-off-by: Paul Burton <paul.burton@imgtec.com> Cc: Masahiro Yamada <yamada.masahiro@socionext.com> Cc: Kees Cook <keescook@chromium.org> Cc: Andrew Morton <akpm@linux-foundation.org> Cc: linux-mips@linux-mips.org Cc: linux-kernel@vger.kernel.org Patchwork: https://patchwork.linux-mips.org/patch/14273/ Signed-off-by: Ralf Baechle <ralf@linux-mips.org>
2016-09-20 06:21:22 +09:00
mem_entries = gen_fdt_mem_array(mem_array, physical_memsize, mem_map);
err = fdt_setprop(fdt, mem_off, "reg", mem_array,
mem_entries * 2 * sizeof(mem_array[0]));
if (err)
panic("Unable to set memory regs property: %d", err);
MIPS: Malta: Use all available DDR by default Malta boards can have more than 256MB DDR available, but we have previously only made use of up to 256MB (ie. the DDR accessible via kseg0) by default, without the user manually specifying mem= kernel parameters. This patch causes all available DDR, as reported by the bootloader via the ememsize or memsize environment variables or optionally on the command line, to be used when possible without the user needing to manually provide the memory ranges. Malta now has 2 subtly different memory maps which have to be taken into account when setting this up. The original memory map (referred to by the code as v1) has up to 2GB of DDR aliased in both the upper & lower halves of the 32 bit physical address space, with a 256MB I/O region obscuring 0x10000000-0x1fffffff only in the lower alias. The revised v2 memory map is flat with up to 4GB DDR starting from 0x0, and the I/O region obscures 256MB of DDR which becomes inacessible. The memory map in use is indicated by a register provided by the rocit2 system controller, which is checked in order to set up the kernels memory ranges accordingly. Signed-off-by: Paul Burton <paul.burton@imgtec.com> Cc: Masahiro Yamada <yamada.masahiro@socionext.com> Cc: Kees Cook <keescook@chromium.org> Cc: Andrew Morton <akpm@linux-foundation.org> Cc: linux-mips@linux-mips.org Cc: linux-kernel@vger.kernel.org Patchwork: https://patchwork.linux-mips.org/patch/14273/ Signed-off-by: Ralf Baechle <ralf@linux-mips.org>
2016-09-20 06:21:22 +09:00
mem_entries = gen_fdt_mem_array(mem_array, memsize, mem_map);
err = fdt_setprop(fdt, mem_off, "linux,usable-memory", mem_array,
mem_entries * 2 * sizeof(mem_array[0]));
if (err)
panic("Unable to set linux,usable-memory property: %d", err);
}
static void __init remove_gic(void *fdt)
{
int err, gic_off, i8259_off, cpu_off;
void __iomem *biu_base;
uint32_t cpu_phandle, sc_cfg;
/* if we have a CM which reports a GIC is present, leave the DT alone */
err = mips_cm_probe();
MIPS: CM: Use BIT/GENMASK for register fields, order & drop shifts There's no reason for us not to use BIT() & GENMASK() in asm/mips-cm.h when declaring macros corresponding to register fields. This patch modifies our definitions to do so. The *_SHF definitions are removed entirely - they duplicate information found in the masks, are infrequently used & can be replaced with use of __ffs() where needed. The *_MSK definitions then lose their _MSK suffix which is now somewhat redundant, and users are modified to match. The field definitions are moved to follow the appropriate register's accessor functions, which helps to keep the field definitions in order & to find the appropriate fields for a given register. Whilst here a comment is added describing each register & including its name, which is helpful both for linking the register back to hardware documentation & for grepping purposes. This also cleans up a couple of issues that became obvious as a result of making the changes described above: - We previously had definitions for GCR_Cx_RESET_EXT_BASE & a phony copy of that named GCR_RESET_EXT_BASE - a register which does not exist. The bad definitions were added by commit 497e803ebf98 ("MIPS: smp-cps: Ensure secondary cores start with EVA disabled") and made use of from boot_core(), which is now modified to use the GCR_Cx_RESET_EXT_BASE definitions. - We had a typo in CM_GCR_ERROR_CAUSE_ERRINGO_MSK - we now correctly define this as inFo rather than inGo. Now that we don't duplicate field information between _SHF & _MSK definitions, and keep the fields next to the register accessors, it will be much easier to spot & prevent any similar oddities being introduced in the future. Signed-off-by: Paul Burton <paul.burton@imgtec.com> Acked-by: Thomas Gleixner <tglx@linutronix.de Cc: linux-mips@linux-mips.org Patchwork: https://patchwork.linux-mips.org/patch/17001/ Patchwork: https://patchwork.linux-mips.org/patch/17216/ Signed-off-by: Ralf Baechle <ralf@linux-mips.org>
2017-08-13 11:49:27 +09:00
if (!err && (read_gcr_gic_status() & CM_GCR_GIC_STATUS_EX))
return;
if (malta_scon() == MIPS_REVISION_SCON_ROCIT) {
/*
* On systems using the RocIT system controller a GIC may be
* present without a CM. Detect whether that is the case.
*/
biu_base = ioremap_nocache(MSC01_BIU_REG_BASE,
MSC01_BIU_ADDRSPACE_SZ);
sc_cfg = __raw_readl(biu_base + MSC01_SC_CFG_OFS);
if (sc_cfg & MSC01_SC_CFG_GICPRES_MSK) {
/* enable the GIC at the system controller level */
sc_cfg |= BIT(MSC01_SC_CFG_GICENA_SHF);
__raw_writel(sc_cfg, biu_base + MSC01_SC_CFG_OFS);
return;
}
}
gic_off = fdt_node_offset_by_compatible(fdt, -1, "mti,gic");
if (gic_off < 0) {
pr_warn("malta-dtshim: unable to find DT GIC node: %d\n",
gic_off);
return;
}
err = fdt_nop_node(fdt, gic_off);
if (err)
pr_warn("malta-dtshim: unable to nop GIC node\n");
i8259_off = fdt_node_offset_by_compatible(fdt, -1, "intel,i8259");
if (i8259_off < 0) {
pr_warn("malta-dtshim: unable to find DT i8259 node: %d\n",
i8259_off);
return;
}
cpu_off = fdt_node_offset_by_compatible(fdt, -1,
"mti,cpu-interrupt-controller");
if (cpu_off < 0) {
pr_warn("malta-dtshim: unable to find CPU intc node: %d\n",
cpu_off);
return;
}
cpu_phandle = fdt_get_phandle(fdt, cpu_off);
if (!cpu_phandle) {
pr_warn("malta-dtshim: unable to get CPU intc phandle\n");
return;
}
err = fdt_setprop_u32(fdt, i8259_off, "interrupt-parent", cpu_phandle);
if (err) {
pr_warn("malta-dtshim: unable to set i8259 interrupt-parent: %d\n",
err);
return;
}
err = fdt_setprop_u32(fdt, i8259_off, "interrupts", 2);
if (err) {
pr_warn("malta-dtshim: unable to set i8259 interrupts: %d\n",
err);
return;
}
}
void __init *malta_dt_shim(void *fdt)
{
int root_off, len, err;
const char *compat;
if (fdt_check_header(fdt))
panic("Corrupt DT");
err = fdt_open_into(fdt, fdt_buf, sizeof(fdt_buf));
if (err)
panic("Unable to open FDT: %d", err);
root_off = fdt_path_offset(fdt_buf, "/");
if (root_off < 0)
panic("No / node in DT");
compat = fdt_getprop(fdt_buf, root_off, "compatible", &len);
if (!compat)
panic("No root compatible property in DT: %d", len);
/* if this isn't Malta, leave the DT alone */
if (strncmp(compat, "mti,malta", len))
return fdt;
append_memory(fdt_buf, root_off);
remove_gic(fdt_buf);
err = fdt_pack(fdt_buf);
if (err)
panic("Unable to pack FDT: %d\n", err);
return fdt_buf;
}