* [PATCH 06/16] ARM: STi: use generic API for enabling SCU
From: Pankaj Dubey @ 2016-11-14 5:02 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1479099731-28108-1-git-send-email-pankaj.dubey@samsung.com>
Now as we have of_scu_enable which takes care of mapping
scu base from DT, lets use it.
CC: Patrice Chotard <patrice.chotard@st.com>
Signed-off-by: Pankaj Dubey <pankaj.dubey@samsung.com>
---
arch/arm/mach-sti/platsmp.c | 9 +--------
1 file changed, 1 insertion(+), 8 deletions(-)
diff --git a/arch/arm/mach-sti/platsmp.c b/arch/arm/mach-sti/platsmp.c
index ea5a227..0bc7ff8 100644
--- a/arch/arm/mach-sti/platsmp.c
+++ b/arch/arm/mach-sti/platsmp.c
@@ -99,19 +99,12 @@ static int sti_boot_secondary(unsigned int cpu, struct task_struct *idle)
static void __init sti_smp_prepare_cpus(unsigned int max_cpus)
{
struct device_node *np;
- void __iomem *scu_base;
u32 __iomem *cpu_strt_ptr;
u32 release_phys;
int cpu;
unsigned long entry_pa = virt_to_phys(sti_secondary_startup);
- np = of_find_compatible_node(NULL, NULL, "arm,cortex-a9-scu");
-
- if (np) {
- scu_base = of_iomap(np, 0);
- scu_enable(scu_base);
- of_node_put(np);
- }
+ of_scu_enable();
if (max_cpus <= 1)
return;
--
2.7.4
^ permalink raw reply related
* [PATCH 07/16] ARM: ux500: use generic API for enabling SCU
From: Pankaj Dubey @ 2016-11-14 5:02 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1479099731-28108-1-git-send-email-pankaj.dubey@samsung.com>
Now as we have of_scu_enable which takes care of mapping
scu base from DT, lets use it.
CC: Linus Walleij <linus.walleij@linaro.org>
Signed-off-by: Pankaj Dubey <pankaj.dubey@samsung.com>
---
arch/arm/mach-ux500/platsmp.c | 20 +-------------------
1 file changed, 1 insertion(+), 19 deletions(-)
diff --git a/arch/arm/mach-ux500/platsmp.c b/arch/arm/mach-ux500/platsmp.c
index 8f2f615..e1927ae 100644
--- a/arch/arm/mach-ux500/platsmp.c
+++ b/arch/arm/mach-ux500/platsmp.c
@@ -66,28 +66,10 @@ static void wakeup_secondary(void)
static void __init ux500_smp_prepare_cpus(unsigned int max_cpus)
{
- struct device_node *np;
- static void __iomem *scu_base;
- unsigned int ncores;
- int i;
-
- np = of_find_compatible_node(NULL, NULL, "arm,cortex-a9-scu");
- if (!np) {
- pr_err("No SCU base address\n");
- return;
- }
- scu_base = of_iomap(np, 0);
- of_node_put(np);
- if (!scu_base) {
+ if (of_scu_enable()) {
pr_err("No SCU remap\n");
return;
}
-
- scu_enable(scu_base);
- ncores = scu_get_core_count(scu_base);
- for (i = 0; i < ncores; i++)
- set_cpu_possible(i, true);
- iounmap(scu_base);
}
static int ux500_boot_secondary(unsigned int cpu, struct task_struct *idle)
--
2.7.4
^ permalink raw reply related
* [PATCH 08/16] ARM: vexpress: use generic API for enabling SCU
From: Pankaj Dubey @ 2016-11-14 5:02 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1479099731-28108-1-git-send-email-pankaj.dubey@samsung.com>
Now as we have of_scu_enable which takes care of mapping
scu base from DT, lets use it.
CC: Liviu Dudau <liviu.dudau@arm.com>
CC: Sudeep Holla <sudeep.holla@arm.com>
CC: Lorenzo Pieralisi <lorenzo.pieralisi@arm.com>
Signed-off-by: Pankaj Dubey <pankaj.dubey@samsung.com>
---
arch/arm/mach-vexpress/platsmp.c | 13 +------------
1 file changed, 1 insertion(+), 12 deletions(-)
diff --git a/arch/arm/mach-vexpress/platsmp.c b/arch/arm/mach-vexpress/platsmp.c
index 8b8d072..17dee2b 100644
--- a/arch/arm/mach-vexpress/platsmp.c
+++ b/arch/arm/mach-vexpress/platsmp.c
@@ -41,20 +41,9 @@ bool __init vexpress_smp_init_ops(void)
return false;
}
-static const struct of_device_id vexpress_smp_dt_scu_match[] __initconst = {
- { .compatible = "arm,cortex-a5-scu", },
- { .compatible = "arm,cortex-a9-scu", },
- {}
-};
-
static void __init vexpress_smp_dt_prepare_cpus(unsigned int max_cpus)
{
- struct device_node *scu = of_find_matching_node(NULL,
- vexpress_smp_dt_scu_match);
-
- if (scu)
- scu_enable(of_iomap(scu, 0));
-
+ of_scu_enable();
/*
* Write the address of secondary startup into the
* system-wide flags register. The boot monitor waits
--
2.7.4
^ permalink raw reply related
* [PATCH 09/16] ARM: BCM: use generic API for enabling SCU
From: Pankaj Dubey @ 2016-11-14 5:02 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1479099731-28108-1-git-send-email-pankaj.dubey@samsung.com>
Now as we have of_scu_enable which takes care of mapping
scu base from DT, lets use it.
CC: Florian Fainelli <f.fainelli@gmail.com>
CC: Ray Jui <rjui@broadcom.com>
CC: Scott Branden <sbranden@broadcom.com>
CC: bcm-kernel-feedback-list at broadcom.com
Signed-off-by: Pankaj Dubey <pankaj.dubey@samsung.com>
---
arch/arm/mach-bcm/bcm63xx_smp.c | 18 ++--------------
arch/arm/mach-bcm/platsmp.c | 46 +----------------------------------------
2 files changed, 3 insertions(+), 61 deletions(-)
diff --git a/arch/arm/mach-bcm/bcm63xx_smp.c b/arch/arm/mach-bcm/bcm63xx_smp.c
index 9b6727e..a4c6ecd 100644
--- a/arch/arm/mach-bcm/bcm63xx_smp.c
+++ b/arch/arm/mach-bcm/bcm63xx_smp.c
@@ -20,9 +20,6 @@
#include "bcm63xx_smp.h"
-/* Size of mapped Cortex A9 SCU address space */
-#define CORTEX_A9_SCU_SIZE 0x58
-
/*
* Enable the Cortex A9 Snoop Control Unit
*
@@ -35,7 +32,6 @@
*/
static int __init scu_a9_enable(void)
{
- unsigned long config_base;
void __iomem *scu_base;
unsigned int i, ncores;
@@ -44,19 +40,9 @@ static int __init scu_a9_enable(void)
return -ENXIO;
}
- /* Config base address register value is zero for uniprocessor */
- config_base = scu_a9_get_base();
- if (!config_base) {
- pr_err("hardware reports only one core\n");
- return -ENOENT;
- }
-
- scu_base = ioremap((phys_addr_t)config_base, CORTEX_A9_SCU_SIZE);
- if (!scu_base) {
- pr_err("failed to remap config base (%lu/%u) for SCU\n",
- config_base, CORTEX_A9_SCU_SIZE);
+ scu_base = of_scu_get_base();
+ if (IS_ERR(scu_base))
return -ENOMEM;
- }
scu_enable(scu_base);
diff --git a/arch/arm/mach-bcm/platsmp.c b/arch/arm/mach-bcm/platsmp.c
index 3ac3a9b..743599a 100644
--- a/arch/arm/mach-bcm/platsmp.c
+++ b/arch/arm/mach-bcm/platsmp.c
@@ -28,9 +28,6 @@
#include <asm/smp_plat.h>
#include <asm/smp_scu.h>
-/* Size of mapped Cortex A9 SCU address space */
-#define CORTEX_A9_SCU_SIZE 0x58
-
#define SECONDARY_TIMEOUT_NS NSEC_PER_MSEC /* 1 msec (in nanoseconds) */
#define BOOT_ADDR_CPUID_MASK 0x3
@@ -38,47 +35,6 @@
#define OF_SECONDARY_BOOT "secondary-boot-reg"
#define MPIDR_CPUID_BITMASK 0x3
-/*
- * Enable the Cortex A9 Snoop Control Unit
- *
- * By the time this is called we already know there are multiple
- * cores present. We assume we're running on a Cortex A9 processor,
- * so any trouble getting the base address register or getting the
- * SCU base is a problem.
- *
- * Return 0 if successful or an error code otherwise.
- */
-static int __init scu_a9_enable(void)
-{
- unsigned long config_base;
- void __iomem *scu_base;
-
- if (!scu_a9_has_base()) {
- pr_err("no configuration base address register!\n");
- return -ENXIO;
- }
-
- /* Config base address register value is zero for uniprocessor */
- config_base = scu_a9_get_base();
- if (!config_base) {
- pr_err("hardware reports only one core\n");
- return -ENOENT;
- }
-
- scu_base = ioremap((phys_addr_t)config_base, CORTEX_A9_SCU_SIZE);
- if (!scu_base) {
- pr_err("failed to remap config base (%lu/%u) for SCU\n",
- config_base, CORTEX_A9_SCU_SIZE);
- return -ENOMEM;
- }
-
- scu_enable(scu_base);
-
- iounmap(scu_base); /* That's the last we'll need of this */
-
- return 0;
-}
-
static u32 secondary_boot_addr_for(unsigned int cpu)
{
u32 secondary_boot_addr = 0;
@@ -134,7 +90,7 @@ static void __init bcm_smp_prepare_cpus(unsigned int max_cpus)
const cpumask_t only_cpu_0 = { CPU_BITS_CPU0 };
/* Enable the SCU on Cortex A9 based SoCs */
- if (scu_a9_enable()) {
+ if (of_scu_enable()) {
/* Update the CPU present map to reflect uniprocessor mode */
pr_warn("failed to enable A9 SCU - disabling SMP\n");
init_cpu_present(&only_cpu_0);
--
2.7.4
^ permalink raw reply related
* [PATCH 10/16] ARM: tegra: use generic API for enabling SCU
From: Pankaj Dubey @ 2016-11-14 5:02 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1479099731-28108-1-git-send-email-pankaj.dubey@samsung.com>
Now as we have of_scu_enable which takes care of mapping
scu base from DT, lets use it.
CC: Stephen Warren <swarren@wwwdotorg.org>
CC: linux-tegra at vger.kernel.org
Signed-off-by: Pankaj Dubey <pankaj.dubey@samsung.com>
---
arch/arm/mach-tegra/platsmp.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/arch/arm/mach-tegra/platsmp.c b/arch/arm/mach-tegra/platsmp.c
index 75620ae..3467617 100644
--- a/arch/arm/mach-tegra/platsmp.c
+++ b/arch/arm/mach-tegra/platsmp.c
@@ -179,7 +179,7 @@ static void __init tegra_smp_prepare_cpus(unsigned int max_cpus)
cpumask_set_cpu(0, &tegra_cpu_init_mask);
if (scu_a9_has_base())
- scu_enable(IO_ADDRESS(scu_a9_get_base()));
+ of_scu_enable();
}
const struct smp_operations tegra_smp_ops __initconst = {
--
2.7.4
^ permalink raw reply related
* [PATCH 11/16] ARM: rockchip: use generic API for enabling SCU
From: Pankaj Dubey @ 2016-11-14 5:02 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1479099731-28108-1-git-send-email-pankaj.dubey@samsung.com>
Now as we have of_scu_enable which takes care of mapping
scu base from DT, lets use it.
CC: Heiko Stuebner <heiko@sntech.de>
CC: linux-rockchip at lists.infradead.org
Signed-off-by: Pankaj Dubey <pankaj.dubey@samsung.com>
---
arch/arm/mach-rockchip/platsmp.c | 12 +++---------
1 file changed, 3 insertions(+), 9 deletions(-)
diff --git a/arch/arm/mach-rockchip/platsmp.c b/arch/arm/mach-rockchip/platsmp.c
index 4d827a0..31169cf 100644
--- a/arch/arm/mach-rockchip/platsmp.c
+++ b/arch/arm/mach-rockchip/platsmp.c
@@ -282,21 +282,15 @@ static void __init rockchip_smp_prepare_cpus(unsigned int max_cpus)
if (has_pmu && rockchip_smp_prepare_pmu())
return;
- if (read_cpuid_part() == ARM_CPU_PART_CORTEX_A9) {
+ if (scu_a9_has_base()) {
if (rockchip_smp_prepare_sram(node))
return;
/* enable the SCU power domain */
pmu_set_power_domain(PMU_PWRDN_SCU, true);
- node = of_find_compatible_node(NULL, NULL, "arm,cortex-a9-scu");
- if (!node) {
- pr_err("%s: missing scu\n", __func__);
- return;
- }
-
- scu_base_addr = of_iomap(node, 0);
- if (!scu_base_addr) {
+ scu_base_addr = of_scu_get_base();
+ if (IS_ERR(scu_base_addr)) {
pr_err("%s: could not map scu registers\n", __func__);
return;
}
--
2.7.4
^ permalink raw reply related
* [PATCH 12/16] ARM: imx: use generic API for enabling SCU
From: Pankaj Dubey @ 2016-11-14 5:02 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1479099731-28108-1-git-send-email-pankaj.dubey@samsung.com>
Now as we have of_scu_enable which takes care of mapping
scu base from DT, lets use it.
At the same time this patch cleans up mach-imx platform files by
removing static mapping of SCU and dropping imx_scu_map_io function.
CC: Shawn Guo <shawnguo@kernel.org>
CC: Sascha Hauer <kernel@pengutronix.de>
Signed-off-by: Pankaj Dubey <pankaj.dubey@samsung.com>
---
arch/arm/mach-imx/common.h | 5 -----
arch/arm/mach-imx/mach-imx6q.c | 8 +-------
arch/arm/mach-imx/platsmp.c | 32 +++++---------------------------
arch/arm/mach-imx/pm-imx6.c | 3 ++-
4 files changed, 8 insertions(+), 40 deletions(-)
diff --git a/arch/arm/mach-imx/common.h b/arch/arm/mach-imx/common.h
index c4436d9..9787d5f 100644
--- a/arch/arm/mach-imx/common.h
+++ b/arch/arm/mach-imx/common.h
@@ -87,11 +87,6 @@ u32 imx_get_cpu_arg(int cpu);
void imx_set_cpu_arg(int cpu, u32 arg);
#ifdef CONFIG_SMP
void v7_secondary_startup(void);
-void imx_scu_map_io(void);
-void imx_smp_prepare(void);
-#else
-static inline void imx_scu_map_io(void) {}
-static inline void imx_smp_prepare(void) {}
#endif
void imx_src_init(void);
void imx_gpc_pre_suspend(bool arm_power_off);
diff --git a/arch/arm/mach-imx/mach-imx6q.c b/arch/arm/mach-imx/mach-imx6q.c
index 45801b2..1c6cc9f 100644
--- a/arch/arm/mach-imx/mach-imx6q.c
+++ b/arch/arm/mach-imx/mach-imx6q.c
@@ -383,12 +383,6 @@ static void __init imx6q_init_late(void)
}
}
-static void __init imx6q_map_io(void)
-{
- debug_ll_io_init();
- imx_scu_map_io();
-}
-
static void __init imx6q_init_irq(void)
{
imx_gpc_check_dt();
@@ -410,7 +404,7 @@ DT_MACHINE_START(IMX6Q, "Freescale i.MX6 Quad/DualLite (Device Tree)")
.l2c_aux_val = 0,
.l2c_aux_mask = ~0,
.smp = smp_ops(imx_smp_ops),
- .map_io = imx6q_map_io,
+ .map_io = debug_ll_io_init,
.init_irq = imx6q_init_irq,
.init_machine = imx6q_init_machine,
.init_late = imx6q_init_late,
diff --git a/arch/arm/mach-imx/platsmp.c b/arch/arm/mach-imx/platsmp.c
index 711dbbd..c032369 100644
--- a/arch/arm/mach-imx/platsmp.c
+++ b/arch/arm/mach-imx/platsmp.c
@@ -26,26 +26,6 @@
u32 g_diag_reg;
static void __iomem *scu_base;
-static struct map_desc scu_io_desc __initdata = {
- /* .virtual and .pfn are run-time assigned */
- .length = SZ_4K,
- .type = MT_DEVICE,
-};
-
-void __init imx_scu_map_io(void)
-{
- unsigned long base;
-
- /* Get SCU base */
- asm("mrc p15, 4, %0, c15, c0, 0" : "=r" (base));
-
- scu_io_desc.virtual = IMX_IO_P2V(base);
- scu_io_desc.pfn = __phys_to_pfn(base);
- iotable_init(&scu_io_desc, 1);
-
- scu_base = IMX_IO_ADDRESS(base);
-}
-
static int imx_boot_secondary(unsigned int cpu, struct task_struct *idle)
{
imx_set_cpu_jump(cpu, v7_secondary_startup);
@@ -61,20 +41,18 @@ static void __init imx_smp_init_cpus(void)
{
int i, ncores;
- ncores = scu_get_core_count(scu_base);
+ if (!IS_ERR(scu_base))
+ ncores = scu_get_core_count(scu_base);
for (i = ncores; i < NR_CPUS; i++)
set_cpu_possible(i, false);
}
-void imx_smp_prepare(void)
-{
- scu_enable(scu_base);
-}
-
static void __init imx_smp_prepare_cpus(unsigned int max_cpus)
{
- imx_smp_prepare();
+ scu_base = of_scu_get_base();
+ if (!IS_ERR(scu_base))
+ scu_enable(scu_base);
/*
* The diagnostic register holds the errata bits. Mostly bootloader
diff --git a/arch/arm/mach-imx/pm-imx6.c b/arch/arm/mach-imx/pm-imx6.c
index 1515e49..859aacb 100644
--- a/arch/arm/mach-imx/pm-imx6.c
+++ b/arch/arm/mach-imx/pm-imx6.c
@@ -26,6 +26,7 @@
#include <asm/fncpy.h>
#include <asm/proc-fns.h>
#include <asm/suspend.h>
+#include <asm/smp_scu.h>
#include <asm/tlb.h>
#include "common.h"
@@ -393,7 +394,7 @@ static int imx6q_pm_enter(suspend_state_t state)
/* Zzz ... */
cpu_suspend(0, imx6q_suspend_finish);
if (cpu_is_imx6q() || cpu_is_imx6dl())
- imx_smp_prepare();
+ of_scu_enable();
imx_anatop_post_resume();
imx_gpc_post_resume();
imx6_enable_rbc(false);
--
2.7.4
^ permalink raw reply related
* [PATCH 13/16] ARM: zynq: use generic API for enabling SCU
From: Pankaj Dubey @ 2016-11-14 5:02 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1479099731-28108-1-git-send-email-pankaj.dubey@samsung.com>
Now as we have of_scu_enable which takes care of mapping
scu base from DT, lets use it.
At the same time this patch cleans up mach-zynq platform files by
removing static mapping of SCU and dropping zynq_scu_map_io and zynq_map_io
functions.
CC: Michal Simek <michal.simek@xilinx.com>
Signed-off-by: Pankaj Dubey <pankaj.dubey@samsung.com>
---
arch/arm/mach-zynq/common.c | 32 +-------------------------------
arch/arm/mach-zynq/common.h | 2 --
arch/arm/mach-zynq/platsmp.c | 2 ++
3 files changed, 3 insertions(+), 33 deletions(-)
diff --git a/arch/arm/mach-zynq/common.c b/arch/arm/mach-zynq/common.c
index d12002c..3986b2b 100644
--- a/arch/arm/mach-zynq/common.c
+++ b/arch/arm/mach-zynq/common.c
@@ -38,7 +38,6 @@
#include <asm/mach-types.h>
#include <asm/page.h>
#include <asm/pgtable.h>
-#include <asm/smp_scu.h>
#include <asm/system_info.h>
#include <asm/hardware/cache-l2x0.h>
@@ -48,8 +47,6 @@
#define ZYNQ_DEVCFG_PS_VERSION_SHIFT 28
#define ZYNQ_DEVCFG_PS_VERSION_MASK 0xF
-void __iomem *zynq_scu_base;
-
/**
* zynq_memory_init - Initialize special memory
*
@@ -153,33 +150,6 @@ static void __init zynq_timer_init(void)
clocksource_probe();
}
-static struct map_desc zynq_cortex_a9_scu_map __initdata = {
- .length = SZ_256,
- .type = MT_DEVICE,
-};
-
-static void __init zynq_scu_map_io(void)
-{
- unsigned long base;
-
- base = scu_a9_get_base();
- zynq_cortex_a9_scu_map.pfn = __phys_to_pfn(base);
- /* Expected address is in vmalloc area that's why simple assign here */
- zynq_cortex_a9_scu_map.virtual = base;
- iotable_init(&zynq_cortex_a9_scu_map, 1);
- zynq_scu_base = (void __iomem *)base;
- BUG_ON(!zynq_scu_base);
-}
-
-/**
- * zynq_map_io - Create memory mappings needed for early I/O.
- */
-static void __init zynq_map_io(void)
-{
- debug_ll_io_init();
- zynq_scu_map_io();
-}
-
static void __init zynq_irq_init(void)
{
zynq_early_slcr_init();
@@ -196,7 +166,7 @@ DT_MACHINE_START(XILINX_EP107, "Xilinx Zynq Platform")
.l2c_aux_val = 0x00400000,
.l2c_aux_mask = 0xffbfffff,
.smp = smp_ops(zynq_smp_ops),
- .map_io = zynq_map_io,
+ .map_io = debug_ll_io_init,
.init_irq = zynq_irq_init,
.init_machine = zynq_init_machine,
.init_late = zynq_init_late,
diff --git a/arch/arm/mach-zynq/common.h b/arch/arm/mach-zynq/common.h
index e771933..7c2f008 100644
--- a/arch/arm/mach-zynq/common.h
+++ b/arch/arm/mach-zynq/common.h
@@ -33,8 +33,6 @@ extern int zynq_cpun_start(u32 address, int cpu);
extern const struct smp_operations zynq_smp_ops;
#endif
-extern void __iomem *zynq_scu_base;
-
void zynq_pm_late_init(void);
static inline void zynq_core_pm_init(void)
diff --git a/arch/arm/mach-zynq/platsmp.c b/arch/arm/mach-zynq/platsmp.c
index 7cd9865..2d09119 100644
--- a/arch/arm/mach-zynq/platsmp.c
+++ b/arch/arm/mach-zynq/platsmp.c
@@ -33,6 +33,7 @@
* be called from zynq_cpun_start() because it is not in __init section.
*/
static int ncores;
+static void __iomem *zynq_scu_base;
int zynq_cpun_start(u32 address, int cpu)
{
@@ -108,6 +109,7 @@ static void __init zynq_smp_init_cpus(void)
static void __init zynq_smp_prepare_cpus(unsigned int max_cpus)
{
+ zynq_scu_base = of_scu_get_base();
scu_enable(zynq_scu_base);
}
--
2.7.4
^ permalink raw reply related
* [PATCH 14/16] ARM: hisi: use generic API for enabling SCU
From: Pankaj Dubey @ 2016-11-14 5:02 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1479099731-28108-1-git-send-email-pankaj.dubey@samsung.com>
Now as we have of_scu_enable which takes care of mapping
scu base from DT, lets use it.
CC: Wei Xu <xuwei5@hisilicon.com>
Signed-off-by: Pankaj Dubey <pankaj.dubey@samsung.com>
---
arch/arm/mach-hisi/platsmp.c | 24 +++++-------------------
1 file changed, 5 insertions(+), 19 deletions(-)
diff --git a/arch/arm/mach-hisi/platsmp.c b/arch/arm/mach-hisi/platsmp.c
index e1d6764..425a291 100644
--- a/arch/arm/mach-hisi/platsmp.c
+++ b/arch/arm/mach-hisi/platsmp.c
@@ -39,29 +39,14 @@ int hi3xxx_get_cpu_jump(int cpu)
return readl_relaxed(ctrl_base + ((cpu - 1) << 2));
}
-static void __init hisi_enable_scu_a9(void)
-{
- unsigned long base = 0;
- void __iomem *scu_base = NULL;
-
- if (scu_a9_has_base()) {
- base = scu_a9_get_base();
- scu_base = ioremap(base, SZ_4K);
- if (!scu_base) {
- pr_err("ioremap(scu_base) failed\n");
- return;
- }
- scu_enable(scu_base);
- iounmap(scu_base);
- }
-}
-
static void __init hi3xxx_smp_prepare_cpus(unsigned int max_cpus)
{
struct device_node *np = NULL;
u32 offset = 0;
- hisi_enable_scu_a9();
+ if (scu_a9_has_base())
+ of_scu_enable();
+
if (!ctrl_base) {
np = of_find_compatible_node(NULL, NULL, "hisilicon,sysctrl");
if (!np) {
@@ -100,7 +85,8 @@ static const struct smp_operations hi3xxx_smp_ops __initconst = {
static void __init hisi_common_smp_prepare_cpus(unsigned int max_cpus)
{
- hisi_enable_scu_a9();
+ if (scu_a9_has_base())
+ of_scu_enable();
}
static void hix5hd2_set_scu_boot_addr(phys_addr_t start_addr, phys_addr_t jump_addr)
--
2.7.4
^ permalink raw reply related
* [PATCH 15/16] ARM: mvebu: use generic API for enabling SCU
From: Pankaj Dubey @ 2016-11-14 5:02 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1479099731-28108-1-git-send-email-pankaj.dubey@samsung.com>
Now as we have of_scu_enable which takes care of mapping
scu base from DT, lets use it.
CC: Jason Cooper <jason@lakedaemon.net>
CC: Andrew Lunn <andrew@lunn.ch>
CC: Gregory Clement <gregory.clement@free-electrons.com>
CC: Sebastian Hesselbarth <sebastian.hesselbarth@gmail.com>
Signed-off-by: Pankaj Dubey <pankaj.dubey@samsung.com>
---
arch/arm/mach-mvebu/board-v7.c | 8 ++------
1 file changed, 2 insertions(+), 6 deletions(-)
diff --git a/arch/arm/mach-mvebu/board-v7.c b/arch/arm/mach-mvebu/board-v7.c
index ccca951..d7014a3 100644
--- a/arch/arm/mach-mvebu/board-v7.c
+++ b/arch/arm/mach-mvebu/board-v7.c
@@ -41,13 +41,9 @@ static void __iomem *scu_base;
*/
static void __init mvebu_scu_enable(void)
{
- struct device_node *np =
- of_find_compatible_node(NULL, NULL, "arm,cortex-a9-scu");
- if (np) {
- scu_base = of_iomap(np, 0);
+ scu_base = of_scu_get_base();
+ if (!IS_ERR(scu_base))
scu_enable(scu_base);
- of_node_put(np);
- }
}
void __iomem *mvebu_get_scu_base(void)
--
2.7.4
^ permalink raw reply related
* [PATCH 16/16] ARM: zx: use generic API for enabling SCU
From: Pankaj Dubey @ 2016-11-14 5:02 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1479099731-28108-1-git-send-email-pankaj.dubey@samsung.com>
Now as we have of_scu_enable which takes care of mapping
scu base from DT, lets use it.
CC: Jun Nie <jun.nie@linaro.org>
Signed-off-by: Pankaj Dubey <pankaj.dubey@samsung.com>
---
arch/arm/mach-zx/platsmp.c | 6 ++----
1 file changed, 2 insertions(+), 4 deletions(-)
diff --git a/arch/arm/mach-zx/platsmp.c b/arch/arm/mach-zx/platsmp.c
index 0297f92..2788c34 100644
--- a/arch/arm/mach-zx/platsmp.c
+++ b/arch/arm/mach-zx/platsmp.c
@@ -44,13 +44,11 @@ static void __iomem *scu_base;
void __init zx_smp_prepare_cpus(unsigned int max_cpus)
{
struct device_node *np;
- unsigned long base = 0;
void __iomem *aonsysctrl_base;
void __iomem *sys_iram;
- base = scu_a9_get_base();
- scu_base = ioremap(base, SZ_256);
- if (!scu_base) {
+ scu_base = of_scu_get_base();
+ if (IS_ERR(scu_base)) {
pr_err("%s: failed to map scu\n", __func__);
return;
}
--
2.7.4
^ permalink raw reply related
* [PATCH v1] ARM:dmaengine:sun6i:fix the uninitialized value for v_lli
From: Vinod Koul @ 2016-11-14 5:06 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161102053112.GA8109@arx-xi>
On Wed, Nov 02, 2016 at 01:31:12PM +0800, Axl-zhang wrote:
> dma_pool_alloc does not initialize the value of the newly allocated
> block for the v_lli, and the uninitilize value make the tests failed
> which is on pine64 with dmatest.
> we can fix it just change the "|=" to "=" for the v_lli->cfg.
Applied after fixing the title. We dont need ARM.
Also spaces after each tag please..
--
~Vinod
^ permalink raw reply
* [PATCH v10 03/11] remoteproc: Update Kconfig setup to 'depends on REMOTEPROC'
From: Vinod Koul @ 2016-11-14 5:12 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161103212439.GS25787@tuxbot>
On Thu, Nov 03, 2016 at 02:24:39PM -0700, Bjorn Andersson wrote:
> On Sat 08 Oct 05:52 PDT 2016, Peter Griffin wrote:
>
> > Make REMOTEPROC core a selectable kconfig option, and update
> > remoteproc client drivers to 'depends on' the core. This avoids
> > some nasty Kconfig recursive dependency issues. Also when using
> > menuconfig client drivers will be hidden until the core has been
> > enabled.
> >
> > Documentation/kbuild/kconfig-language.txt:
> >
> > Note:
> > select should be used with care. select will force
> > a symbol to a value without visiting the dependencies.
> > By abusing select you are able to select a symbol FOO even
> > if FOO depends on BAR that is not set.
> > In general use select only for non-visible symbols
> > (no prompts anywhere) and for symbols with no dependencies.
> > That will limit the usefulness but on the other hand avoid
> > the illegal configurations all over.
> >
> > Signed-off-by: Peter Griffin <peter.griffin@linaro.org>
>
> Sorry, I missed this patch in the set - but spotted it in linux-next.
>
> I still don't like the change, but remoteproc has dependencies so I
> guess I have to pick it until we fix that.
>
> It's however not okay to take this patch through the DMA tree, as it
> effectively stops me from introducing any changes in the rproc tree.
> Further more, it's not based on v4.9, so it currently introduces another
> Kconfig dependency problem - that I can't fix in my tree without
> conflicting with Vinod's.
>
>
> So, Vinod, can you please drop this patch from your tree? I'll pick it
> up for now.
Sorry for the delay, b/w KS/LPC and travel, was slow on email.
I have dropped this one now..
--
~Vinod
^ permalink raw reply
* [PATCH v10 01/11] remoteproc: st_slim_rproc: add a slimcore rproc driver
From: Vinod Koul @ 2016-11-14 5:18 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161107135735.GA27280@griffinp-ThinkPad-X1-Carbon-2nd>
On Mon, Nov 07, 2016 at 01:57:35PM +0000, Peter Griffin wrote:
> >
> > As you now make changes to the entire remoteproc Kconfig file, rather
> > than simply add a Kconfig symbol we can't bring this in via Vinod's tree
> > without providing Linus with a messy merge conflict.
> >
> > So the remoteproc parts now has to go through my tree.
>
> OK, I think the best approach is for Vinod to create an immutable
> branch with the entire fdma series on, and then both of you merge that branch into
> your respective trees.
my topic/st_fdma is immutable branch. You cna merge it, if you need a signed
tag, please do let me know
>
> That way there won't be any conflicts and you can both accept further changes
> for v4.9 release. Trying to take half the series via rproc, and half via dma trees won't work
> because they have dependencies on each other.
>
> I will send a v11 series in a moment which includes the feedback in this email
> and also include the additional fixes which Vinod has applied since the driver
> has been in linux-next.
WHY.. Stuff is already merged twice! Please send updated on top of already
merged code! This is how kernel developement is done...
--
~Vinod
^ permalink raw reply
* [PATCH v11 00/14] Add support for FDMA DMA controller and slim core rproc found on STi chipsets
From: Vinod Koul @ 2016-11-14 5:19 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1478542665-17089-1-git-send-email-peter.griffin@linaro.org>
On Mon, Nov 07, 2016 at 06:17:31PM +0000, Peter Griffin wrote:
> Hi Vinod and Bjorn,
>
> This patchset adds support for the Flexible Direct Memory Access (FDMA) core
> found on STi chipsets from STMicroelectronics. The FDMA is a slim core CPU
> with a dedicated firmware. It is a general purpose DMA controller supporting
> 16 independent channels and data can be moved from memory to memory or between
> memory and paced latency critical real time targets.
>
> In reponse to Bjorn latest mail here https://lkml.org/lkml/2016/11/7/425 and
> here https://patchwork.kernel.org/patch/9368157/ I have created a v11
> incorporating the minor API update, and removed the unrelated change.
>
> As tthis series has been in linux-next for a while, some additional fixes
> have been submitted and applied by Vinod. I have included these as part of
> the v11 series as well.
>
> I believe the best route as described here
> https://www.spinics.net/lists/arm-kernel/msg541026.htmlforward is for Vinod
> to apply the whole series on an immutable branch which is then merged into
> both the dma and remoteproc trees.
As I said earlier and just to make it clear, am not taking this one. Please
send updates on top of already applied stuff
--
~Vinod
^ permalink raw reply
* [PATCH v3 1/3] Documentation: DT: add dma compatible for sun50i A64 SOC.
From: Vinod Koul @ 2016-11-14 5:22 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161107181457.GA3619@arx12>
On Tue, Nov 08, 2016 at 02:14:57AM +0800, Hao Zhang wrote:
> This adds documentation of the sun50i a64 dma binding compatible.
Please send a cover letter for patch series, and please post the series as a
thread (hint: git send-email does that quite well).
Lastly where is patch2/3??
--
~Vinod
^ permalink raw reply
* [PATCH V4] ARM: dts: imx6: Add support for Logic PD SOM and Baseboard
From: Shawn Guo @ 2016-11-14 5:27 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1478609017-2415-1-git-send-email-aford173@gmail.com>
On Tue, Nov 08, 2016 at 06:43:37AM -0600, aford173 at gmail.com wrote:
> From: Adam Ford <aford173@gmail.com>
>
> The system on module (SOM) specific portions are in the .dtsi
> while the baseboard specific portions are in the .dts file.
>
> V4: Forgot to fix the Wlcore property list and child node
> V3: Forgot to remove push buttons in V2, and change the
> enable-sdio-wakup to wakeup-source
> V2: Fix small bug and update style for 4.9 Kernel
>
> Signed-off-by: Adam Ford <aford173@gmail.com>
<snip>
> + leds {
> + compatible = "gpio-leds";
> +
> + gen_led0 {
Please use hyphen instead of underscore in node name.
> + label = "cpu0";
> + gpios = <&gpio3 19 GPIO_ACTIVE_HIGH>;
> + linux,default-trigger = "cpu0";
> + };
> +
> + gen_led1 {
> + label = "cpu1";
> + gpios = <&gpio3 20 GPIO_ACTIVE_HIGH>;
> + linux,default-trigger = "cpu1";
> + };
> +
> + gen_led2 {
> + label = "heartbeat";
> + gpios = <&gpio3 21 GPIO_ACTIVE_HIGH>;
> + linux,default-trigger = "heartbeat";
> + };
> +
> + gen_led3 {
> + label = "Always On";
> + gpios = <&gpio3 22 GPIO_ACTIVE_HIGH>;
> + linux,default-trigger = "default-on";
> + };
> + };
<snip>
> + backlight_lcd: backlight-lcd {
> + compatible = "pwm-backlight";
> + pinctrl-names = "default";
> + pinctrl-0 = <&pinctrl_backlight>;
> + enable-gpios = <&gpio2 10 GPIO_ACTIVE_HIGH>;
> + pwms = <&pwm3 0 5000000>;
> + brightness-levels = <0 4 8 16 32 64 128 255>;
> + default-brightness-level = <6>;
> + };
> +
> +
One newline is enough.
> + lcd_display: display at di0 {
> + compatible = "fsl,imx-parallel-display";
> + #address-cells = <1>;
> + #size-cells = <0>;
> + interface-pix-fmt = "rgb565";
> + pinctrl-names = "default";
> + pinctrl-0 = <&pinctrl_lcd>;
> + status = "okay";
> +
> + display-timings {
> + native-mode = <&type15_timing>;
Have a newline between property list and child node.
> + type15_timing: type_15 {
Can we have a better node name for this? Also hyphen should be used in
node name.
> + clock-frequency = <9000000>;
> + hactive = <480>;
> + vactive = <272>;
> + hfront-porch = <3>;
> + hback-porch = <2>;
> + hsync-len = <42>;
> + vback-porch = <3>;
> + vfront-porch = <2>;
> + vsync-len = <11>;
> + hsync-active = <1>;
> + vsync-active = <1>;
> + de-active = <1>;
> + pixelclk-active = <0>;
> + };
> + };
> +
> + port at 0 {
> + reg = <0>;
> + display_in: endpoint {
> + remote-endpoint = <&ipu1_di0_disp0>;
> + };
> + };
> +
> + port at 1 {
> + reg = <1>;
> + display_out: endpoint {
> + remote-endpoint = <&panel_in>;
> + };
> + };
> + };
> +
> + panel: panel {
> + compatible = "innolux,at043tn24", "simple-panel";
> + enable-gpios = <&gpio4 17 GPIO_ACTIVE_HIGH>;
> + backlight = <&backlight_lcd>;
Have a newline between property list and child node.
> + port {
> + panel_in: endpoint {
> + remote-endpoint = <&display_out>;
> + };
> + };
> + };
> +};
> +
> +&ipu1_di0_disp0 {
> + remote-endpoint = <&display_in>;
> +};
> +
> +&pwm3 {
> + pinctrl-names = "default";
> + pinctrl-0 = <&pinctrl_pwm3>;
> + status = "okay";
> +};
> +
> +
Drop one newline.
> +&uart3 {
> + pinctrl-names = "default";
> + pinctrl-0 = <&pinctrl_uart3>;
> + status = "okay";
> +};
> +
> +&usbh1 {
> + pinctrl-names = "default";
> + pinctrl-0 = <&pinctrl_usbh1>;
> + vbus-supply = <®_usb_h1_vbus>;
> + status = "okay";
> +};
> +
> +&usbh2 {
> + pinctrl-names = "default";
> + pinctrl-0 = <&pinctrl_usbh2>;
> + phy_type = "hsic";
> + disable-over-current;
> + status = "okay";
> +};
> +
> +&usbotg {
> + vbus-supply = <®_usb_otg_vbus>;
> + pinctrl-names = "default";
> + pinctrl-0 = <&pinctrl_usbotg>;
> + disable-over-current;
> + status = "okay";
> +};
> +
> +&fec {
Please sort these labeled nodes alphabetically. The iomuxc can be an
exception, and we usually put it at the end of file to make the rest
easy to read.
> + pinctrl-names = "default";
> + pinctrl-0 = <&pinctrl_enet>;
> + phy-mode = "rmii";
> + status = "okay";
> +};
> +
> +&usdhc2 {
> + pinctrl-names = "default";
> + pinctrl-0 = <&pinctrl_usdhc2>;
> + cd-gpios = <&gpio1 4 GPIO_ACTIVE_LOW>;
> + no-1-8-v;
> + keep-power-in-suspend;
> + status = "okay";
> +};
> +
> +&i2c3 {
> + touchscreen: tsc2004 at 48 {
> + compatible = "ti,tsc2004";
> + vio-supply = <®_3v3>;
> + reg = <0x48>;
> + pinctrl-names = "default";
> + pinctrl-0 = <&pinctrl_touchscreen>;
> + reset-gpios = <&gpio4 10 GPIO_ACTIVE_HIGH>;
> + interrupts-extended = <&gpio1 6 IRQ_TYPE_EDGE_RISING>;
> + touchscreen-fuzz-x = <4>;
> + touchscreen-fuzz-y = <7>;
> + touchscreen-fuzz-pressure = <2>;
> + touchscreen-size-x = <4096>;
> + touchscreen-size-y = <4096>;
> + touchscreen-max-pressure = <2048>;
> + ti,x-plate-ohms = <280>;
> + ti,esd-recovery-timeout-ms = <8000>;
> + };
> +};
> +
> +&pcie {
> + pinctrl-names = "default";
> + pinctrl-0 = <&pinctrl_pcie>;
> + reset-gpio = <&gpio1 9 GPIO_ACTIVE_LOW>;
> + status = "okay";
> +};
> +
> +&iomuxc {
> + pinctrl_uart3: uart3grp {
> + fsl,pins = <
> + MX6QDL_PAD_EIM_D23__UART3_CTS_B 0x1b0b1
> + MX6QDL_PAD_EIM_D24__UART3_TX_DATA 0x1b0b1
> + MX6QDL_PAD_EIM_D25__UART3_RX_DATA 0x1b0b1
> + MX6QDL_PAD_EIM_EB3__UART3_RTS_B 0x1b0b1
> + >;
> + };
> +
> + pinctrl_usbotg: usbotggrp {
> + fsl,pins = <
> + MX6QDL_PAD_GPIO_1__USB_OTG_ID 0x17059
> + MX6QDL_PAD_KEY_ROW4__GPIO4_IO15 0x130b0
> + >;
Bad indentation.
> + };
> +
> + pinctrl_usbh1: usbh1grp {
> + fsl,pins = <
> + MX6QDL_PAD_GPIO_0__GPIO1_IO00 0x1b0b0
> + >;
> + };
> +
> + pinctrl_usbh2: usbh2grp {
> + fsl,pins = <
> + MX6QDL_PAD_RGMII_TXC__USB_H2_DATA 0x13030
> + MX6QDL_PAD_RGMII_TX_CTL__USB_H2_STROBE 0x17030
> + >;
> + };
> +
> + pinctrl_usdhc2: usdhc2grp {
> + fsl,pins = <
> + MX6QDL_PAD_SD2_CMD__SD2_CMD 0x17059
> + MX6QDL_PAD_SD2_CLK__SD2_CLK 0x10059
> + MX6QDL_PAD_SD2_DAT0__SD2_DATA0 0x17059
> + MX6QDL_PAD_SD2_DAT1__SD2_DATA1 0x17059
> + MX6QDL_PAD_SD2_DAT2__SD2_DATA2 0x17059
> + MX6QDL_PAD_SD2_DAT3__SD2_DATA3 0x17059
> + >;
> + };
> +
> + pinctrl_enet: enetgrp {
Please sort these pinctrl entries alphabetically.
> + fsl,pins = <
> + MX6QDL_PAD_ENET_MDIO__ENET_MDIO 0x1b0b0
> + MX6QDL_PAD_ENET_MDC__ENET_MDC 0x1b0b0
> + MX6QDL_PAD_ENET_CRS_DV__ENET_RX_EN 0x1b0b0
> + MX6QDL_PAD_ENET_TX_EN__ENET_TX_EN 0x1b0b0
> + MX6QDL_PAD_ENET_TXD0__ENET_TX_DATA0 0x1b0b0
> + MX6QDL_PAD_ENET_TXD1__ENET_TX_DATA1 0x1b0b0
> + MX6QDL_PAD_ENET_RX_ER__ENET_RX_ER 0x1b0b0
> + MX6QDL_PAD_ENET_RXD0__ENET_RX_DATA0 0x1b0b0
> + MX6QDL_PAD_ENET_RXD1__ENET_RX_DATA1 0x1b0b0
> + MX6QDL_PAD_GPIO_16__ENET_REF_CLK 0x4001b0a8
> + MX6QDL_PAD_KEY_ROW1__GPIO4_IO09 0x1b0b0
> + >;
> + };
> +
> + pinctrl_gpio_leds: gpioledsgrp {
> + fsl,pins = <
> + MX6QDL_PAD_EIM_D19__GPIO3_IO19 0x130b0
> + MX6QDL_PAD_EIM_D20__GPIO3_IO20 0x130b0
> + MX6QDL_PAD_EIM_D21__GPIO3_IO21 0x130b0
> + MX6QDL_PAD_EIM_D22__GPIO3_IO22 0x130b0
> + >;
> + };
> +
> + pinctrl_gpio_keys: gpio_keysgrp {
> + fsl,pins = <
> + MX6QDL_PAD_EIM_D28__GPIO3_IO28 0x1b0b0
> + MX6QDL_PAD_EIM_D29__GPIO3_IO29 0x1b0b0
> + MX6QDL_PAD_EIM_D30__GPIO3_IO30 0x1b0b0
> + MX6QDL_PAD_EIM_D31__GPIO3_IO31 0x1b0b0
> + >;
> + };
> +
> + pinctrl_touchscreen: touchscreengrp {
> + fsl,pins = <
> + MX6QDL_PAD_KEY_COL2__GPIO4_IO10 0x1b0b0
> + MX6QDL_PAD_GPIO_6__GPIO1_IO06 0x1b0b0
> + >;
> + };
> +
> + pinctrl_pcie_reg: pciereggrp {
> + fsl,pins = <
> + MX6QDL_PAD_GPIO_2__GPIO1_IO02 0x1b0b0
> + >;
> + };
> +
> + pinctrl_pcie: pciegrp {
> + fsl,pins = <
> + MX6QDL_PAD_GPIO_7__GPIO1_IO07 0x1b0b0
> + MX6QDL_PAD_GPIO_8__GPIO1_IO08 0x1b0b0
> + MX6QDL_PAD_GPIO_9__GPIO1_IO09 0x1b0b0
> + >;
> + };
> +
> + pinctrl_lcd: lcdgrp {
> + fsl,pins = <
> + MX6QDL_PAD_DI0_DISP_CLK__IPU1_DI0_DISP_CLK 0x10
> + MX6QDL_PAD_DI0_PIN15__GPIO4_IO17 0x100b0
> + MX6QDL_PAD_DI0_PIN2__IPU1_DI0_PIN02 0x10
> + MX6QDL_PAD_DI0_PIN3__IPU1_DI0_PIN03 0x10
> + MX6QDL_PAD_DI0_PIN4__IPU1_DI0_PIN04 0x10
> + MX6QDL_PAD_DISP0_DAT1__IPU1_DISP0_DATA01 0x10
> + MX6QDL_PAD_DISP0_DAT2__IPU1_DISP0_DATA02 0x10
> + MX6QDL_PAD_DISP0_DAT3__IPU1_DISP0_DATA03 0x10
> + MX6QDL_PAD_DISP0_DAT4__IPU1_DISP0_DATA04 0x10
> + MX6QDL_PAD_DISP0_DAT5__IPU1_DISP0_DATA05 0x10
> + MX6QDL_PAD_DISP0_DAT6__IPU1_DISP0_DATA06 0x10
> + MX6QDL_PAD_DISP0_DAT7__IPU1_DISP0_DATA07 0x10
> + MX6QDL_PAD_DISP0_DAT8__IPU1_DISP0_DATA08 0x10
> + MX6QDL_PAD_DISP0_DAT9__IPU1_DISP0_DATA09 0x10
> + MX6QDL_PAD_DISP0_DAT10__IPU1_DISP0_DATA10 0x10
> + MX6QDL_PAD_DISP0_DAT11__IPU1_DISP0_DATA11 0x10
> + MX6QDL_PAD_DISP0_DAT12__IPU1_DISP0_DATA12 0x10
> + MX6QDL_PAD_DISP0_DAT13__IPU1_DISP0_DATA13 0x10
> + MX6QDL_PAD_DISP0_DAT14__IPU1_DISP0_DATA14 0x10
> + MX6QDL_PAD_DISP0_DAT15__IPU1_DISP0_DATA15 0x10
> + MX6QDL_PAD_DISP0_DAT16__IPU1_DISP0_DATA16 0x10
> + >;
> + };
> +
> + pinctrl_backlight: backlightgrp {
> + fsl,pins = <
> + MX6QDL_PAD_SD4_DAT2__GPIO2_IO10 0x100b0
> + >;
Fix whitespace.
> + };
> +
> + pinctrl_pwm3: pwm3grp {
> + fsl,pins = <
> + MX6QDL_PAD_SD4_DAT1__PWM3_OUT 0x1b0b1
> + >;
> + };
> +};
> +
> +
Drop the end-of-file newlines.
> diff --git a/arch/arm/boot/dts/imx6qdl-logicpd.dtsi b/arch/arm/boot/dts/imx6qdl-logicpd.dtsi
> new file mode 100644
> index 0000000..ca266a3
> --- /dev/null
> +++ b/arch/arm/boot/dts/imx6qdl-logicpd.dtsi
> @@ -0,0 +1,331 @@
> +/*
> + * Copyright 2016 Logic PD
> + * This file is adapted from imx6qdl-sabresd.dtsi.
> + * Copyright 2012 Freescale Semiconductor, Inc.
> + * Copyright 2011 Linaro Ltd.
> + *
> + * The code contained herein is licensed under the GNU General Public
> + * License. You may obtain a copy of the GNU General Public License
> + * Version 2 or later at the following locations:
> + *
> + * http://www.opensource.org/licenses/gpl-license.html
> + * http://www.gnu.org/copyleft/gpl.html
> + */
Please consider to use GPL/X11 dual licence for all new dts files.
> +
> +#include <dt-bindings/gpio/gpio.h>
> +#include <dt-bindings/input/input.h>
> +#include "imx6q.dtsi"
> +
> +/ {
> + chosen {
> + stdout-path = &uart1;
> + };
> +
> + memory {
> + reg = <0x10000000 0x80000000>;
> + };
> +
> +
Unneeded newlines.
> +};
> +
> +/* Reroute power feeding the CPU to come from the external PMIC */
> +&cpu0 {
> + arm-supply = <&sw1a_reg>;
> + soc-supply = <&sw1c_reg>;
> +};
> +
> +®_arm
> +{
®_arm {
> + vin-supply = <&sw1a_reg>;
> +};
> +
> +®_soc
> +{
Ditto
> + vin-supply = <&sw1c_reg>;
> +};
> +
> +&clks {
> + assigned-clocks = <&clks IMX6QDL_CLK_LDB_DI0_SEL>,
> + <&clks IMX6QDL_CLK_LDB_DI1_SEL>;
> + assigned-clock-parents = <&clks IMX6QDL_CLK_PLL3_USB_OTG>,
> + <&clks IMX6QDL_CLK_PLL3_USB_OTG>;
> +};
> +
> +&gpmi {
> + pinctrl-names = "default";
> + pinctrl-0 = <&pinctrl_gpmi_nand>;
> + status = "okay";
> +};
> +
> +&i2c3 {
> + clock-frequency = <100000>;
> + pinctrl-names = "default";
> + pinctrl-0 = <&pinctrl_i2c3>;
> + status = "okay";
> +
> + pmic: pfuze100 at 08 {
> + compatible = "fsl,pfuze100";
> + reg = <0x08>;
> +
> + regulators {
> + sw1a_reg: sw1ab {
> + regulator-min-microvolt = <725000>;
> + regulator-max-microvolt = <1450000>;
> + regulator-name = "vddcore";
> + regulator-boot-on;
> + regulator-always-on;
> + regulator-ramp-delay = <6250>;
> + };
> +
> + sw1c_reg: sw1c {
> + regulator-min-microvolt = <725000>;
> + regulator-max-microvolt = <1450000>;
> + regulator-name = "vddsoc";
> + regulator-boot-on;
> + regulator-always-on;
> + regulator-ramp-delay = <6250>;
> + };
> +
> + sw2_reg: sw2 {
> + regulator-min-microvolt = <3300000>;
> + regulator-max-microvolt = <3300000>;
> + regulator-name = "gen_3v3";
> + regulator-boot-on;
> + regulator-always-on;
> + };
> +
> + sw3a_reg: sw3a {
> + regulator-min-microvolt = <400000>;
> + regulator-max-microvolt = <1975000>;
> + regulator-name = "sw3a_vddr";
> + regulator-boot-on;
> + regulator-always-on;
> + };
> +
> + sw3b_reg: sw3b {
> + regulator-min-microvolt = <400000>;
> + regulator-max-microvolt = <1975000>;
> + regulator-name = "sw3b_vddr";
> + regulator-boot-on;
> + regulator-always-on;
> + };
> +
> + sw4_reg: sw4 {
> + regulator-min-microvolt = <800000>;
> + regulator-max-microvolt = <3300000>;
> + regulator-name = "gen_rgmii";
> + };
> +
> + swbst_reg: swbst {
> + regulator-min-microvolt = <5000000>;
> + regulator-max-microvolt = <5150000>;
> + regulator-name = "gen_5v0";
> + };
> +
> +
Drop one newline.
> + snvs_reg: vsnvs {
> + regulator-min-microvolt = <1000000>;
> + regulator-max-microvolt = <3000000>;
> + regulator-name = "gen_vsns";
> + regulator-boot-on;
> + regulator-always-on;
> + };
> +
> + vref_reg: vrefddr {
> + regulator-boot-on;
> + regulator-always-on;
> + };
> +
> + vgen1_reg: vgen1 {
> + regulator-min-microvolt = <1500000>;
> + regulator-max-microvolt = <1500000>;
> + regulator-name = "gen_1v5";
> + };
> +
> + vgen2_reg: vgen2 {
> + regulator-name = "vgen2";
> + regulator-min-microvolt = <800000>;
> + regulator-max-microvolt = <1550000>;
> + };
> +
> + vgen3_reg: vgen3 {
> + regulator-name = "gen_vadj_0";
> + regulator-min-microvolt = <3000000>;
> + regulator-max-microvolt = <3000000>;
> + };
> +
> + vgen4_reg: vgen4 {
> + regulator-name = "gen_1v8";
> + regulator-min-microvolt = <1800000>;
> + regulator-max-microvolt = <1800000>;
> + regulator-always-on;
> + };
> +
> + vgen5_reg: vgen5 {
> + regulator-name = "gen_adj_1";
> + regulator-min-microvolt = <3300000>;
> + regulator-max-microvolt = <3300000>;
> + regulator-always-on;
> + };
> +
> + vgen6_reg: vgen6 {
> + regulator-name = "gen_2v5";
> + regulator-min-microvolt = <2500000>;
> + regulator-max-microvolt = <2500000>;
> + regulator-always-on;
> + };
> + };
> + };
> +
> + temp_sense1: tmp102 at 49 {
> + compatible = "ti,tmp102";
> + reg = <0x49>;
> + pinctrl-names = "default";
> + pinctrl-0 = <&pinctrl_tempsense>;
> + interrupt-parent = <&gpio6>;
> + interrupts = <15 IRQ_TYPE_LEVEL_LOW>;
> + #thermal-sensor-cells = <1>;
> + };
> +
> + temp_sense0: tmp102 at 4a {
> + compatible = "ti,tmp102";
> + reg = <0x4a>;
> + interrupt-parent = <&gpio6>;
> + interrupts = <15 IRQ_TYPE_LEVEL_LOW>;
> + #thermal-sensor-cells = <1>;
> + };
> +
> + user_eeprom: at24 at 52 {
> + compatible = "atmel,24c64";
> + pagesize = <32>;
> + reg = <0x52>;
> + };
> +
> + mfg_eeprom: at24 at 51 {
> + compatible = "atmel,24c64";
> + pagesize = <32>;
> + read-only;
> + reg = <0x51>;
> + };
> +};
> +
> +&iomuxc {
> + pinctrl_gpmi_nand: gpminandgrp {
> + fsl,pins = <
> + MX6QDL_PAD_NANDF_CLE__NAND_CLE 0x0b0b1
> + MX6QDL_PAD_NANDF_ALE__NAND_ALE 0x0b0b1
> + MX6QDL_PAD_NANDF_WP_B__NAND_WP_B 0x0b0b1
> + MX6QDL_PAD_NANDF_RB0__NAND_READY_B 0x0b000
> + MX6QDL_PAD_NANDF_CS0__NAND_CE0_B 0x0b0b1
> + MX6QDL_PAD_SD4_CMD__NAND_RE_B 0x0b0b1
> + MX6QDL_PAD_SD4_CLK__NAND_WE_B 0x0b0b1
> + MX6QDL_PAD_NANDF_D0__NAND_DATA00 0x0b0b1
> + MX6QDL_PAD_NANDF_D1__NAND_DATA01 0x0b0b1
> + MX6QDL_PAD_NANDF_D2__NAND_DATA02 0x0b0b1
> + MX6QDL_PAD_NANDF_D3__NAND_DATA03 0x0b0b1
> + MX6QDL_PAD_NANDF_D4__NAND_DATA04 0x0b0b1
> + MX6QDL_PAD_NANDF_D5__NAND_DATA05 0x0b0b1
> + MX6QDL_PAD_NANDF_D6__NAND_DATA06 0x0b0b1
> + MX6QDL_PAD_NANDF_D7__NAND_DATA07 0x0b0b1
> + >;
> + };
> +
> + pinctrl_i2c3: i2c3grp {
> + fsl,pins = <
> + MX6QDL_PAD_EIM_D17__I2C3_SCL 0x4001b8b1
> + MX6QDL_PAD_EIM_D18__I2C3_SDA 0x4001b8b1
> + >;
> + };
> +
> + pinctrl_uart1: uart1grp {
> + fsl,pins = <
> + MX6QDL_PAD_SD3_DAT6__UART1_RX_DATA 0x1b0b1
> + MX6QDL_PAD_SD3_DAT7__UART1_TX_DATA 0x1b0b1
> + >;
> + };
> +
> + pinctrl_uart2: uart2grp {
> + fsl,pins = <
> + MX6QDL_PAD_SD4_DAT4__UART2_RX_DATA 0x1b0b1
> + MX6QDL_PAD_SD4_DAT5__UART2_RTS_B 0x1b0b1
> + MX6QDL_PAD_SD4_DAT6__UART2_CTS_B 0x1b0b1
> + MX6QDL_PAD_SD4_DAT7__UART2_TX_DATA 0x1b0b1
> + >;
> + };
> +
> + pinctrl_usdhc1: usdhc1grp {
> + fsl,pins = <
> + MX6QDL_PAD_SD1_CMD__SD1_CMD 0x17071
> + MX6QDL_PAD_SD1_CLK__SD1_CLK 0x10071
> + MX6QDL_PAD_SD1_DAT0__SD1_DATA0 0x17071
> + MX6QDL_PAD_SD1_DAT1__SD1_DATA1 0x17071
> + MX6QDL_PAD_SD1_DAT2__SD1_DATA2 0x17071
> + MX6QDL_PAD_SD1_DAT3__SD1_DATA3 0x17071
> + >;
> + };
> +
> + pinctrl_usdhc3: usdhc3grp {
> + fsl,pins = <
> + MX6QDL_PAD_SD3_CMD__SD3_CMD 0x17059
> + MX6QDL_PAD_SD3_CLK__SD3_CLK 0x10059
> + MX6QDL_PAD_SD3_RST__GPIO7_IO08 0x1f0b0
> + MX6QDL_PAD_SD3_DAT0__SD3_DATA0 0x17059
> + MX6QDL_PAD_SD3_DAT1__SD3_DATA1 0x17059
> + MX6QDL_PAD_SD3_DAT2__SD3_DATA2 0x17059
> + MX6QDL_PAD_SD3_DAT3__SD3_DATA3 0x17059
> + MX6QDL_PAD_SD3_DAT4__GPIO7_IO01 0x1f0b0
> + MX6QDL_PAD_SD3_DAT5__GPIO7_IO00 0x1f0b0
> + >;
> + };
> +
> + pinctrl_tempsense: tempsensegrp {
> + fsl,pins = <
> + MX6QDL_PAD_NANDF_CS2__GPIO6_IO15 0x1b0b0
> + >;
> + };
> +};
> +
> +&snvs_poweroff {
> + status = "okay";
> +};
> +
> +&uart1 {
> + pinctrl-names = "default";
> + pinctrl-0 = <&pinctrl_uart1>;
> + status = "okay";
> +};
> +
> +&uart2 {
> + pinctrl-names = "default";
> + pinctrl-0 = <&pinctrl_uart2>;
> + status = "okay";
> +};
> +
> +&usdhc1 {
> + pinctrl-names = "default";
> + pinctrl-0 = <&pinctrl_usdhc1>;
> + cd-gpios = <&gpio6 16 GPIO_ACTIVE_HIGH>;
> + keep-power-in-suspend;
> + wakeup-source;
> + status = "okay";
> +};
> +
> +&usdhc3 {
> + pinctrl-names = "default";
> + pinctrl-0 = <&pinctrl_usdhc3>;
> + non-removable;
> + keep-power-in-suspend;
> + wakeup-source;
> + vmmc-supply = <&sw2_reg>;
> + status = "okay";
> + #address-cells = <1>;
> + #size-cells = <0>;
Have a newline between property list and child node.
> + wlcore: wlcore at 0 {
> + compatible = "ti,wl1837";
> + reg = <0>;
> + interrupt-parent = <&gpio7>;
> + interrupts = <1 GPIO_ACTIVE_HIGH>;
> + };
> +};
Shawn
^ permalink raw reply
* [PATCH] input: bma150: Only claim to support the bma180 if the separate iio bma180 driver is not build
From: Dmitry Torokhov @ 2016-11-14 5:35 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161113183407.12848-1-hdegoede@redhat.com>
Hi Hans,
On Sun, Nov 13, 2016 at 07:34:07PM +0100, Hans de Goede wrote:
> commit ef3714fdbc8d ("Input: bma150 - extend chip detection for bma180"),
> adds bma180 chip-ids to the input bma150 driver, assuming that they are
> 100% compatible, but the bma180 is not compatible with the bma150 at all,
> it has 14 bits resolution instead of 10, and it has quite different
> control registers too.
>
> Treating the bma180 as a bma150 wrt its data registers will just result
> in throwing away the lowest 4 bits, which is not too bad. But the ctrl
> registers are a different story. Things happen to just work but supporting
> that certainly does not make treating the bma180 the same as the bma150
> right.
>
> Since some setups depend on the evdev interface the bma150 driver offers
> on top of the bma180, we cannot simply remove the bma180 ids.
>
> So this commit only removes the bma180 id when the bma180 iio driver,
> which does treat the bma180 properly, is enabled.
>
> Cc: Dr. H. Nikolaus Schaller <hns@goldelico.com>
> Signed-off-by: Hans de Goede <hdegoede@redhat.com>
> ---
> drivers/input/misc/bma150.c | 8 +++++++-
> 1 file changed, 7 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/input/misc/bma150.c b/drivers/input/misc/bma150.c
> index b0d4453..9fa1c9a 100644
> --- a/drivers/input/misc/bma150.c
> +++ b/drivers/input/misc/bma150.c
> @@ -539,7 +539,11 @@ static int bma150_probe(struct i2c_client *client,
> }
>
> chip_id = i2c_smbus_read_byte_data(client, BMA150_CHIP_ID_REG);
> - if (chip_id != BMA150_CHIP_ID && chip_id != BMA180_CHIP_ID) {
> + if (chip_id != BMA150_CHIP_ID
> +#ifndef CONFIG_BMA180
> + && chip_id != BMA180_CHIP_ID
> +#endif
Does not this break if bma180 is compiled as module? I'd rather we did
if (chip_id != BMA150_CHIP_ID &&
(IS_ENABLED(CONFIG_BMA180) || chip_id != BMA180_CHIP_ID)) {
...
> + ) {
> dev_err(&client->dev, "BMA150 chip id error: %d\n", chip_id);
> return -EINVAL;
> }
> @@ -643,7 +647,9 @@ static UNIVERSAL_DEV_PM_OPS(bma150_pm, bma150_suspend, bma150_resume, NULL);
>
> static const struct i2c_device_id bma150_id[] = {
> { "bma150", 0 },
> +#ifndef CONFIG_BMA180
#if !IS_ENABLED(CONFIG_BMA180)
> { "bma180", 0 },
> +#endif
> { "smb380", 0 },
> { "bma023", 0 },
> { }
> --
> 2.9.3
>
Thanks.
--
Dmitry
^ permalink raw reply
* [PATCH V3 1/2] ARM: imx: mmdc perf function support i.MX6QP
From: Shawn Guo @ 2016-11-14 5:36 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1478539849-10834-1-git-send-email-Frank.Li@nxp.com>
On Mon, Nov 07, 2016 at 11:30:48AM -0600, Frank Li wrote:
> i.MX6QP added new register bit PROFILE_SEL in MADPCR0.
> need set it at perf start.
>
> Signed-off-by: Frank Li <Frank.Li@nxp.com>
Applied, thanks.
^ permalink raw reply
* [PATCH V3 2/2] ARM: dts: add new compatible stream for i.MX6QP mmdc
From: Shawn Guo @ 2016-11-14 5:37 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1478539849-10834-2-git-send-email-Frank.Li@nxp.com>
On Mon, Nov 07, 2016 at 11:30:49AM -0600, Frank Li wrote:
> MMDC has a slightly different programming model between imx6q and imx6qp
> in terms of perf support, it's exactly same for suspend support, so we
> have fsl,imx6q-mmdc here to save patching suspend driver with the new
> compatible.
>
> Signed-off-by: Frank Li <Frank.Li@nxp.com>
s/stream/string in subject.
I fixed it up and applied the patch.
Shawn
^ permalink raw reply
* [PATCH v2 1/3] ARM: imx6ull: add imx6ull support
From: Shawn Guo @ 2016-11-14 5:48 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1478584614-12054-2-git-send-email-peter.chen@nxp.com>
On Tue, Nov 08, 2016 at 01:56:52PM +0800, Peter Chen wrote:
> It is the 10th processor in the well-known imx6 series, and derived
> from imx6ul but cost optimized. The more information about imx6ull
> can be found at:
>
> http://www.nxp.com/products/microcontrollers-and-processors/
> arm-processors/i.mx-applications-processors/i.mx-6-processors
> /i.mx6qp/i.mx-6ull-single-core-processor-with-arm-cortex-a7-core
> :i.MX6ULL
>
> In this patch, for SoC part, the imx6ull.dtsi includes imx6ul.dtsi;
> for board part (imx6ul/imx6ull 14x14 evk), it has a common board
> file imx6u-14x14-evk.dtsi, and this file is included by both
> imx6ul-14x14-evk.dts and imx6ull-14x14-evk.dts.
>
> Signed-off-by: Peter Chen <peter.chen@nxp.com>
> ---
> arch/arm/boot/dts/Makefile | 3 +-
> arch/arm/boot/dts/imx6u-14x14-evk.dtsi | 487 ++++++++++++++++++++++++++++++++
> arch/arm/boot/dts/imx6ul-14x14-evk.dts | 479 +------------------------------
What's the real change between imx6u-14x14-evk.dtsi and
imx6ul-14x14-evk.dts? Instead of renaming the file, I would like to
have imx6ull-14x14-evk.dts include imx6ul-14x14-evk.dts directly, if we
can work out the difference within imx6ull-14x14-evk.dts.
Shawn
> arch/arm/boot/dts/imx6ull-14x14-evk.dts | 55 ++++
> arch/arm/boot/dts/imx6ull-pinfunc.h | 56 ++++
> arch/arm/boot/dts/imx6ull.dtsi | 43 +++
> 6 files changed, 644 insertions(+), 479 deletions(-)
> create mode 100644 arch/arm/boot/dts/imx6u-14x14-evk.dtsi
> create mode 100644 arch/arm/boot/dts/imx6ull-14x14-evk.dts
> create mode 100644 arch/arm/boot/dts/imx6ull-pinfunc.h
> create mode 100644 arch/arm/boot/dts/imx6ull.dtsi
^ permalink raw reply
* [PATCH v27 1/9] memblock: add memblock_cap_memory_range()
From: AKASHI Takahiro @ 2016-11-14 5:55 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161111031903.GB15997@arm.com>
On Fri, Nov 11, 2016 at 11:19:04AM +0800, Dennis Chen wrote:
> On Fri, Nov 11, 2016 at 11:50:50AM +0900, AKASHI Takahiro wrote:
> > Will,
> > (+ Cc: Dennis)
> >
> > On Thu, Nov 10, 2016 at 05:27:20PM +0000, Will Deacon wrote:
> > > On Wed, Nov 02, 2016 at 01:51:53PM +0900, AKASHI Takahiro wrote:
> > > > Add memblock_cap_memory_range() which will remove all the memblock regions
> > > > except the range specified in the arguments.
> > > >
> > > > This function, like memblock_mem_limit_remove_map(), will not remove
> > > > memblocks with MEMMAP_NOMAP attribute as they may be mapped and accessed
> > > > later as "device memory."
> > > > See the commit a571d4eb55d8 ("mm/memblock.c: add new infrastructure to
> > > > address the mem limit issue").
> > > >
> > > > This function is used, in a succeeding patch in the series of arm64 kdump
> > > > suuport, to limit the range of usable memory, System RAM, on crash dump
> > > > kernel.
> > > > (Please note that "mem=" parameter is of little use for this purpose.)
> > > >
> > > > Signed-off-by: AKASHI Takahiro <takahiro.akashi@linaro.org>
> > > > Cc: linux-mm at kvack.org
> > > > Cc: Andrew Morton <akpm@linux-foundation.org>
> > > > ---
> > > > include/linux/memblock.h | 1 +
> > > > mm/memblock.c | 28 ++++++++++++++++++++++++++++
> > > > 2 files changed, 29 insertions(+)
> > > >
> > > > diff --git a/include/linux/memblock.h b/include/linux/memblock.h
> > > > index 5b759c9..0e770af 100644
> > > > --- a/include/linux/memblock.h
> > > > +++ b/include/linux/memblock.h
> > > > @@ -334,6 +334,7 @@ phys_addr_t memblock_start_of_DRAM(void);
> > > > phys_addr_t memblock_end_of_DRAM(void);
> > > > void memblock_enforce_memory_limit(phys_addr_t memory_limit);
> > > > void memblock_mem_limit_remove_map(phys_addr_t limit);
> > > > +void memblock_cap_memory_range(phys_addr_t base, phys_addr_t size);
> > > > bool memblock_is_memory(phys_addr_t addr);
> > > > int memblock_is_map_memory(phys_addr_t addr);
> > > > int memblock_is_region_memory(phys_addr_t base, phys_addr_t size);
> > > > diff --git a/mm/memblock.c b/mm/memblock.c
> > > > index 7608bc3..eb53876 100644
> > > > --- a/mm/memblock.c
> > > > +++ b/mm/memblock.c
> > > > @@ -1544,6 +1544,34 @@ void __init memblock_mem_limit_remove_map(phys_addr_t limit)
> > > > (phys_addr_t)ULLONG_MAX);
> > > > }
> > > >
> > > > +void __init memblock_cap_memory_range(phys_addr_t base, phys_addr_t size)
> > > > +{
> > > > + int start_rgn, end_rgn;
> > > > + int i, ret;
> > > > +
> > > > + if (!size)
> > > > + return;
> > > > +
> > > > + ret = memblock_isolate_range(&memblock.memory, base, size,
> > > > + &start_rgn, &end_rgn);
> > > > + if (ret)
> > > > + return;
> > > > +
> > > > + /* remove all the MAP regions */
> > > > + for (i = memblock.memory.cnt - 1; i >= end_rgn; i--)
> > > > + if (!memblock_is_nomap(&memblock.memory.regions[i]))
> > > > + memblock_remove_region(&memblock.memory, i);
> > > > +
> > > > + for (i = start_rgn - 1; i >= 0; i--)
> > > > + if (!memblock_is_nomap(&memblock.memory.regions[i]))
> > > > + memblock_remove_region(&memblock.memory, i);
> > > > +
> > > > + /* truncate the reserved regions */
> > > > + memblock_remove_range(&memblock.reserved, 0, base);
> > > > + memblock_remove_range(&memblock.reserved,
> > > > + base + size, (phys_addr_t)ULLONG_MAX);
> > > > +}
> > >
> > > This duplicates a bunch of the logic in memblock_mem_limit_remove_map. Can
> > > you not implement that in terms of your new, more general, function? e.g.
> > > by passing base == 0, and size == limit?
> >
> > Obviously it's possible.
> > I actually talked to Dennis before about merging them,
> > but he was against my idea.
> >
> Oops! I thought we have reached agreement in the thread:http://lists.infradead.org/pipermail/linux-arm-kernel/2016-July/442817.html
> So feel free to do that as Will'll do
OK, but I found that the two functions have a bit different semantics
in clipping memory range, in particular, when the range [base,base+size)
goes across several regions with a gap.
(This does not happen in my arm64 kdump, though.)
That is, 'limit' in memblock_mem_limit_remove_map() means total size of
available memory, while 'size' in memblock_cap_memory_range() indicates
the size of _continuous_ memory range.
So I added an extra argument, exact, to a common function to specify
distinct behaviors. Confusing? Please see the patch below.
If nobody objects to this merge, I will submit a whole patchset of kdump
again.
Thanks,
-Takahiro AKASHI
===8<===
include/linux/memblock.h | 1 +
mm/memblock.c | 91 +++++++++++++++++++++++++++++++++++-------------
2 files changed, 68 insertions(+), 24 deletions(-)
diff --git a/include/linux/memblock.h b/include/linux/memblock.h
index 5b759c9..0e770af 100644
--- a/include/linux/memblock.h
+++ b/include/linux/memblock.h
@@ -334,6 +334,7 @@ phys_addr_t memblock_start_of_DRAM(void);
phys_addr_t memblock_end_of_DRAM(void);
void memblock_enforce_memory_limit(phys_addr_t memory_limit);
void memblock_mem_limit_remove_map(phys_addr_t limit);
+void memblock_cap_memory_range(phys_addr_t base, phys_addr_t size);
bool memblock_is_memory(phys_addr_t addr);
int memblock_is_map_memory(phys_addr_t addr);
int memblock_is_region_memory(phys_addr_t base, phys_addr_t size);
diff --git a/mm/memblock.c b/mm/memblock.c
index 7608bc3..5f849a9 100644
--- a/mm/memblock.c
+++ b/mm/memblock.c
@@ -1473,9 +1473,10 @@ phys_addr_t __init_memblock memblock_end_of_DRAM(void)
return (memblock.memory.regions[idx].base + memblock.memory.regions[idx].size);
}
-static phys_addr_t __init_memblock __find_max_addr(phys_addr_t limit)
+static phys_addr_t __init_memblock __find_max_addr(phys_addr_t min,
+ phys_addr_t limit)
{
- phys_addr_t max_addr = (phys_addr_t)ULLONG_MAX;
+ phys_addr_t max_addr = (phys_addr_t)ULLONG_MAX, base, size;
struct memblock_region *r;
/*
@@ -1484,11 +1485,22 @@ static phys_addr_t __init_memblock __find_max_addr(phys_addr_t limit)
* of those regions, max_addr will keep original value ULLONG_MAX
*/
for_each_memblock(memory, r) {
- if (limit <= r->size) {
- max_addr = r->base + limit;
+ if (min >= r->base + r->size)
+ continue;
+
+ if (r->base <= min) {
+ base = min;
+ size = r->base + r->size - min;
+ } else {
+ base = r->base;
+ size = r->size;
+ }
+
+ if (limit <= size) {
+ max_addr = base + limit;
break;
}
- limit -= r->size;
+ limit -= size;
}
return max_addr;
@@ -1501,7 +1513,7 @@ void __init memblock_enforce_memory_limit(phys_addr_t limit)
if (!limit)
return;
- max_addr = __find_max_addr(limit);
+ max_addr = __find_max_addr(0, limit);
/* @limit exceeds the total size of the memory, do nothing */
if (max_addr == (phys_addr_t)ULLONG_MAX)
@@ -1514,34 +1526,65 @@ void __init memblock_enforce_memory_limit(phys_addr_t limit)
(phys_addr_t)ULLONG_MAX);
}
-void __init memblock_mem_limit_remove_map(phys_addr_t limit)
+/*
+ * __memblock_cap_memory_range - cap memblock regions
+ * @base: lowest address to clip
+ * @size: size of memory range
+ * @exact: true or false
+ *
+ * If @exact is true, the exact range [@base, @base+ at size) of memory with
+ * kernel direct mapping is clipped from memblock.memory. Otherwise, total
+ * of @size of memory is clipped starting from @base.
+ */
+static void __init __memblock_cap_memory_range(phys_addr_t base,
+ phys_addr_t size, bool exact)
{
- struct memblock_type *type = &memblock.memory;
- phys_addr_t max_addr;
- int i, ret, start_rgn, end_rgn;
+ int start_rgn, end_rgn;
+ int i, ret;
- if (!limit)
+ if (!size)
return;
- max_addr = __find_max_addr(limit);
+ if (!exact) {
+ phys_addr_t max_addr;
- /* @limit exceeds the total size of the memory, do nothing */
- if (max_addr == (phys_addr_t)ULLONG_MAX)
- return;
+ max_addr = __find_max_addr(base, size);
+ /* @size exceeds the total size of the memory, do nothing */
+ if (max_addr == (phys_addr_t)ULLONG_MAX)
+ return;
+
+ /* recalc the size to clip the exact range [@base, max_addr) */
+ size = max_addr - base;
+ }
- ret = memblock_isolate_range(type, max_addr, (phys_addr_t)ULLONG_MAX,
- &start_rgn, &end_rgn);
+ ret = memblock_isolate_range(&memblock.memory, base, size,
+ &start_rgn, &end_rgn);
if (ret)
return;
- /* remove all the MAP regions above the limit */
- for (i = end_rgn - 1; i >= start_rgn; i--) {
- if (!memblock_is_nomap(&type->regions[i]))
- memblock_remove_region(type, i);
- }
+ /* remove all the other MAP regions */
+ for (i = memblock.memory.cnt - 1; i >= end_rgn; i--)
+ if (!memblock_is_nomap(&memblock.memory.regions[i]))
+ memblock_remove_region(&memblock.memory, i);
+
+ for (i = start_rgn - 1; i >= 0; i--)
+ if (!memblock_is_nomap(&memblock.memory.regions[i]))
+ memblock_remove_region(&memblock.memory, i);
+
/* truncate the reserved regions */
- memblock_remove_range(&memblock.reserved, max_addr,
- (phys_addr_t)ULLONG_MAX);
+ memblock_remove_range(&memblock.reserved, 0, base);
+ memblock_remove_range(&memblock.reserved,
+ base + size, (phys_addr_t)ULLONG_MAX);
+}
+
+void __init memblock_mem_limit_remove_map(phys_addr_t limit)
+{
+ __memblock_cap_memory_range(0, limit, false);
+}
+
+void __init memblock_cap_memory_range(phys_addr_t base, phys_addr_t size)
+{
+ __memblock_cap_memory_range(base, size, true);
}
static int __init_memblock memblock_search(struct memblock_type *type, phys_addr_t addr)
--
2.10.0
===>8===
> >
> > Thanks,
> > -Takahiro AKASHI
> >
> > > Will
^ permalink raw reply related
* [PATCH v2 1/2] arm64: dts: Add level for cpu dt node for exynos7
From: Alim Akhtar @ 2016-11-14 5:58 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CAJKOXPc5aJi9nVv4rd3pB_dkkoJWUjmkEyXF2Kxtp+6Y7VZdWg@mail.gmail.com>
Hi Krzysztof,
On 11/13/2016 12:43 AM, Krzysztof Kozlowski wrote:
> On Sat, Nov 12, 2016 at 6:00 PM, Alim Akhtar <alim.akhtar@gmail.com> wrote:
>> Hi Javier,
>>
>> On Sat, Nov 12, 2016 at 7:54 PM, Javier Martinez Canillas
>> <javier@osg.samsung.com> wrote:
>>> Hello Alim,
>>>
>>> On 11/12/2016 07:17 AM, Alim Akhtar wrote:
>>>> This patch adds level for cpu dt node, so that these levels can be used
>>>
>>> Do you mean s/level/label here? I'm asking because you are using level
>>> consistently in the subject line and commit message but I'm not sure
>>> what it means in this context.
>>>
>>
>> Ah!! my bad. Its __label__. If required, will respin.
>> Thanks for review.
>
> I think there is no need of respin because this should be squashed
> with previous patch. This is quite small and there are no functional
> changes here (labels are transparent, except of course conflict
> cases). Without the 2/2, this patch does not have much sense yet.
>
The reason why I kept the _label_ changes are separate patch is to keep
git bisect happy. If you think there won't be a case for that, then lets
merge the two in single patch.
Let me know if you want me to respin or you will take care.
> Best regards,
> Krzysztof
>
>
>
^ permalink raw reply
* [PATCH v2 1/3] ARM: imx6ull: add imx6ull support
From: Peter Chen @ 2016-11-14 5:59 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161114054833.GG3310@dragon>
Best regards,
Peter Chen
>-----Original Message-----
>From: Shawn Guo [mailto:shawnguo at kernel.org]
>Sent: Monday, November 14, 2016 1:49 PM
>To: Peter Chen <peter.chen@nxp.com>
>Cc: sboyd at codeaurora.org; mturquette at baylibre.com; linux-arm-
>kernel at lists.infradead.org; kernel at pengutronix.de; devicetree at vger.kernel.org;
>robh+dt at kernel.org; Fabio Estevam <fabio.estevam@nxp.com>;
>mark.rutland at arm.com; linux-clk at vger.kernel.org
>Subject: Re: [PATCH v2 1/3] ARM: imx6ull: add imx6ull support
>
>On Tue, Nov 08, 2016 at 01:56:52PM +0800, Peter Chen wrote:
>> It is the 10th processor in the well-known imx6 series, and derived
>> from imx6ul but cost optimized. The more information about imx6ull can
>> be found at:
>>
>> http://www.nxp.com/products/microcontrollers-and-processors/
>> arm-processors/i.mx-applications-processors/i.mx-6-processors
>> /i.mx6qp/i.mx-6ull-single-core-processor-with-arm-cortex-a7-core
>> :i.MX6ULL
>>
>> In this patch, for SoC part, the imx6ull.dtsi includes imx6ul.dtsi;
>> for board part (imx6ul/imx6ull 14x14 evk), it has a common board file
>> imx6u-14x14-evk.dtsi, and this file is included by both
>> imx6ul-14x14-evk.dts and imx6ull-14x14-evk.dts.
>>
>> Signed-off-by: Peter Chen <peter.chen@nxp.com>
>> ---
>> arch/arm/boot/dts/Makefile | 3 +-
>> arch/arm/boot/dts/imx6u-14x14-evk.dtsi | 487
>> ++++++++++++++++++++++++++++++++
>> arch/arm/boot/dts/imx6ul-14x14-evk.dts | 479
>> +------------------------------
>
>What's the real change between imx6u-14x14-evk.dtsi and imx6ul-14x14-evk.dts?
>Instead of renaming the file, I would like to have imx6ull-14x14-evk.dts include
>imx6ul-14x14-evk.dts directly, if we can work out the difference within imx6ull-
>14x14-evk.dts.
>
The main difference is compatible string, I can't include two compatible strings in one dts file,
the dts build will fail for that.
imx6ull-14x14-evk.dts
/ {
model = "Freescale i.MX6 UlltraLite 14x14 EVK Board";
compatible = "fsl,imx6ull-14x14-evk", "fsl,imx6ull";
};
imx6ul-14x14-evk.dts
/ {
model = "Freescale i.MX6 UltraLite 14x14 EVK Board";
compatible = "fsl,imx6ul-14x14-evk", "fsl,imx6ul";
};
Peter
^ permalink raw reply
* [PATCH 09/16] ARM: BCM: use generic API for enabling SCU
From: Florian Fainelli @ 2016-11-14 6:10 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1479099731-28108-10-git-send-email-pankaj.dubey@samsung.com>
Le 13/11/2016 ? 21:02, Pankaj Dubey a ?crit :
> Now as we have of_scu_enable which takes care of mapping
> scu base from DT, lets use it.
>
> CC: Florian Fainelli <f.fainelli@gmail.com>
> CC: Ray Jui <rjui@broadcom.com>
> CC: Scott Branden <sbranden@broadcom.com>
> CC: bcm-kernel-feedback-list at broadcom.com
> Signed-off-by: Pankaj Dubey <pankaj.dubey@samsung.com>
Reviewed-by: Florian Fainelli <f.fainelli@gmail.com>
Let me know if I need to pick this and submit via ARM SoC pull requests,
thanks!
--
Florian
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox