* [PATCH v6 5/8] ARM: brcmstb: add CPU binding for Broadcom Brahma15
From: Marc Carino @ 2014-02-03 21:30 UTC (permalink / raw)
To: Christian Daudt, Arnd Bergmann, Olof Johansson
Cc: Florian Fainelli, Matt Porter, Russell King, linux-arm-kernel,
linux-kernel, devicetree, Marc Carino
In-Reply-To: <1391463041-15241-1-git-send-email-marc.ceeeee@gmail.com>
Add the Broadcom Brahma B15 CPU to the DT CPU binding list.
Signed-off-by: Marc Carino <marc.ceeeee@gmail.com>
Acked-by: Florian Fainelli <f.fainelli@gmail.com>
---
Documentation/devicetree/bindings/arm/cpus.txt | 1 +
1 files changed, 1 insertions(+), 0 deletions(-)
diff --git a/Documentation/devicetree/bindings/arm/cpus.txt b/Documentation/devicetree/bindings/arm/cpus.txt
index 9130435..0cd1e25 100644
--- a/Documentation/devicetree/bindings/arm/cpus.txt
+++ b/Documentation/devicetree/bindings/arm/cpus.txt
@@ -163,6 +163,7 @@ nodes to be present and contain the properties described below.
"arm,cortex-r4"
"arm,cortex-r5"
"arm,cortex-r7"
+ "brcm,brahma-b15"
"faraday,fa526"
"intel,sa110"
"intel,sa1100"
--
1.7.1
^ permalink raw reply related
* [PATCH v6 4/8] ARM: do CPU-specific init for Broadcom Brahma15 cores
From: Marc Carino @ 2014-02-03 21:30 UTC (permalink / raw)
To: Christian Daudt, Arnd Bergmann, Olof Johansson
Cc: Florian Fainelli, Matt Porter, Russell King, linux-arm-kernel,
linux-kernel, devicetree, Marc Carino
In-Reply-To: <1391463041-15241-1-git-send-email-marc.ceeeee@gmail.com>
Perform any CPU-specific initialization required on the
Broadcom Brahma-15 core.
Signed-off-by: Marc Carino <marc.ceeeee@gmail.com>
Acked-by: Florian Fainelli <f.fainelli@gmail.com>
---
arch/arm/mm/proc-v7.S | 11 +++++++++++
1 files changed, 11 insertions(+), 0 deletions(-)
diff --git a/arch/arm/mm/proc-v7.S b/arch/arm/mm/proc-v7.S
index bd17819..98ea423 100644
--- a/arch/arm/mm/proc-v7.S
+++ b/arch/arm/mm/proc-v7.S
@@ -193,6 +193,7 @@ __v7_cr7mp_setup:
b 1f
__v7_ca7mp_setup:
__v7_ca15mp_setup:
+__v7_b15mp_setup:
mov r10, #0
1:
#ifdef CONFIG_SMP
@@ -494,6 +495,16 @@ __v7_ca15mp_proc_info:
.size __v7_ca15mp_proc_info, . - __v7_ca15mp_proc_info
/*
+ * Broadcom Corporation Brahma-B15 processor.
+ */
+ .type __v7_b15mp_proc_info, #object
+__v7_b15mp_proc_info:
+ .long 0x420f00f0
+ .long 0xff0ffff0
+ __v7_proc __v7_b15mp_setup, hwcaps = HWCAP_IDIV
+ .size __v7_b15mp_proc_info, . - __v7_b15mp_proc_info
+
+ /*
* Qualcomm Inc. Krait processors.
*/
.type __krait_proc_info, #object
--
1.7.1
^ permalink raw reply related
* [PATCH v6 3/8] ARM: brcmstb: add debug UART for earlyprintk support
From: Marc Carino @ 2014-02-03 21:30 UTC (permalink / raw)
To: Christian Daudt, Arnd Bergmann, Olof Johansson
Cc: Florian Fainelli, Matt Porter, Russell King, linux-arm-kernel,
linux-kernel, devicetree, Marc Carino
In-Reply-To: <1391463041-15241-1-git-send-email-marc.ceeeee@gmail.com>
Add the UART definitions needed to support earlyprintk on brcmstb machines.
Signed-off-by: Marc Carino <marc.ceeeee@gmail.com>
Acked-by: Florian Fainelli <f.fainelli@gmail.com>
---
arch/arm/Kconfig.debug | 15 ++++++++++++++-
1 files changed, 14 insertions(+), 1 deletions(-)
diff --git a/arch/arm/Kconfig.debug b/arch/arm/Kconfig.debug
index 0531da8..5d7f76b 100644
--- a/arch/arm/Kconfig.debug
+++ b/arch/arm/Kconfig.debug
@@ -125,6 +125,17 @@ choice
Say Y here if you want kernel low-level debugging support
on Marvell Berlin SoC based platforms.
+ config DEBUG_BRCMSTB_UART
+ bool "Use BRCMSTB UART for low-level debug"
+ depends on ARCH_BRCMSTB
+ select DEBUG_UART_8250
+ help
+ Say Y here if you want the debug print routines to direct
+ their output to the first serial port on these devices.
+
+ If you have a Broadcom STB chip and would like early print
+ messages to appear over the UART, select this option.
+
config DEBUG_CLPS711X_UART1
bool "Kernel low-level debugging messages via UART1"
depends on ARCH_CLPS711X
@@ -1049,6 +1060,7 @@ config DEBUG_UART_PHYS
default 0xd4018000 if DEBUG_MMP_UART3
default 0xe0000000 if ARCH_SPEAR13XX
default 0xf0000be0 if ARCH_EBSA110
+ default 0xf0406b00 if DEBUG_BRCMSTB_UART
default 0xf1012000 if DEBUG_MVEBU_UART_ALTERNATE
default 0xf1012000 if ARCH_DOVE || ARCH_KIRKWOOD || ARCH_MV78XX0 || \
ARCH_ORION5X
@@ -1083,6 +1095,7 @@ config DEBUG_UART_VIRT
default 0xf8090000 if DEBUG_VEXPRESS_UART0_RS1
default 0xfb009000 if DEBUG_REALVIEW_STD_PORT
default 0xfb10c000 if DEBUG_REALVIEW_PB1176_PORT
+ default 0xfc406b00 if DEBUG_BRCMSTB_UART
default 0xfd000000 if ARCH_SPEAR3XX || ARCH_SPEAR6XX
default 0xfd000000 if ARCH_SPEAR13XX
default 0xfd012000 if ARCH_MV78XX0
@@ -1136,7 +1149,7 @@ config DEBUG_UART_8250_WORD
ARCH_KEYSTONE || \
DEBUG_DAVINCI_DMx_UART0 || DEBUG_DAVINCI_DA8XX_UART1 || \
DEBUG_DAVINCI_DA8XX_UART2 || DEBUG_DAVINCI_TNETV107X_UART1 || \
- DEBUG_BCM_KONA_UART
+ DEBUG_BCM_KONA_UART || DEBUG_BRCMSTB_UART
config DEBUG_UART_8250_FLOW_CONTROL
bool "Enable flow control for 8250 UART"
--
1.7.1
^ permalink raw reply related
* [PATCH v6 2/8] power: reset: Add reboot driver for brcmstb
From: Marc Carino @ 2014-02-03 21:30 UTC (permalink / raw)
To: Christian Daudt, Arnd Bergmann, Olof Johansson
Cc: Florian Fainelli, Matt Porter, Russell King, linux-arm-kernel,
linux-kernel, devicetree, Marc Carino
In-Reply-To: <1391463041-15241-1-git-send-email-marc.ceeeee@gmail.com>
Add support for reboot functionality on boards with ARM-based
Broadcom STB chipsets.
Signed-off-by: Marc Carino <marc.ceeeee@gmail.com>
---
arch/arm/mach-bcm/Kconfig | 1 +
drivers/power/reset/Kconfig | 10 +++
drivers/power/reset/Makefile | 1 +
drivers/power/reset/brcmstb-reboot.c | 120 ++++++++++++++++++++++++++++++++++
4 files changed, 132 insertions(+), 0 deletions(-)
create mode 100644 drivers/power/reset/brcmstb-reboot.c
diff --git a/arch/arm/mach-bcm/Kconfig b/arch/arm/mach-bcm/Kconfig
index f85e7bc..d8f6d7a 100644
--- a/arch/arm/mach-bcm/Kconfig
+++ b/arch/arm/mach-bcm/Kconfig
@@ -39,6 +39,7 @@ config ARCH_BRCMSTB
select MIGHT_HAVE_PCI
select HAVE_SMP
select HAVE_ARM_ARCH_TIMER
+ select POWER_RESET_BRCMSTB
help
Say Y if you intend to run the kernel on a Broadcom ARM-based STB
chipset.
diff --git a/drivers/power/reset/Kconfig b/drivers/power/reset/Kconfig
index 6d452a7..c886505 100644
--- a/drivers/power/reset/Kconfig
+++ b/drivers/power/reset/Kconfig
@@ -12,6 +12,16 @@ config POWER_RESET_AS3722
help
This driver supports turning off board via a ams AS3722 power-off.
+config POWER_RESET_BRCMSTB
+ bool "Broadcom STB reset driver"
+ depends on POWER_RESET && ARCH_BRCMSTB
+ help
+ This driver provides restart support for ARM-based Broadcom STB
+ boards.
+
+ Say Y here if you have an ARM-based Broadcom STB board and you wish
+ to have restart support.
+
config POWER_RESET_GPIO
bool "GPIO power-off driver"
depends on OF_GPIO && POWER_RESET
diff --git a/drivers/power/reset/Makefile b/drivers/power/reset/Makefile
index a5b4a77..72bb94f 100644
--- a/drivers/power/reset/Makefile
+++ b/drivers/power/reset/Makefile
@@ -5,3 +5,4 @@ obj-$(CONFIG_POWER_RESET_QNAP) += qnap-poweroff.o
obj-$(CONFIG_POWER_RESET_RESTART) += restart-poweroff.o
obj-$(CONFIG_POWER_RESET_VEXPRESS) += vexpress-poweroff.o
obj-$(CONFIG_POWER_RESET_XGENE) += xgene-reboot.o
+obj-$(CONFIG_POWER_RESET_BRCMSTB) += brcmstb-reboot.o
diff --git a/drivers/power/reset/brcmstb-reboot.c b/drivers/power/reset/brcmstb-reboot.c
new file mode 100644
index 0000000..3f23692
--- /dev/null
+++ b/drivers/power/reset/brcmstb-reboot.c
@@ -0,0 +1,120 @@
+/*
+ * Copyright (C) 2013 Broadcom Corporation
+ *
+ * This program is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU General Public License as
+ * published by the Free Software Foundation version 2.
+ *
+ * This program is distributed "as is" WITHOUT ANY WARRANTY of any
+ * kind, whether express or implied; without even the implied warranty
+ * of MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+ * GNU General Public License for more details.
+ */
+
+#include <linux/device.h>
+#include <linux/errno.h>
+#include <linux/init.h>
+#include <linux/io.h>
+#include <linux/jiffies.h>
+#include <linux/of_address.h>
+#include <linux/of_irq.h>
+#include <linux/of_platform.h>
+#include <linux/platform_device.h>
+#include <linux/printk.h>
+#include <linux/reboot.h>
+#include <linux/regmap.h>
+#include <linux/smp.h>
+#include <linux/mfd/syscon.h>
+
+#include <asm/system_misc.h>
+
+#define RESET_SOURCE_ENABLE_REG 1
+#define SW_MASTER_RESET_REG 2
+
+static struct regmap *regmap;
+static u32 rst_src_en;
+static u32 sw_mstr_rst;
+
+static void brcmstb_reboot(enum reboot_mode mode, const char *cmd)
+{
+ int rc;
+ u32 tmp;
+
+ rc = regmap_write(regmap, rst_src_en, 1);
+ if (rc) {
+ pr_err("failed to write rst_src_en (%d)\n", rc);
+ return;
+ }
+
+ rc = regmap_read(regmap, rst_src_en, &tmp);
+ if (rc) {
+ pr_err("failed to read rst_src_en (%d)\n", rc);
+ return;
+ }
+
+ rc = regmap_write(regmap, sw_mstr_rst, 1);
+ if (rc) {
+ pr_err("failed to write sw_mstr_rst (%d)\n", rc);
+ return;
+ }
+
+ rc = regmap_read(regmap, sw_mstr_rst, &tmp);
+ if (rc) {
+ pr_err("failed to read sw_mstr_rst (%d)\n", rc);
+ return;
+ }
+
+ while (1)
+ ;
+}
+
+static int brcmstb_reboot_probe(struct platform_device *pdev)
+{
+ int rc;
+ struct device_node *np = pdev->dev.of_node;
+
+ regmap = syscon_regmap_lookup_by_phandle(np, "syscon");
+ if (IS_ERR(regmap)) {
+ pr_err("failed to get syscon phandle\n");
+ return -EINVAL;
+ }
+
+ rc = of_property_read_u32_index(np, "syscon", RESET_SOURCE_ENABLE_REG,
+ &rst_src_en);
+ if (rc) {
+ pr_err("can't get rst_src_en offset (%d)\n", rc);
+ return -EINVAL;
+ }
+
+ rc = of_property_read_u32_index(np, "syscon", SW_MASTER_RESET_REG,
+ &sw_mstr_rst);
+ if (rc) {
+ pr_err("can't get sw_mstr_rst offset (%d)\n", rc);
+ return -EINVAL;
+ }
+
+ arm_pm_restart = brcmstb_reboot;
+
+ return 0;
+}
+
+static const struct of_device_id of_match[] = {
+ { .compatible = "brcm,brcmstb-reboot", },
+ {},
+};
+
+static struct platform_driver brcmstb_reboot_driver = {
+ .probe = brcmstb_reboot_probe,
+ .driver = {
+ .name = "brcmstb-reboot",
+ .owner = THIS_MODULE,
+ .of_match_table = of_match,
+ },
+};
+
+static int __init brcmstb_reboot_init(void)
+{
+ return platform_driver_probe(&brcmstb_reboot_driver,
+ brcmstb_reboot_probe);
+}
+subsys_initcall(brcmstb_reboot_init);
--
1.7.1
^ permalink raw reply related
* [PATCH v6 1/8] ARM: brcmstb: add infrastructure for ARM-based Broadcom STB SoCs
From: Marc Carino @ 2014-02-03 21:30 UTC (permalink / raw)
To: Christian Daudt, Arnd Bergmann, Olof Johansson
Cc: Florian Fainelli, Matt Porter, Russell King, linux-arm-kernel,
linux-kernel, devicetree, Marc Carino
In-Reply-To: <1391463041-15241-1-git-send-email-marc.ceeeee@gmail.com>
The BCM7xxx series of Broadcom SoCs are used primarily in set-top boxes.
This patch adds machine support for the ARM-based Broadcom SoCs.
Signed-off-by: Marc Carino <marc.ceeeee@gmail.com>
Acked-by: Florian Fainelli <f.fainelli@gmail.com>
---
arch/arm/configs/multi_v7_defconfig | 1 +
arch/arm/mach-bcm/Kconfig | 14 ++
arch/arm/mach-bcm/Makefile | 4 +
arch/arm/mach-bcm/brcmstb.c | 104 ++++++++++++
arch/arm/mach-bcm/brcmstb.h | 38 +++++
arch/arm/mach-bcm/headsmp-brcmstb.S | 33 ++++
arch/arm/mach-bcm/hotplug-brcmstb.c | 311 +++++++++++++++++++++++++++++++++++
7 files changed, 505 insertions(+), 0 deletions(-)
create mode 100644 arch/arm/mach-bcm/brcmstb.c
create mode 100644 arch/arm/mach-bcm/brcmstb.h
create mode 100644 arch/arm/mach-bcm/headsmp-brcmstb.S
create mode 100644 arch/arm/mach-bcm/hotplug-brcmstb.c
diff --git a/arch/arm/configs/multi_v7_defconfig b/arch/arm/configs/multi_v7_defconfig
index 845bc74..2437b7f 100644
--- a/arch/arm/configs/multi_v7_defconfig
+++ b/arch/arm/configs/multi_v7_defconfig
@@ -12,6 +12,7 @@ CONFIG_MACH_ARMADA_370=y
CONFIG_MACH_ARMADA_XP=y
CONFIG_ARCH_BCM=y
CONFIG_ARCH_BCM_MOBILE=y
+CONFIG_ARCH_BRCMSTB=y
CONFIG_ARCH_BERLIN=y
CONFIG_MACH_BERLIN_BG2=y
CONFIG_MACH_BERLIN_BG2CD=y
diff --git a/arch/arm/mach-bcm/Kconfig b/arch/arm/mach-bcm/Kconfig
index b1aa6a9..f85e7bc 100644
--- a/arch/arm/mach-bcm/Kconfig
+++ b/arch/arm/mach-bcm/Kconfig
@@ -32,6 +32,20 @@ config ARCH_BCM_MOBILE
BCM11130, BCM11140, BCM11351, BCM28145 and
BCM28155 variants.
+config ARCH_BRCMSTB
+ bool "Broadcom BCM7XXX based boards" if ARCH_MULTI_V7
+ depends on MMU
+ select ARM_GIC
+ select MIGHT_HAVE_PCI
+ select HAVE_SMP
+ select HAVE_ARM_ARCH_TIMER
+ help
+ Say Y if you intend to run the kernel on a Broadcom ARM-based STB
+ chipset.
+
+ This enables support for Broadcom ARM-based set-top box chipsets,
+ including the 7445 family of chips.
+
endmenu
endif
diff --git a/arch/arm/mach-bcm/Makefile b/arch/arm/mach-bcm/Makefile
index c2ccd5a..b744a12 100644
--- a/arch/arm/mach-bcm/Makefile
+++ b/arch/arm/mach-bcm/Makefile
@@ -13,3 +13,7 @@
obj-$(CONFIG_ARCH_BCM_MOBILE) := board_bcm281xx.o bcm_kona_smc.o bcm_kona_smc_asm.o kona.o
plus_sec := $(call as-instr,.arch_extension sec,+sec)
AFLAGS_bcm_kona_smc_asm.o :=-Wa,-march=armv7-a$(plus_sec)
+
+obj-$(CONFIG_ARCH_BRCMSTB) := brcmstb.o
+obj-$(CONFIG_SMP) += headsmp-brcmstb.o
+obj-$(CONFIG_HOTPLUG_CPU) += hotplug-brcmstb.o
diff --git a/arch/arm/mach-bcm/brcmstb.c b/arch/arm/mach-bcm/brcmstb.c
new file mode 100644
index 0000000..71387a8
--- /dev/null
+++ b/arch/arm/mach-bcm/brcmstb.c
@@ -0,0 +1,104 @@
+/*
+ * Copyright (C) 2013 Broadcom Corporation
+ *
+ * This program is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU General Public License as
+ * published by the Free Software Foundation version 2.
+ *
+ * This program is distributed "as is" WITHOUT ANY WARRANTY of any
+ * kind, whether express or implied; without even the implied warranty
+ * of MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+ * GNU General Public License for more details.
+ */
+
+#include <linux/clk-provider.h>
+#include <linux/console.h>
+#include <linux/clocksource.h>
+#include <linux/delay.h>
+#include <linux/device.h>
+#include <linux/errno.h>
+#include <linux/init.h>
+#include <linux/io.h>
+#include <linux/jiffies.h>
+#include <linux/of_address.h>
+#include <linux/of_irq.h>
+#include <linux/of_platform.h>
+#include <linux/platform_device.h>
+#include <linux/printk.h>
+#include <linux/smp.h>
+
+#include <asm/cacheflush.h>
+#include <asm/mach-types.h>
+#include <asm/mach/arch.h>
+#include <asm/mach/map.h>
+#include <asm/mach/time.h>
+
+#include "brcmstb.h"
+
+/***********************************************************************
+ * STB CPU (main application processor)
+ ***********************************************************************/
+
+static const char *brcmstb_match[] __initconst = {
+ "brcm,bcm7445",
+ "brcm,brcmstb",
+ NULL
+};
+
+/***********************************************************************
+ * SMP boot
+ ***********************************************************************/
+
+#ifdef CONFIG_SMP
+static DEFINE_SPINLOCK(boot_lock);
+
+static void brcmstb_secondary_init(unsigned int cpu)
+{
+ /*
+ * Synchronise with the boot thread.
+ */
+ spin_lock(&boot_lock);
+ spin_unlock(&boot_lock);
+}
+
+static int brcmstb_boot_secondary(unsigned int cpu,
+ struct task_struct *idle)
+{
+ /*
+ * set synchronisation state between this boot processor
+ * and the secondary one
+ */
+ spin_lock(&boot_lock);
+
+ /* Bring up power to the core if necessary */
+ if (brcmstb_cpu_get_power_state(cpu) == 0)
+ brcmstb_cpu_power_on(cpu);
+
+ brcmstb_cpu_boot(cpu);
+
+ /*
+ * now the secondary core is starting up let it run its
+ * calibrations, then wait for it to finish
+ */
+ spin_unlock(&boot_lock);
+
+ return 0;
+}
+
+struct smp_operations brcmstb_smp_ops __initdata = {
+ .smp_prepare_cpus = brcmstb_cpu_ctrl_setup,
+ .smp_secondary_init = brcmstb_secondary_init,
+ .smp_boot_secondary = brcmstb_boot_secondary,
+#ifdef CONFIG_HOTPLUG_CPU
+ .cpu_kill = brcmstb_cpu_kill,
+ .cpu_die = brcmstb_cpu_die,
+#endif
+};
+#endif
+
+DT_MACHINE_START(BRCMSTB, "Broadcom STB (Flattened Device Tree)")
+ .dt_compat = brcmstb_match,
+#ifdef CONFIG_SMP
+ .smp = smp_ops(brcmstb_smp_ops),
+#endif
+MACHINE_END
diff --git a/arch/arm/mach-bcm/brcmstb.h b/arch/arm/mach-bcm/brcmstb.h
new file mode 100644
index 0000000..e49bde6
--- /dev/null
+++ b/arch/arm/mach-bcm/brcmstb.h
@@ -0,0 +1,38 @@
+/*
+ * Copyright (C) 2013 Broadcom Corporation
+ *
+ * This program is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU General Public License as
+ * published by the Free Software Foundation version 2.
+ *
+ * This program is distributed "as is" WITHOUT ANY WARRANTY of any
+ * kind, whether express or implied; without even the implied warranty
+ * of MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+ * GNU General Public License for more details.
+ */
+
+#ifndef __BRCMSTB_H__
+#define __BRCMSTB_H__
+
+#if !defined(__ASSEMBLY__)
+#include <linux/smp.h>
+#endif
+
+#if !defined(__ASSEMBLY__)
+extern void brcmstb_secondary_startup(void);
+extern void brcmstb_cpu_boot(unsigned int cpu);
+extern void brcmstb_cpu_power_on(unsigned int cpu);
+extern int brcmstb_cpu_get_power_state(unsigned int cpu);
+extern struct smp_operations brcmstb_smp_ops;
+#if defined(CONFIG_HOTPLUG_CPU)
+extern void brcmstb_cpu_die(unsigned int cpu);
+extern int brcmstb_cpu_kill(unsigned int cpu);
+void __init brcmstb_cpu_ctrl_setup(unsigned int max_cpus);
+#else
+static inline void brcmstb_cpu_die(unsigned int cpu) {}
+static inline int brcmstb_cpu_kill(unsigned int cpu) {}
+static inline void __init brcmstb_cpu_ctrl_setup(unsigned int max_cpus) {}
+#endif
+#endif
+
+#endif /* __BRCMSTB_H__ */
diff --git a/arch/arm/mach-bcm/headsmp-brcmstb.S b/arch/arm/mach-bcm/headsmp-brcmstb.S
new file mode 100644
index 0000000..89134c7
--- /dev/null
+++ b/arch/arm/mach-bcm/headsmp-brcmstb.S
@@ -0,0 +1,33 @@
+/*
+ * SMP boot code for secondary CPUs
+ * Based on arch/arm/mach-tegra/headsmp.S
+ *
+ * Copyright (C) 2010 NVIDIA, Inc.
+ * Copyright (C) 2013 Broadcom Corporation
+ *
+ * This program is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU General Public License as
+ * published by the Free Software Foundation version 2.
+ *
+ * This program is distributed "as is" WITHOUT ANY WARRANTY of any
+ * kind, whether express or implied; without even the implied warranty
+ * of MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+ * GNU General Public License for more details.
+ */
+
+#include <asm/assembler.h>
+#include <linux/linkage.h>
+#include <linux/init.h>
+
+ .section ".text.head", "ax"
+
+ENTRY(brcmstb_secondary_startup)
+ /*
+ * Ensure CPU is in a sane state by disabling all IRQs and switching
+ * into SVC mode.
+ */
+ setmode PSR_I_BIT | PSR_F_BIT | SVC_MODE, r0
+
+ bl v7_invalidate_l1
+ b secondary_startup
+ENDPROC(brcmstb_secondary_startup)
diff --git a/arch/arm/mach-bcm/hotplug-brcmstb.c b/arch/arm/mach-bcm/hotplug-brcmstb.c
new file mode 100644
index 0000000..21431a6
--- /dev/null
+++ b/arch/arm/mach-bcm/hotplug-brcmstb.c
@@ -0,0 +1,311 @@
+/*
+ * Broadcom STB CPU hotplug support for ARM
+ *
+ * Copyright (C) 2013 Broadcom Corporation
+ *
+ * This program is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU General Public License as
+ * published by the Free Software Foundation version 2.
+ *
+ * This program is distributed "as is" WITHOUT ANY WARRANTY of any
+ * kind, whether express or implied; without even the implied warranty
+ * of MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+ * GNU General Public License for more details.
+ */
+
+#include <linux/delay.h>
+#include <linux/device.h>
+#include <linux/errno.h>
+#include <linux/init.h>
+#include <linux/io.h>
+#include <linux/jiffies.h>
+#include <linux/of_address.h>
+#include <linux/of_irq.h>
+#include <linux/of_platform.h>
+#include <linux/printk.h>
+#include <linux/regmap.h>
+#include <linux/smp.h>
+#include <linux/mfd/syscon.h>
+
+#include <asm/cacheflush.h>
+#include <asm/cp15.h>
+#include <asm/mach-types.h>
+#include <asm/smp_plat.h>
+
+#include "brcmstb.h"
+
+enum {
+ ZONE_MAN_CLKEN_MASK = BIT(0),
+ ZONE_MAN_RESET_CNTL_MASK = BIT(1),
+ ZONE_MAN_MEM_PWR_MASK = BIT(4),
+ ZONE_RESERVED_1_MASK = BIT(5),
+ ZONE_MAN_ISO_CNTL_MASK = BIT(6),
+ ZONE_MANUAL_CONTROL_MASK = BIT(7),
+ ZONE_PWR_DN_REQ_MASK = BIT(9),
+ ZONE_PWR_UP_REQ_MASK = BIT(10),
+ ZONE_BLK_RST_ASSERT_MASK = BIT(12),
+ ZONE_PWR_OFF_STATE_MASK = BIT(25),
+ ZONE_PWR_ON_STATE_MASK = BIT(26),
+ ZONE_DPG_PWR_STATE_MASK = BIT(28),
+ ZONE_MEM_PWR_STATE_MASK = BIT(29),
+ ZONE_RESET_STATE_MASK = BIT(31),
+ CPU0_PWR_ZONE_CTRL_REG = 1,
+ CPU_RESET_CONFIG_REG = 2,
+};
+
+static void __iomem *cpubiuctrl_block;
+static void __iomem *hif_cont_block;
+static u32 cpu0_pwr_zone_ctrl_reg;
+static u32 cpu_rst_cfg_reg;
+static u32 hif_cont_reg;
+DEFINE_PER_CPU_ALIGNED(int, per_cpu_sw_state);
+
+static int per_cpu_sw_state_rd(u32 cpu)
+{
+ sync_cache_r(SHIFT_PERCPU_PTR(&per_cpu_sw_state, per_cpu_offset(cpu)));
+ return per_cpu(per_cpu_sw_state, cpu);
+}
+
+static void per_cpu_sw_state_wr(u32 cpu, int val)
+{
+ per_cpu(per_cpu_sw_state, cpu) = val;
+ dmb();
+ sync_cache_w(SHIFT_PERCPU_PTR(&per_cpu_sw_state, per_cpu_offset(cpu)));
+ dsb_sev();
+}
+
+static void __iomem *pwr_ctrl_get_base(u32 cpu)
+{
+ void __iomem *base = cpubiuctrl_block + cpu0_pwr_zone_ctrl_reg;
+ base += (cpu_logical_map(cpu) * 4);
+ return base;
+}
+
+static u32 pwr_ctrl_rd(u32 cpu)
+{
+ void __iomem *base = pwr_ctrl_get_base(cpu);
+ return readl_relaxed(base);
+}
+
+static void pwr_ctrl_wr(u32 cpu, u32 val)
+{
+ void __iomem *base = pwr_ctrl_get_base(cpu);
+ writel(val, base);
+}
+
+static void cpu_rst_cfg_set(u32 cpu, int set)
+{
+ u32 val;
+ val = readl_relaxed(cpubiuctrl_block + cpu_rst_cfg_reg);
+ if (set)
+ val |= BIT(cpu_logical_map(cpu));
+ else
+ val &= ~BIT(cpu_logical_map(cpu));
+ writel_relaxed(val, cpubiuctrl_block + cpu_rst_cfg_reg);
+}
+
+static void cpu_set_boot_addr(u32 cpu, unsigned long boot_addr)
+{
+ const int reg_ofs = cpu_logical_map(cpu) * 8;
+ writel_relaxed(0, hif_cont_block + hif_cont_reg + reg_ofs);
+ writel_relaxed(boot_addr, hif_cont_block + hif_cont_reg + 4 + reg_ofs);
+}
+
+void brcmstb_cpu_boot(u32 cpu)
+{
+ pr_info("SMP: Booting CPU%d...\n", cpu);
+
+ /*
+ * set the reset vector to point to the secondary_startup
+ * routine
+ */
+ cpu_set_boot_addr(cpu, virt_to_phys(brcmstb_secondary_startup));
+
+ /* unhalt the cpu */
+ cpu_rst_cfg_set(cpu, 0);
+}
+
+void brcmstb_cpu_power_on(u32 cpu)
+{
+ /*
+ * The secondary cores power was cut, so we must go through
+ * power-on initialization.
+ */
+ u32 tmp;
+
+ pr_info("SMP: Powering up CPU%d...\n", cpu);
+
+ /* Request zone power up */
+ pwr_ctrl_wr(cpu, ZONE_PWR_UP_REQ_MASK);
+
+ /* Wait for the power up FSM to complete */
+ do {
+ tmp = pwr_ctrl_rd(cpu);
+ } while (!(tmp & ZONE_PWR_ON_STATE_MASK));
+
+ per_cpu_sw_state_wr(cpu, 1);
+}
+
+int brcmstb_cpu_get_power_state(u32 cpu)
+{
+ int tmp = pwr_ctrl_rd(cpu);
+ return (tmp & ZONE_RESET_STATE_MASK) ? 0 : 1;
+}
+
+void __ref brcmstb_cpu_die(u32 cpu)
+{
+ v7_exit_coherency_flush(all);
+
+ /* Prevent all interrupts from reaching this CPU. */
+ arch_local_irq_disable();
+
+ /*
+ * Final full barrier to ensure everything before this instruction has
+ * quiesced.
+ */
+ isb();
+ dsb();
+
+ per_cpu_sw_state_wr(cpu, 0);
+
+ /* Sit and wait to die */
+ wfi();
+
+ /* We should never get here... */
+ panic("Spurious interrupt on CPU %d received!\n", cpu);
+}
+
+int brcmstb_cpu_kill(u32 cpu)
+{
+ u32 tmp;
+
+ pr_info("SMP: Powering down CPU%d...\n", cpu);
+
+ while (per_cpu_sw_state_rd(cpu))
+ ;
+
+ /* Program zone reset */
+ pwr_ctrl_wr(cpu, ZONE_RESET_STATE_MASK | ZONE_BLK_RST_ASSERT_MASK |
+ ZONE_PWR_DN_REQ_MASK);
+
+ /* Verify zone reset */
+ tmp = pwr_ctrl_rd(cpu);
+ if (!(tmp & ZONE_RESET_STATE_MASK))
+ pr_err("%s: Zone reset bit for CPU %d not asserted!\n",
+ __func__, cpu);
+
+ /* Wait for power down */
+ do {
+ tmp = pwr_ctrl_rd(cpu);
+ } while (!(tmp & ZONE_PWR_OFF_STATE_MASK));
+
+ /* Settle-time from Broadcom-internal DVT reference code */
+ udelay(7);
+
+ /* Assert reset on the CPU */
+ cpu_rst_cfg_set(cpu, 1);
+
+ return 1;
+}
+
+static int __init setup_hifcpubiuctrl_regs(struct device_node *np)
+{
+ int rc = 0;
+ char *name;
+ struct device_node *syscon_np = NULL;
+
+ name = "syscon-cpu";
+
+ syscon_np = of_parse_phandle(np, name, 0);
+ if (!syscon_np) {
+ pr_err("can't find phandle %s\n", name);
+ rc = -EINVAL;
+ goto cleanup;
+ }
+
+ cpubiuctrl_block = of_iomap(syscon_np, 0);
+ if (!cpubiuctrl_block) {
+ pr_err("iomap failed for cpubiuctrl_block\n");
+ rc = -EINVAL;
+ goto cleanup;
+ }
+
+ rc = of_property_read_u32_index(np, name, CPU0_PWR_ZONE_CTRL_REG,
+ &cpu0_pwr_zone_ctrl_reg);
+ if (rc) {
+ pr_err("failed to read 1st entry from %s property (%d)\n", name,
+ rc);
+ rc = -EINVAL;
+ goto cleanup;
+ }
+
+ rc = of_property_read_u32_index(np, name, CPU_RESET_CONFIG_REG,
+ &cpu_rst_cfg_reg);
+ if (rc) {
+ pr_err("failed to read 2nd entry from %s property (%d)\n", name,
+ rc);
+ rc = -EINVAL;
+ goto cleanup;
+ }
+
+cleanup:
+ if (syscon_np)
+ of_node_put(syscon_np);
+
+ return rc;
+}
+
+static int __init setup_hifcont_regs(struct device_node *np)
+{
+ int rc = 0;
+ char *name;
+ struct device_node *syscon_np = NULL;
+
+ name = "syscon-cont";
+
+ syscon_np = of_parse_phandle(np, name, 0);
+ if (!syscon_np) {
+ pr_err("can't find phandle %s\n", name);
+ rc = -EINVAL;
+ goto cleanup;
+ }
+
+ hif_cont_block = of_iomap(syscon_np, 0);
+ if (!hif_cont_block) {
+ pr_err("iomap failed for hif_cont_block\n");
+ rc = -EINVAL;
+ goto cleanup;
+ }
+
+ /* offset is at top of hif_cont_block */
+ hif_cont_reg = 0;
+
+cleanup:
+ if (syscon_np)
+ of_node_put(syscon_np);
+
+ return rc;
+}
+
+void __init brcmstb_cpu_ctrl_setup(unsigned int max_cpus)
+{
+ int rc;
+ struct device_node *np;
+ char *name;
+
+ name = "brcm,brcmstb-smpboot";
+ np = of_find_compatible_node(NULL, NULL, name);
+ if (!np) {
+ pr_err("can't find compatible node %s\n", name);
+ return;
+ }
+
+ rc = setup_hifcpubiuctrl_regs(np);
+ if (rc)
+ return;
+
+ rc = setup_hifcont_regs(np);
+ if (rc)
+ return;
+}
+
--
1.7.1
^ permalink raw reply related
* [PATCH v6 0/8] ARM: brcmstb: Add Broadcom STB SoC support
From: Marc Carino @ 2014-02-03 21:30 UTC (permalink / raw)
To: Christian Daudt, Arnd Bergmann, Olof Johansson
Cc: Florian Fainelli, Matt Porter, Russell King,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
linux-kernel-u79uwXL29TY76Z2rM5mHXA,
devicetree-u79uwXL29TY76Z2rM5mHXA, Marc Carino
This patchset contains the board support package for the
Broadcom BCM7445 ARM-based SoC [1]. These changes contain a
minimal set of code needed for a BCM7445-based board to boot
the Linux kernel.
These changes heavily leverage the OF/devicetree framework.
v6:
- rebased to v3.14-rc1
- utilize common APIs for handling CPU power-down
- drop deprecated __cpuinit attributes
v5 (https://lkml.org/lkml/2014/1/21/640):
- rebased to v3.13 tag
- make UART DT node a child of 'rdb' node
- fix ordering of debug UART entries
v4 (https://lkml.org/lkml/2014/1/17/455):
- make a reboot driver and put it in the drivers folder
- rework DT bindings to leverage 'syscon'
- rework BSP code to use 'syscon' for all register mappings
- misc. tweaks per suggestions from v3
v3 (https://lkml.org/lkml/2014/1/14/696):
- rebased to v3.13-rc8
- switched to using 'multi_v7_defconfig'
- eliminated dependence on compile-time peripheral register access
- moved DT node iomap out from 'init_early'
- misc. minor cleanups from mailing-list discussion for v2
v2 (https://lkml.org/lkml/2013/11/26/570):
- rebased to v3.13-rc1
- moved implementation to 'mach-bcm' folder
- added CPU init for B16RM
v1:
- initial submission
[1] http://www.broadcom.com/products/Cable/Cable-Set-Top-Box-Solutions/BCM7445
Marc Carino (8):
ARM: brcmstb: add infrastructure for ARM-based Broadcom STB SoCs
power: reset: Add reboot driver for brcmstb
ARM: brcmstb: add debug UART for earlyprintk support
ARM: do CPU-specific init for Broadcom Brahma15 cores
ARM: brcmstb: add CPU binding for Broadcom Brahma15
ARM: brcmstb: add misc. DT bindings for brcmstb
ARM: brcmstb: gic: add compatible string for Broadcom Brahma15
ARM: brcmstb: dts: add a reference DTS for Broadcom 7445
.../devicetree/bindings/arm/brcm-brcmstb.txt | 95 ++++++
Documentation/devicetree/bindings/arm/cpus.txt | 1 +
Documentation/devicetree/bindings/arm/gic.txt | 1 +
arch/arm/Kconfig.debug | 15 +-
arch/arm/boot/dts/bcm7445.dts | 111 +++++++
arch/arm/configs/multi_v7_defconfig | 1 +
arch/arm/mach-bcm/Kconfig | 15 +
arch/arm/mach-bcm/Makefile | 4 +
arch/arm/mach-bcm/brcmstb.c | 104 +++++++
arch/arm/mach-bcm/brcmstb.h | 38 +++
arch/arm/mach-bcm/headsmp-brcmstb.S | 33 ++
arch/arm/mach-bcm/hotplug-brcmstb.c | 311 ++++++++++++++++++++
arch/arm/mm/proc-v7.S | 11 +
drivers/power/reset/Kconfig | 10 +
drivers/power/reset/Makefile | 1 +
drivers/power/reset/brcmstb-reboot.c | 120 ++++++++
16 files changed, 870 insertions(+), 1 deletions(-)
create mode 100644 Documentation/devicetree/bindings/arm/brcm-brcmstb.txt
create mode 100644 arch/arm/boot/dts/bcm7445.dts
create mode 100644 arch/arm/mach-bcm/brcmstb.c
create mode 100644 arch/arm/mach-bcm/brcmstb.h
create mode 100644 arch/arm/mach-bcm/headsmp-brcmstb.S
create mode 100644 arch/arm/mach-bcm/hotplug-brcmstb.c
create mode 100644 drivers/power/reset/brcmstb-reboot.c
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* RE: [PATCH v1] ARM: tegra: add nvidia,wdt-timer-id optional property
From: Andrew Chew @ 2014-02-03 21:29 UTC (permalink / raw)
To: Stephen Warren, Mark Rutland
Cc: robh+dt-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org, Pawel Moll,
ijc+devicetree-KcIKpvwj1kUDXYZnReoRVg@public.gmane.org,
galak-sgV2jX0FEOL9JmXXK+q4OQ@public.gmane.org,
rob-VoJi6FS/r0vR7s880joybQ@public.gmane.org,
thierry.reding-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org,
abrestic-F7+t8E8rja9g9hUCZPvPmw@public.gmane.org,
dgreid-F7+t8E8rja9g9hUCZPvPmw@public.gmane.org,
katierh-F7+t8E8rja9g9hUCZPvPmw@public.gmane.org,
devicetree-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
linux-doc-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
linux-tegra-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
In-Reply-To: <52F00994.7080701-3lzwWm7+Weoh9ZMKESR00Q@public.gmane.org>
> On 02/03/2014 02:16 PM, Andrew Chew wrote:
> >> On 02/03/2014 11:59 AM, Andrew Chew wrote:
> >>>> On Fri, Jan 31, 2014 at 09:46:51PM +0000, Andrew Chew wrote:
> >>>>> This optional property can be used to specify which timers are to
> >>>>> be used for hardware watchdog timeouts (via a tegra wdt driver).
> >>>>
> >>>> Is there any reason that a particular timer should be used?
> >>>
> >>> I worry about colliding with other timer allocations, and wanted to
> >>> be flexible in this regard.
> >>
> >> Are the other timer allocations represented in DT, or simply made by
> >> or hard- coded in the driver? If the former, this property seems like
> >> a good equivalent of any existing allocations. If the latter, can't
> >> the driver just allocate or hard- code the allocation in the same way as any
> existing allocations?
> >
> > From what I've seen, timer allocations are just hard-coded into whatever
> driver.
> > I didn't think this was a particularly good idea, since when writing
> > other drivers that for some reason need a timer, the author has to be
> > aware of allocations made in other, barely related drivers.
>
> I'm not sure that they would; why wouldn't the timer driver register the
> various timers with standard Linux APIs which the clients talk to, thus
> avoiding the clients having any knowledge at all of which channels are used
> for what.
>
> If you're talking about the watchdog driver, then can't we just create a
> shared header file that the clocksource and watchdog drivers both include,
> which defines the timer ID allocations?
Sure, let's go with that. In that case, this patch isn't needed, and should be
dropped.
^ permalink raw reply
* Re: [PATCH v1] ARM: tegra: add nvidia,wdt-timer-id optional property
From: Stephen Warren @ 2014-02-03 21:26 UTC (permalink / raw)
To: Andrew Chew, Mark Rutland
Cc: robh+dt-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org, Pawel Moll,
ijc+devicetree-KcIKpvwj1kUDXYZnReoRVg@public.gmane.org,
galak-sgV2jX0FEOL9JmXXK+q4OQ@public.gmane.org,
rob-VoJi6FS/r0vR7s880joybQ@public.gmane.org,
thierry.reding-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org,
abrestic-F7+t8E8rja9g9hUCZPvPmw@public.gmane.org,
dgreid-F7+t8E8rja9g9hUCZPvPmw@public.gmane.org,
katierh-F7+t8E8rja9g9hUCZPvPmw@public.gmane.org,
devicetree-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
linux-doc-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
linux-tegra-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
In-Reply-To: <643E69AA4436674C8F39DCC2C05F7638631998538B-lR+7xdUAJVNDw2glCA4ptUEOCMrvLtNR@public.gmane.org>
On 02/03/2014 02:16 PM, Andrew Chew wrote:
>> On 02/03/2014 11:59 AM, Andrew Chew wrote:
>>>> On Fri, Jan 31, 2014 at 09:46:51PM +0000, Andrew Chew wrote:
>>>>> This optional property can be used to specify which timers are to be
>>>>> used for hardware watchdog timeouts (via a tegra wdt driver).
>>>>
>>>> Is there any reason that a particular timer should be used?
>>>
>>> I worry about colliding with other timer allocations, and wanted to be
>>> flexible in this regard.
>>
>> Are the other timer allocations represented in DT, or simply made by or hard-
>> coded in the driver? If the former, this property seems like a good equivalent
>> of any existing allocations. If the latter, can't the driver just allocate or hard-
>> code the allocation in the same way as any existing allocations?
>
> From what I've seen, timer allocations are just hard-coded into whatever driver.
> I didn't think this was a particularly good idea, since when writing other drivers
> that for some reason need a timer, the author has to be aware of allocations
> made in other, barely related drivers.
I'm not sure that they would; why wouldn't the timer driver register the
various timers with standard Linux APIs which the clients talk to, thus
avoiding the clients having any knowledge at all of which channels are
used for what.
If you're talking about the watchdog driver, then can't we just create a
shared header file that the clocksource and watchdog drivers both
include, which defines the timer ID allocations?
^ permalink raw reply
* DONATION FOR YOU.
From: Charles Francis Feeney @ 2014-02-03 21:21 UTC (permalink / raw)
To: Recipients
Hi,
My name is Charles Francis Feeney, a philanthropist and the founder of The Atlantic Philanthropies, one of the largest private foundations in the world. I believe strongly in ‘giving while living.’ I had one idea that never changed in my mind — that you should use your wealth to help people and I have decided to secretly give USD 1.9Million to randomly selected individuals worldwide. On receipt of this email, you should count yourself as the lucky individual. Your email address was chosen online while searching at random. Kindly get back to me at your earliest convenience, so I know your email address is valid.
(charlesfrancis1103-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org) Email me.
Visit the web page to know more about me: http://en.wikipedia.org/wiki/Chuck_Feeney
Regards,
Charles F. Feeney
charlesfrancis1103-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* RE: [PATCH v1] ARM: tegra: add nvidia,wdt-timer-id optional property
From: Andrew Chew @ 2014-02-03 21:16 UTC (permalink / raw)
To: Stephen Warren, Mark Rutland
Cc: robh+dt-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org, Pawel Moll,
ijc+devicetree-KcIKpvwj1kUDXYZnReoRVg@public.gmane.org,
galak-sgV2jX0FEOL9JmXXK+q4OQ@public.gmane.org,
rob-VoJi6FS/r0vR7s880joybQ@public.gmane.org,
thierry.reding-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org,
abrestic-F7+t8E8rja9g9hUCZPvPmw@public.gmane.org,
dgreid-F7+t8E8rja9g9hUCZPvPmw@public.gmane.org,
katierh-F7+t8E8rja9g9hUCZPvPmw@public.gmane.org,
devicetree-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
linux-doc-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
linux-tegra-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
In-Reply-To: <52F005A0.4080807-3lzwWm7+Weoh9ZMKESR00Q@public.gmane.org>
> On 02/03/2014 11:59 AM, Andrew Chew wrote:
> >> On Fri, Jan 31, 2014 at 09:46:51PM +0000, Andrew Chew wrote:
> >>> This optional property can be used to specify which timers are to be
> >>> used for hardware watchdog timeouts (via a tegra wdt driver).
> >>
> >> Is there any reason that a particular timer should be used?
> >
> > I worry about colliding with other timer allocations, and wanted to be
> > flexible in this regard.
>
> Are the other timer allocations represented in DT, or simply made by or hard-
> coded in the driver? If the former, this property seems like a good equivalent
> of any existing allocations. If the latter, can't the driver just allocate or hard-
> code the allocation in the same way as any existing allocations?
>From what I've seen, timer allocations are just hard-coded into whatever driver.
I didn't think this was a particularly good idea, since when writing other drivers
that for some reason need a timer, the author has to be aware of allocations
made in other, barely related drivers. In addition, what seems like an arbitrary
allocation in one scenario, I anticipate may not be completely arbitrary in
a different scenario, so I thought it would be better to freeze the device driver
code, and allow for flexibility at the device tree level.
But I'll do whatever others think is right. I can make my watchdog driver just take
an arbitrary (to me right now) timer and instantiate one watchdog for it. If I'm to
do that, then this device node property isn't necessary, and we can drop this patch.
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: [PATCH v1] ARM: tegra: add nvidia,wdt-timer-id optional property
From: Stephen Warren @ 2014-02-03 21:09 UTC (permalink / raw)
To: Andrew Chew, Mark Rutland
Cc: robh+dt-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org, Pawel Moll,
ijc+devicetree-KcIKpvwj1kUDXYZnReoRVg@public.gmane.org,
galak-sgV2jX0FEOL9JmXXK+q4OQ@public.gmane.org,
rob-VoJi6FS/r0vR7s880joybQ@public.gmane.org,
thierry.reding-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org,
abrestic-F7+t8E8rja9g9hUCZPvPmw@public.gmane.org,
dgreid-F7+t8E8rja9g9hUCZPvPmw@public.gmane.org,
katierh-F7+t8E8rja9g9hUCZPvPmw@public.gmane.org,
devicetree-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
linux-doc-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
linux-tegra-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
In-Reply-To: <643E69AA4436674C8F39DCC2C05F763863199852CA-lR+7xdUAJVNDw2glCA4ptUEOCMrvLtNR@public.gmane.org>
On 02/03/2014 11:59 AM, Andrew Chew wrote:
>> On Fri, Jan 31, 2014 at 09:46:51PM +0000, Andrew Chew wrote:
>>> This optional property can be used to specify which timers are to be
>>> used for hardware watchdog timeouts (via a tegra wdt driver).
>>
>> Is there any reason that a particular timer should be used?
>
> I worry about colliding with other timer allocations, and wanted to be
> flexible in this regard.
Are the other timer allocations represented in DT, or simply made by or
hard-coded in the driver? If the former, this property seems like a good
equivalent of any existing allocations. If the latter, can't the driver
just allocate or hard-code the allocation in the same way as any
existing allocations?
^ permalink raw reply
* Re: [PATCH 1/2] clocksource: sunxi: Add new compatibles
From: Daniel Lezcano @ 2014-02-03 20:17 UTC (permalink / raw)
To: Maxime Ripard
Cc: tglx-hfZtesqFncYOwBW4kG4KsQ,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
devicetree-u79uwXL29TY76Z2rM5mHXA
In-Reply-To: <20140203194505.GF25625@lukather>
On 02/03/2014 08:45 PM, Maxime Ripard wrote:
> Hi Daniel,
>
> (Adding DT mailing-list in CC)
>
> On Mon, Feb 03, 2014 at 05:36:03PM +0100, Daniel Lezcano wrote:
>> On 02/02/2014 02:37 PM, Maxime Ripard wrote:
>>> The Allwinner A10 compatibles were following a slightly different compatible
>>> patterns than the rest of the SoCs for historical reasons. Add compatibles
>>> matching the other pattern to the timer driver for consistency, and keep the
>>> older one for backward compatibility.
>>
>> Hi Maxime,
>>
>> is it really needed to keep the old pattern ?
>
> We agreed during the ARM Kernel Summit to consider the DT as a stable
> ABI.
>
> While I'd be ok with removing the older ones, that also means that we
> would break the boot of newer kernels with older DT, so yes, we
> actually need to keep the old compatibles.
Thanks for the clarification.
So these old compatibles will stay there 'ad vitam aeternam', right ?
>>> Signed-off-by: Maxime Ripard <maxime.ripard-wi1+55ScJUtKEb57/3fJTNBPR1lH4CV8@public.gmane.org>
>>> ---
>>> Documentation/devicetree/bindings/timer/allwinner,sun4i-timer.txt | 5 +++--
>>> drivers/clocksource/sun4i_timer.c | 4 ++++
>>> 2 files changed, 7 insertions(+), 2 deletions(-)
>>>
>>> diff --git a/Documentation/devicetree/bindings/timer/allwinner,sun4i-timer.txt b/Documentation/devicetree/bindings/timer/allwinner,sun4i-timer.txt
>>> index 48aeb78..d9e35ae 100644
>>> --- a/Documentation/devicetree/bindings/timer/allwinner,sun4i-timer.txt
>>> +++ b/Documentation/devicetree/bindings/timer/allwinner,sun4i-timer.txt
>>> @@ -2,7 +2,8 @@ Allwinner A1X SoCs Timer Controller
>>>
>>> Required properties:
>>>
>>> -- compatible : should be "allwinner,sun4i-timer"
>>> +- compatible : should be "allwinner,sun4i-a10-timer"
>>> + (Deprecated "allwinner,sun4i-timer")
>>> - reg : Specifies base physical address and size of the registers.
>>> - interrupts : The interrupt of the first timer
>>> - clocks: phandle to the source clock (usually a 24 MHz fixed clock)
>>> @@ -10,7 +11,7 @@ Required properties:
>>> Example:
>>>
>>> timer {
>>> - compatible = "allwinner,sun4i-timer";
>>> + compatible = "allwinner,sun4i-a10-timer";
>>> reg = <0x01c20c00 0x400>;
>>> interrupts = <22>;
>>> clocks = <&osc>;
>>> diff --git a/drivers/clocksource/sun4i_timer.c b/drivers/clocksource/sun4i_timer.c
>>> index bf497af..de03895 100644
>>> --- a/drivers/clocksource/sun4i_timer.c
>>> +++ b/drivers/clocksource/sun4i_timer.c
>>> @@ -196,5 +196,9 @@ static void __init sun4i_timer_init(struct device_node *node)
>>> clockevents_config_and_register(&sun4i_clockevent, rate,
>>> TIMER_SYNC_TICKS, 0xffffffff);
>>> }
>>> +CLOCKSOURCE_OF_DECLARE(sun4i, "allwinner,sun4i-a10-timer",
>>> + sun4i_timer_init);
>>> +
>>> +/* Deprecated */
>>> CLOCKSOURCE_OF_DECLARE(sun4i, "allwinner,sun4i-timer",
>>> sun4i_timer_init);
>>>
>>
>>
>> --
>> <http://www.linaro.org/> Linaro.org │ Open source software for ARM SoCs
>>
>> Follow Linaro: <http://www.facebook.com/pages/Linaro> Facebook |
>> <http://twitter.com/#!/linaroorg> Twitter |
>> <http://www.linaro.org/linaro-blog/> Blog
>>
>
--
<http://www.linaro.org/> Linaro.org │ Open source software for ARM SoCs
Follow Linaro: <http://www.facebook.com/pages/Linaro> Facebook |
<http://twitter.com/#!/linaroorg> Twitter |
<http://www.linaro.org/linaro-blog/> Blog
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: [RFC PATCH V3 1/4] pci: APM X-Gene PCIe controller driver
From: Tanmay Inamdar @ 2014-02-03 20:14 UTC (permalink / raw)
To: Arnd Bergmann
Cc: Bjorn Helgaas, Jason Gunthorpe, Grant Likely, Rob Herring,
Catalin Marinas, Rob Landley, linux-pci@vger.kernel.org,
devicetree@vger.kernel.org, linux-arm-kernel, linux-doc,
linux-kernel, patches, Jon Masters, Liviu Dudau
In-Reply-To: <4985267.LnsktRmabM@wuerfel>
On Mon, Feb 3, 2014 at 12:12 PM, Arnd Bergmann <arnd@arndb.de> wrote:
> On Monday 03 February 2014 11:42:22 Tanmay Inamdar wrote:
>> On Thu, Jan 30, 2014 at 6:16 AM, Arnd Bergmann <arnd@arndb.de> wrote:
>> > On Friday 24 January 2014, Tanmay Inamdar wrote:
>> >
>> >> +static void xgene_pcie_fixup_bridge(struct pci_dev *dev)
>> >> +{
>> >> + int i;
>> >> +
>> >> + /* Hide the PCI host BARs from the kernel as their content doesn't
>> >> + * fit well in the resource management
>> >> + */
>> >> + for (i = 0; i < DEVICE_COUNT_RESOURCE; i++) {
>> >> + dev->resource[i].start = dev->resource[i].end = 0;
>> >> + dev->resource[i].flags = 0;
>> >> + }
>> >> + dev_info(&dev->dev, "Hiding X-Gene pci host bridge resources %s\n",
>> >> + pci_name(dev));
>> >> +}
>> >> +DECLARE_PCI_FIXUP_HEADER(XGENE_PCIE_VENDORID, XGENE_PCIE_DEVICEID,
>> >> + xgene_pcie_fixup_bridge);
>> >
>> > Shouldn't this be gone now that the host bridge is correctly shown
>> > at the domain root?
>>
>> In inbound region configuration, whole DDR space is mapped into the
>> BAR of RC. When Linux PCI mid-layer starts enumerating, it reads the
>> size of BAR of RC and tries to fit it into the memory resource. First
>> thing is that the outbound memory is not enough to map the inbound BAR
>> space. This creates problem with the resource management logic and
>> second thing is that, it is not required to map inbound BAR space RC
>> bar as no one will be accessing it further.
>>
>> As Jason suggested, Bridge BAR's should be 0 size unless the bridge
>> itself has registers. However this is not the case with XGene PCIe
>> controller. It may have been inherited from the legacy design.
>> 'arch/powerpc/sysdev/ppc4xx_pci.c' has similar fixup function.
>
> Are you sure that is true for the root bridge as well? I don't
> remember the details, but I though that for the host bridge,
> we don't actually look at the BARs at all.
>
>> > If you want to try out the I/O space, I'd suggest using an Intel
>> > e1000 network card, which has both memory and i/o space. There
>> > is a patch at http://www.spinics.net/lists/linux-pci/msg27684.html
>> > that lets you check the I/O registers on it, or you can go
>> > through /dev/port from user space.
>> >
>> > I also haven't seen your patch that adds pci_ioremap_io() for
>> > arm64. It would be helpful to keep it in the same patch
>> > series, since it won't build without this patch.
>>
>> I will post the arm64 pci patch along with next revision of this
>> driver. That will cover the 'pci_ioremap_io' as well.
>
> Please note that today, Liviu Dudau has also posted patches for this,
> so you should coordinate a bit.
Yes. Just looking at his patches. Looks similar to what I have. I will
wait till your solution shapes up.
>
> Arnd
^ permalink raw reply
* Re: [RFC PATCH V3 1/4] pci: APM X-Gene PCIe controller driver
From: Arnd Bergmann @ 2014-02-03 20:12 UTC (permalink / raw)
To: Tanmay Inamdar
Cc: Bjorn Helgaas, Jason Gunthorpe, Grant Likely, Rob Herring,
Catalin Marinas, Rob Landley, linux-pci@vger.kernel.org,
devicetree@vger.kernel.org, linux-arm-kernel, linux-doc,
linux-kernel, patches, Jon Masters, Liviu Dudau
In-Reply-To: <CACoXjcnXoysMeBsGuOb3t5b10zdeJ8pOnuOOzR8AaZhsOOYVEw@mail.gmail.com>
On Monday 03 February 2014 11:42:22 Tanmay Inamdar wrote:
> On Thu, Jan 30, 2014 at 6:16 AM, Arnd Bergmann <arnd@arndb.de> wrote:
> > On Friday 24 January 2014, Tanmay Inamdar wrote:
> >
> >> +static void xgene_pcie_fixup_bridge(struct pci_dev *dev)
> >> +{
> >> + int i;
> >> +
> >> + /* Hide the PCI host BARs from the kernel as their content doesn't
> >> + * fit well in the resource management
> >> + */
> >> + for (i = 0; i < DEVICE_COUNT_RESOURCE; i++) {
> >> + dev->resource[i].start = dev->resource[i].end = 0;
> >> + dev->resource[i].flags = 0;
> >> + }
> >> + dev_info(&dev->dev, "Hiding X-Gene pci host bridge resources %s\n",
> >> + pci_name(dev));
> >> +}
> >> +DECLARE_PCI_FIXUP_HEADER(XGENE_PCIE_VENDORID, XGENE_PCIE_DEVICEID,
> >> + xgene_pcie_fixup_bridge);
> >
> > Shouldn't this be gone now that the host bridge is correctly shown
> > at the domain root?
>
> In inbound region configuration, whole DDR space is mapped into the
> BAR of RC. When Linux PCI mid-layer starts enumerating, it reads the
> size of BAR of RC and tries to fit it into the memory resource. First
> thing is that the outbound memory is not enough to map the inbound BAR
> space. This creates problem with the resource management logic and
> second thing is that, it is not required to map inbound BAR space RC
> bar as no one will be accessing it further.
>
> As Jason suggested, Bridge BAR's should be 0 size unless the bridge
> itself has registers. However this is not the case with XGene PCIe
> controller. It may have been inherited from the legacy design.
> 'arch/powerpc/sysdev/ppc4xx_pci.c' has similar fixup function.
Are you sure that is true for the root bridge as well? I don't
remember the details, but I though that for the host bridge,
we don't actually look at the BARs at all.
> > If you want to try out the I/O space, I'd suggest using an Intel
> > e1000 network card, which has both memory and i/o space. There
> > is a patch at http://www.spinics.net/lists/linux-pci/msg27684.html
> > that lets you check the I/O registers on it, or you can go
> > through /dev/port from user space.
> >
> > I also haven't seen your patch that adds pci_ioremap_io() for
> > arm64. It would be helpful to keep it in the same patch
> > series, since it won't build without this patch.
>
> I will post the arm64 pci patch along with next revision of this
> driver. That will cover the 'pci_ioremap_io' as well.
Please note that today, Liviu Dudau has also posted patches for this,
so you should coordinate a bit.
Arnd
^ permalink raw reply
* Re: [PATCH 1/2] clocksource: sunxi: Add new compatibles
From: Rob Herring @ 2014-02-03 20:11 UTC (permalink / raw)
To: Maxime Ripard
Cc: Daniel Lezcano, Thomas Gleixner,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r@public.gmane.org,
devicetree-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
In-Reply-To: <20140203194505.GF25625@lukather>
On Mon, Feb 3, 2014 at 1:45 PM, Maxime Ripard
<maxime.ripard-wi1+55ScJUtKEb57/3fJTNBPR1lH4CV8@public.gmane.org> wrote:
> Hi Daniel,
>
> (Adding DT mailing-list in CC)
>
> On Mon, Feb 03, 2014 at 05:36:03PM +0100, Daniel Lezcano wrote:
>> On 02/02/2014 02:37 PM, Maxime Ripard wrote:
>> >The Allwinner A10 compatibles were following a slightly different compatible
>> >patterns than the rest of the SoCs for historical reasons. Add compatibles
>> >matching the other pattern to the timer driver for consistency, and keep the
>> >older one for backward compatibility.
>>
>> Hi Maxime,
>>
>> is it really needed to keep the old pattern ?
>
> We agreed during the ARM Kernel Summit to consider the DT as a stable
> ABI.
>
> While I'd be ok with removing the older ones, that also means that we
> would break the boot of newer kernels with older DT, so yes, we
> actually need to keep the old compatibles.
It all depends if that would really cause problems for a given
platform. So if Allwinner DT support is a moving target, then changing
is probably okay. For example, if anyone using the platform is going
to need to update their DTB to add more nodes to get various features
anyway, then breaking it is not all that important.
Rob
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: [PATCH] arm64: Add architecture support for PCI
From: Arnd Bergmann @ 2014-02-03 20:05 UTC (permalink / raw)
To: linaro-kernel
Cc: Liviu Dudau, devicetree@vger.kernel.org, linux-pci, LKML,
Catalin Marinas, Bjorn Helgaas, LAKML
In-Reply-To: <20140203191837.GC4889@e106497-lin.cambridge.arm.com>
On Monday 03 February 2014 19:18:38 Liviu Dudau wrote:
> On Mon, Feb 03, 2014 at 06:58:56PM +0000, Arnd Bergmann wrote:
> > On Monday 03 February 2014 18:43:48 Liviu Dudau wrote:
> > > diff --git a/arch/arm64/include/asm/io.h b/arch/arm64/include/asm/io.h
> > > index 4cc813e..ce5bad2 100644
> > > --- a/arch/arm64/include/asm/io.h
> > > +++ b/arch/arm64/include/asm/io.h
> > > @@ -120,9 +120,13 @@ static inline u64 __raw_readq(const volatile void __iomem *addr)
> > > /*
> > > * I/O port access primitives.
> > > */
> > > +#define arch_has_dev_port() (0)
> >
> > Why not?
>
> Maybe I got it the wrong way around, but the comment in include/linux/io.h says:
>
> /*
> * Some systems do not have legacy ISA devices.
> * /dev/port is not a valid interface on these systems.
> * So for those archs, <asm/io.h> should define the following symbol.
> */
>
> So ... defining it should mean no legacy ISA devices, right?
I would read that comment as referring to systems that don't have
any I/O space. If you have PCI, you can by definition have ISA
compatible devices behind a bridge. A typical example would be
a VGA card that supports the 03c0-03df port range.
> >
> > > #define IO_SPACE_LIMIT 0xffff
> >
> > You probably want to increase this a bit, to allow multiple host bridges
> > to have their own I/O space.
>
> OK, but to what size?
2 MB was a compromise on arm32 to allow up to 32 PCI host bridges but not
take up too much virtual space. On arm64 it should be at least as big.
Could be more than that, although I don't see a reason why it should be,
unless we expect to see systems with tons of host bridges, or buses
that exceed 64KB of I/O space.
> > > +#define ioport_map(port, nr) (PCI_IOBASE + ((port) & IO_SPACE_LIMIT))
> > > +#define ioport_unmap(addr)
> >
> > inline functions?
>
> Will do, thanks!
I suppose you can actually use the generic implementation from
asm-generic/io.h, and fix it by using the definition you have
above, since it's currently broken.
> > > diff --git a/arch/arm64/include/asm/pci.h b/arch/arm64/include/asm/pci.h
> > > new file mode 100644
> > > index 0000000..dd084a3
> > > --- /dev/null
> > > +++ b/arch/arm64/include/asm/pci.h
> > > @@ -0,0 +1,35 @@
> > > +#ifndef __ASM_PCI_H
> > > +#define __ASM_PCI_H
> > > +#ifdef __KERNEL__
> > > +
> > > +#include <linux/types.h>
> > > +#include <linux/slab.h>
> > > +#include <linux/dma-mapping.h>
> > > +
> > > +#include <asm/io.h>
> > > +#include <asm-generic/pci-bridge.h>
> > > +#include <asm-generic/pci-dma-compat.h>
> > > +
> > > +#define PCIBIOS_MIN_IO 0
> > > +#define PCIBIOS_MIN_MEM 0
> >
> > PCIBIOS_MIN_IO is normally set to 0x1000, to stay out of the ISA range.
>
> :) No ISA support! (Die ISA, die!!)
If only it were that easy.
> > > diff --git a/arch/arm64/kernel/pci.c b/arch/arm64/kernel/pci.c
> > > new file mode 100644
> > > index 0000000..7b652cf
> > > --- /dev/null
> > > +++ b/arch/arm64/kernel/pci.c
> > > @@ -0,0 +1,112 @@
> >
> > None of this looks really arm64 specific, nor should it be. I think
> > we should try a little harder to move this as a default implementation
> > into common code, even if we start out by having all architectures
> > override it.
>
> Agree. This is the RFC version. I didn't dare to post a patch with fixes
> for all architectures. :)
No need to change the other architectures. You can make it opt-in for
now and just put the code into a common location.
An interesting question however is what the transition plan is to
have the code shared between arm32 and arm64: We will certainly need
to share at least the dw-pcie and the generic SBSA compliant pci
implementation.
> > > +int pci_ioremap_io(unsigned int offset, phys_addr_t phys_addr)
> > > +{
> > > + BUG_ON(offset + SZ_64K - 1 > IO_SPACE_LIMIT);
> > > +
> > > + return ioremap_page_range((unsigned long)PCI_IOBASE + offset,
> > > + (unsigned long)PCI_IOBASE + offset + SZ_64K,
> > > + phys_addr,
> > > + __pgprot(PROT_DEVICE_nGnRE));
> > > +}
> >
> > Not sure if we want to treat this one as architecture specific though.
> > It certainly won't be portable to x86, but it could be shared with
> > a couple of others. We may also want to redesign the interface.
> > I've been thinking we could make this function allocate space in the
> > Linux virtual I/O space aperture, and pass two resources into it
> > (physical I/O aperture and bus I/O range), and get the actual
> > io_offset as the return value, or a negative error number.
>
> Not sure I completely follow your idea.
Something like this (coded in mail client, don't try to compile):
#define IO_SPACE_PAGES (IO_SPACE_LIMIT + 1) / PAGE_SIZE)
static DECLARE_BITMAP(pci_iospace, IO_SPACE_PAGES);
unsigned long pci_ioremap_io(const struct resource *bus, const struct resource phys)
{
unsigned long start, len, virt_start;
int error;
/* use logical address == bus address if possible */
start = bus->start / PAGE_SIZE;
if (start > IO_SPACE_LIMIT / PAGE_SIZE)
start = 0;
/*
* try finding free space for the whole size first,
* fall back to 64K if not available
*/
len = min(resource_size(bus), resource_size(phys);
start = bitmap_find_next_zero_area(pci_iospace, IO_SPACE_PAGES,
start, len / PAGE_SIZE, 0);
if (start == IO_SPACE_PAGES && len > SZ_64K)
len = SZ_64K;
start = 0;
start = bitmap_find_next_zero_area(pci_iospace, IO_SPACE_PAGES,
start, len / PAGE_SIZE, 0);
}
/* no 64K area found */
if (start == IO_SPACE_PAGES)
return -ENOMEM;
/* ioremap physical aperture to virtual aperture */
virt_start = start * PAGE_SIZE + (unsigned long)PCI_IOBASE;
error = ioremap_page_range(virt_start, virt_start + len,
phys->start, __pgprot(PROT_DEVICE_nGnRE));
if (error)
return error;
bitmap_set(start, len / PAGE_SIZE);
/* return io_offset */
return start * PAGE_SIZE - bus->start;
}
EXPORT_SYMBOL_GPL(pci_ioremap_io);
Arnd
^ permalink raw reply
* Re: [PATCH 1/2] clocksource: sunxi: Add new compatibles
From: Maxime Ripard @ 2014-02-03 19:45 UTC (permalink / raw)
To: Daniel Lezcano
Cc: tglx-hfZtesqFncYOwBW4kG4KsQ,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
devicetree-u79uwXL29TY76Z2rM5mHXA
In-Reply-To: <52EFC573.2050302-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org>
[-- Attachment #1: Type: text/plain, Size: 3170 bytes --]
Hi Daniel,
(Adding DT mailing-list in CC)
On Mon, Feb 03, 2014 at 05:36:03PM +0100, Daniel Lezcano wrote:
> On 02/02/2014 02:37 PM, Maxime Ripard wrote:
> >The Allwinner A10 compatibles were following a slightly different compatible
> >patterns than the rest of the SoCs for historical reasons. Add compatibles
> >matching the other pattern to the timer driver for consistency, and keep the
> >older one for backward compatibility.
>
> Hi Maxime,
>
> is it really needed to keep the old pattern ?
We agreed during the ARM Kernel Summit to consider the DT as a stable
ABI.
While I'd be ok with removing the older ones, that also means that we
would break the boot of newer kernels with older DT, so yes, we
actually need to keep the old compatibles.
> >Signed-off-by: Maxime Ripard <maxime.ripard-wi1+55ScJUtKEb57/3fJTNBPR1lH4CV8@public.gmane.org>
> >---
> > Documentation/devicetree/bindings/timer/allwinner,sun4i-timer.txt | 5 +++--
> > drivers/clocksource/sun4i_timer.c | 4 ++++
> > 2 files changed, 7 insertions(+), 2 deletions(-)
> >
> >diff --git a/Documentation/devicetree/bindings/timer/allwinner,sun4i-timer.txt b/Documentation/devicetree/bindings/timer/allwinner,sun4i-timer.txt
> >index 48aeb78..d9e35ae 100644
> >--- a/Documentation/devicetree/bindings/timer/allwinner,sun4i-timer.txt
> >+++ b/Documentation/devicetree/bindings/timer/allwinner,sun4i-timer.txt
> >@@ -2,7 +2,8 @@ Allwinner A1X SoCs Timer Controller
> >
> > Required properties:
> >
> >-- compatible : should be "allwinner,sun4i-timer"
> >+- compatible : should be "allwinner,sun4i-a10-timer"
> >+ (Deprecated "allwinner,sun4i-timer")
> > - reg : Specifies base physical address and size of the registers.
> > - interrupts : The interrupt of the first timer
> > - clocks: phandle to the source clock (usually a 24 MHz fixed clock)
> >@@ -10,7 +11,7 @@ Required properties:
> > Example:
> >
> > timer {
> >- compatible = "allwinner,sun4i-timer";
> >+ compatible = "allwinner,sun4i-a10-timer";
> > reg = <0x01c20c00 0x400>;
> > interrupts = <22>;
> > clocks = <&osc>;
> >diff --git a/drivers/clocksource/sun4i_timer.c b/drivers/clocksource/sun4i_timer.c
> >index bf497af..de03895 100644
> >--- a/drivers/clocksource/sun4i_timer.c
> >+++ b/drivers/clocksource/sun4i_timer.c
> >@@ -196,5 +196,9 @@ static void __init sun4i_timer_init(struct device_node *node)
> > clockevents_config_and_register(&sun4i_clockevent, rate,
> > TIMER_SYNC_TICKS, 0xffffffff);
> > }
> >+CLOCKSOURCE_OF_DECLARE(sun4i, "allwinner,sun4i-a10-timer",
> >+ sun4i_timer_init);
> >+
> >+/* Deprecated */
> > CLOCKSOURCE_OF_DECLARE(sun4i, "allwinner,sun4i-timer",
> > sun4i_timer_init);
> >
>
>
> --
> <http://www.linaro.org/> Linaro.org │ Open source software for ARM SoCs
>
> Follow Linaro: <http://www.facebook.com/pages/Linaro> Facebook |
> <http://twitter.com/#!/linaroorg> Twitter |
> <http://www.linaro.org/linaro-blog/> Blog
>
--
Maxime Ripard, Free Electrons
Embedded Linux, Kernel and Android engineering
http://free-electrons.com
[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 836 bytes --]
^ permalink raw reply
* Re: [RFC PATCH V3 1/4] pci: APM X-Gene PCIe controller driver
From: Tanmay Inamdar @ 2014-02-03 19:42 UTC (permalink / raw)
To: Arnd Bergmann
Cc: Bjorn Helgaas, Jason Gunthorpe, Grant Likely, Rob Herring,
Catalin Marinas, Rob Landley, linux-pci@vger.kernel.org,
devicetree@vger.kernel.org, linux-arm-kernel, linux-doc,
linux-kernel, patches, Jon Masters
In-Reply-To: <201401301516.27091.arnd@arndb.de>
On Thu, Jan 30, 2014 at 6:16 AM, Arnd Bergmann <arnd@arndb.de> wrote:
> On Friday 24 January 2014, Tanmay Inamdar wrote:
>
>> +static void xgene_pcie_fixup_bridge(struct pci_dev *dev)
>> +{
>> + int i;
>> +
>> + /* Hide the PCI host BARs from the kernel as their content doesn't
>> + * fit well in the resource management
>> + */
>> + for (i = 0; i < DEVICE_COUNT_RESOURCE; i++) {
>> + dev->resource[i].start = dev->resource[i].end = 0;
>> + dev->resource[i].flags = 0;
>> + }
>> + dev_info(&dev->dev, "Hiding X-Gene pci host bridge resources %s\n",
>> + pci_name(dev));
>> +}
>> +DECLARE_PCI_FIXUP_HEADER(XGENE_PCIE_VENDORID, XGENE_PCIE_DEVICEID,
>> + xgene_pcie_fixup_bridge);
>
> Shouldn't this be gone now that the host bridge is correctly shown
> at the domain root?
In inbound region configuration, whole DDR space is mapped into the
BAR of RC. When Linux PCI mid-layer starts enumerating, it reads the
size of BAR of RC and tries to fit it into the memory resource. First
thing is that the outbound memory is not enough to map the inbound BAR
space. This creates problem with the resource management logic and
second thing is that, it is not required to map inbound BAR space RC
bar as no one will be accessing it further.
As Jason suggested, Bridge BAR's should be 0 size unless the bridge
itself has registers. However this is not the case with XGene PCIe
controller. It may have been inherited from the legacy design.
'arch/powerpc/sysdev/ppc4xx_pci.c' has similar fixup function.
>
>> +static int xgene_pcie_setup(int nr, struct pci_sys_data *sys)
>> +{
>> + struct xgene_pcie_port *pp = sys->private_data;
>> + struct resource *io = &pp->realio;
>> +
>> + io->start = sys->domain * SZ_64K;
>> + io->end = io->start + SZ_64K;
>> + io->flags = pp->io.res.flags;
>> + io->name = "PCI IO";
>> + pci_ioremap_io(io->start, pp->io.res.start);
>> +
>> + pci_add_resource_offset(&sys->resources, io, sys->io_offset);
>> + sys->mem_offset = pp->mem.res.start - pp->mem.pci_addr;
>> + pci_add_resource_offset(&sys->resources, &pp->mem.res,
>> + sys->mem_offset);
>> + return 1;
>> +}
>
> Thanks for bringing back the I/O space handling.
>
> You don't seem to set sys->io_offset anywhere, but each of the
> ports listed in your DT starts a local bus I/O register range
> at port 0.
>
> AFAICT, you need to add (somewhere)
>
> sys->io_offset = pp->realio.start - pp->io.pci_addr;
>
> but there could be something else missing. You clearly haven't
> tested if the I/O space actually works.
That is correct :-). Could not find the card. Thanks for the patch below.
>
> If you want to try out the I/O space, I'd suggest using an Intel
> e1000 network card, which has both memory and i/o space. There
> is a patch at http://www.spinics.net/lists/linux-pci/msg27684.html
> that lets you check the I/O registers on it, or you can go
> through /dev/port from user space.
>
> I also haven't seen your patch that adds pci_ioremap_io() for
> arm64. It would be helpful to keep it in the same patch
> series, since it won't build without this patch.
I will post the arm64 pci patch along with next revision of this
driver. That will cover the 'pci_ioremap_io' as well.
>
> Arnd
^ permalink raw reply
* Re: [PATCH v3 8/8] ARM: dts: sun7i: Add ethernet alias for GMAC
From: Maxime Ripard @ 2014-02-03 19:38 UTC (permalink / raw)
To: Chen-Yu Tsai
Cc: Emilio Lopez, Mike Turquette,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
linux-sunxi-/JYPxA39Uh5TLH3MbocFFw,
devicetree-u79uwXL29TY76Z2rM5mHXA,
linux-kernel-u79uwXL29TY76Z2rM5mHXA
In-Reply-To: <1391398346-5094-9-git-send-email-wens-jdAy2FN1RRM@public.gmane.org>
[-- Attachment #1: Type: text/plain, Size: 1188 bytes --]
On Mon, Feb 03, 2014 at 11:32:26AM +0800, Chen-Yu Tsai wrote:
> U-Boot will insert MAC address into the device tree image.
> It looks up ethernet[0-5] aliases to find the ethernet nodes.
> Alias GMAC as ethernet0, as it is the only ethernet controller used.
>
> Signed-off-by: Chen-Yu Tsai <wens-jdAy2FN1RRM@public.gmane.org>
> ---
> arch/arm/boot/dts/sun7i-a20.dtsi | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/arch/arm/boot/dts/sun7i-a20.dtsi b/arch/arm/boot/dts/sun7i-a20.dtsi
> index 65fb8d0..c48fb11 100644
> --- a/arch/arm/boot/dts/sun7i-a20.dtsi
> +++ b/arch/arm/boot/dts/sun7i-a20.dtsi
> @@ -17,7 +17,7 @@
> interrupt-parent = <&gic>;
>
> aliases {
> - ethernet0 = &emac;
> + ethernet0 = &gmac;
> };
I'm not very fond of this patch.
People might rely on the fact that ethernet0 is actually the emac, and
are expecting u-boot to fill the ethaddr variable to the emac, and not
the gmac.
Since u-boot is totally able to deal with several ethernet addresses,
please add it as ethernet1.
Maxime
--
Maxime Ripard, Free Electrons
Embedded Linux, Kernel and Android engineering
http://free-electrons.com
[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 836 bytes --]
^ permalink raw reply
* Re: [PATCH v3 2/8] ARM: dts: sun7i: Add GMAC clock node to sun7i DTSI
From: Maxime Ripard @ 2014-02-03 19:34 UTC (permalink / raw)
To: Chen-Yu Tsai
Cc: Emilio Lopez, Mike Turquette,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
linux-sunxi-/JYPxA39Uh5TLH3MbocFFw,
devicetree-u79uwXL29TY76Z2rM5mHXA,
linux-kernel-u79uwXL29TY76Z2rM5mHXA
In-Reply-To: <1391398346-5094-3-git-send-email-wens-jdAy2FN1RRM@public.gmane.org>
[-- Attachment #1: Type: text/plain, Size: 1215 bytes --]
On Mon, Feb 03, 2014 at 11:32:20AM +0800, Chen-Yu Tsai wrote:
> The GMAC uses 1 of 2 sources for its transmit clock, depending on the
> PHY interface mode. Add both sources as dummy clocks, and as parents
> to the GMAC clock node.
>
> Signed-off-by: Chen-Yu Tsai <wens-jdAy2FN1RRM@public.gmane.org>
> ---
> arch/arm/boot/dts/sun7i-a20.dtsi | 28 ++++++++++++++++++++++++++++
> 1 file changed, 28 insertions(+)
>
> diff --git a/arch/arm/boot/dts/sun7i-a20.dtsi b/arch/arm/boot/dts/sun7i-a20.dtsi
> index 1595e9a..fc7f470 100644
> --- a/arch/arm/boot/dts/sun7i-a20.dtsi
> +++ b/arch/arm/boot/dts/sun7i-a20.dtsi
> @@ -314,6 +314,34 @@
> };
>
> /*
> + * The following two are dummy clocks, placeholders used
> + * on gmac_tx clock. The actual frequency and availability
> + * depends on the external PHY, operation mode and link
> + * speed.
> + */
If it depends on the external PHY, I guess that means it also depends
on the board, right? Or is the GMAC supposed to always have that clock
running at 25MHz, no matter what PHY is connected to it?
Maxime
--
Maxime Ripard, Free Electrons
Embedded Linux, Kernel and Android engineering
http://free-electrons.com
[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 836 bytes --]
^ permalink raw reply
* Re: [PATCH] pci: Add support for creating a generic host_bridge from device tree
From: Arnd Bergmann @ 2014-02-03 19:31 UTC (permalink / raw)
To: Liviu Dudau
Cc: linux-pci, Bjorn Helgaas, Catalin Marinas, Will Deacon, LKML,
devicetree@vger.kernel.org, LAKML, linaro-kernel
In-Reply-To: <20140203190649.GB4889@e106497-lin.cambridge.arm.com>
On Monday 03 February 2014 19:06:49 Liviu Dudau wrote:
> On Mon, Feb 03, 2014 at 06:46:10PM +0000, Arnd Bergmann wrote:
> > On Monday 03 February 2014 18:33:48 Liviu Dudau wrote:
> > > +/**
> > > + * pci_host_bridge_of_get_ranges - Parse PCI host bridge resources from DT
> > > + * @dev: device node of the host bridge having the range property
> > > + * @resources: list where the range of resources will be added after DT parsing
> > > + *
> > > + * This function will parse the "ranges" property of a PCI host bridge device
> > > + * node and setup the resource mapping based on its content. It is expected
> > > + * that the property conforms with the Power ePAPR document.
> > > + *
> > > + * Each architecture will then apply their filtering based on the limitations
> > > + * of each platform. One general restriction seems to be the number of IO space
> > > + * ranges, the PCI framework makes intensive use of struct resource management,
> > > + * and for IORESOURCE_IO types they can only be requested if they are contained
> > > + * within the global ioport_resource, so that should be limited to one IO space
> > > + * range.
> >
> > Actually we have quite a different set of restrictions around I/O space on ARM32
> > at the moment: Each host bridge can have its own 64KB range in an arbitrary
> > location on MMIO space, and the total must not exceed 2MB of I/O space.
>
> And that is why the filtering is not (yet) imposed in the generic code. But once
> you use pci_request_region, that will call request_region which will check
> against ioport_resource as parent for the requested resource. That should fail
> if is is not in the correct range, so I don't know how arm arch code manages
> multiple IO ranges.
Let's try to come up with nomenclature so we can talk about this better
The ioport_resource is in "logical I/O space", which is a Linux fiction,
it goes from 0 to IO_SPACE_LIMIT (2MB on ARM) and is mapped into "virtual
I/O space", which start at (void __iomem *)PCI_IO_VIRT_BASE.
Each PCI domain can have its own "bus I/O aperture", which is typically
between 0x1000 and 0xffff and reflects the address that is used in PCI
transactions and in BARs. The aperture here reflects the subset of the
4GB bus I/O space that is actually mapped into a CPU visible "physical
I/O aperture" using an inbound mapping of the host bridge. The physical
I/O aperture in turn gets mapped to the virtual I/O space using
pci_ioremap_io. The difference between a bus I/O address and a logical
I/O address is stored in the io_offset.
So much for basic definitions. When a device driver calls pci_request_region,
the port number it sees is the bus I/O port number adjusted using the
io_offset to turn it into a logical I/O port number, which should
always be within the host bridge window, which in turn is a subset
of the ioport_resource.
> > > +static int pci_host_bridge_of_get_ranges(struct device_node *dev,
> > > + struct list_head *resources)
> > > +{
> > > + struct resource *res;
> > > + struct of_pci_range range;
> > > + struct of_pci_range_parser parser;
> > > + int err;
> > > +
> > > + pr_info("PCI host bridge %s ranges:\n", dev->full_name);
> > > +
> > > + /* Check for ranges property */
> > > + err = of_pci_range_parser_init(&parser, dev);
> > > + if (err)
> > > + return err;
> > > +
> > > + pr_debug("Parsing ranges property...\n");
> > > + for_each_of_pci_range(&parser, &range) {
> > > + /* Read next ranges element */
> > > + pr_debug("pci_space: 0x%08x pci_addr:0x%016llx ",
> > > + range.pci_space, range.pci_addr);
> > > + pr_debug("cpu_addr:0x%016llx size:0x%016llx\n",
> > > + range.cpu_addr, range.size);
> > > +
> > > + /* If we failed translation or got a zero-sized region
> > > + * (some FW try to feed us with non sensical zero sized regions
> > > + * such as power3 which look like some kind of attempt
> > > + * at exposing the VGA memory hole) then skip this range
> > > + */
> > > + if (range.cpu_addr == OF_BAD_ADDR || range.size == 0)
> > > + continue;
> > > +
> > > + res = kzalloc(sizeof(struct resource), GFP_KERNEL);
> > > + if (!res) {
> > > + err = -ENOMEM;
> > > + goto bridge_ranges_nomem;
> > > + }
> > > +
> > > + of_pci_range_to_resource(&range, dev, res);
> > > +
> > > + pci_add_resource_offset(resources, res,
> > > + range.cpu_addr - range.pci_addr);
> > > + }
> >
> > I believe of_pci_range_to_resource() will return the MMIO aperture for the
> > I/O space window here, which is not what you are supposed to pass into
> > pci_add_resource_offset.
>
> And that is why the code in probe.c has been added to deal with that. It is
> too early to do the adjustments here as all we have is the list of resources
> and that might get culled by the architecture fixup code. Remembering the
> io_offset will happen once the pci_host_bridge gets created, and the resources
> are then adjusted.
So you want to register an incorrect I/O resource first and then
have it fixed up later, rather than registering the correct
one from the start as everyone else?
> > > diff --git a/drivers/pci/probe.c b/drivers/pci/probe.c
> > > index 6e34498..16febae 100644
> > > --- a/drivers/pci/probe.c
> > > +++ b/drivers/pci/probe.c
> > > @@ -1787,6 +1787,17 @@ struct pci_bus *pci_create_root_bus(struct device *parent, int bus,
> > > list_for_each_entry_safe(window, n, resources, list) {
> > > list_move_tail(&window->list, &bridge->windows);
> > > res = window->res;
> > > + /*
> > > + * IO resources are stored in the kernel with a CPU start
> > > + * address of zero. Adjust the data accordingly and remember
> > > + * the offset
> > > + */
> > > + if (resource_type(res) == IORESOURCE_IO) {
> > > + bridge->io_offset = res->start;
> > > + res->end -= res->start;
> > > + window->offset -= res->start;
> > > + res->start = 0;
> > > + }
> > > offset = window->offset;
> > > if (res->flags & IORESOURCE_BUS)
> >
> > Won't this break all existing host bridges?
>
> I am not sure. I believe not, due to what I've explained earlier, but you might be right.
>
> The adjustment happens before the resource is added to the host bridge windows and translates
> it from MMIO range into IO range.
AFAICT, the resource_type of the resource you register above should be
IORESOURCE_MEM, so you are not actually matching it here.
Arnd
^ permalink raw reply
* Re: [PATCH v3 1/8] clk: sunxi: Add Allwinner A20/A31 GMAC clock unit
From: Maxime Ripard @ 2014-02-03 19:31 UTC (permalink / raw)
To: Chen-Yu Tsai
Cc: Emilio Lopez, Mike Turquette,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
linux-sunxi-/JYPxA39Uh5TLH3MbocFFw,
devicetree-u79uwXL29TY76Z2rM5mHXA,
linux-kernel-u79uwXL29TY76Z2rM5mHXA
In-Reply-To: <1391398346-5094-2-git-send-email-wens-jdAy2FN1RRM@public.gmane.org>
[-- Attachment #1: Type: text/plain, Size: 6331 bytes --]
Hi,
On Mon, Feb 03, 2014 at 11:32:19AM +0800, Chen-Yu Tsai wrote:
> The Allwinner A20/A31 clock module controls the transmit clock source
> and interface type of the GMAC ethernet controller. Model this as
> a single clock for GMAC drivers to use.
>
> Signed-off-by: Chen-Yu Tsai <wens-jdAy2FN1RRM@public.gmane.org>
> ---
> Documentation/devicetree/bindings/clock/sunxi.txt | 26 +++++++
> drivers/clk/sunxi/clk-sunxi.c | 83 +++++++++++++++++++++++
> 2 files changed, 109 insertions(+)
>
> diff --git a/Documentation/devicetree/bindings/clock/sunxi.txt b/Documentation/devicetree/bindings/clock/sunxi.txt
> index 0cf679b..f43b4c0 100644
> --- a/Documentation/devicetree/bindings/clock/sunxi.txt
> +++ b/Documentation/devicetree/bindings/clock/sunxi.txt
> @@ -37,6 +37,7 @@ Required properties:
> "allwinner,sun6i-a31-apb2-gates-clk" - for the APB2 gates on A31
> "allwinner,sun4i-mod0-clk" - for the module 0 family of clocks
> "allwinner,sun7i-a20-out-clk" - for the external output clocks
> + "allwinner,sun7i-a20-gmac-clk" - for the GMAC clock module on A20/A31
>
> Required properties for all clocks:
> - reg : shall be the control register address for the clock.
> @@ -50,6 +51,9 @@ Required properties for all clocks:
> If the clock module only has one output, the name shall be the
> module name.
>
> +For "allwinner,sun7i-a20-gmac-clk", the parent clocks shall be fixed rate
> +dummy clocks at 25 MHz and 125 MHz, respectively. See example.
> +
> Clock consumers should specify the desired clocks they use with a
> "clocks" phandle cell. Consumers that are using a gated clock should
> provide an additional ID in their clock property. This ID is the
> @@ -96,3 +100,25 @@ mmc0_clk: clk@01c20088 {
> clocks = <&osc24M>, <&pll6 1>, <&pll5 1>;
> clock-output-names = "mmc0";
> };
> +
> +mii_phy_tx_clk: clk@2 {
> + #clock-cells = <0>;
> + compatible = "fixed-clock";
> + clock-frequency = <25000000>;
> + clock-output-names = "mii_phy_tx";
> +};
> +
> +gmac_int_tx_clk: clk@3 {
> + #clock-cells = <0>;
> + compatible = "fixed-clock";
> + clock-frequency = <125000000>;
> + clock-output-names = "gmac_int_tx";
> +};
> +
> +gmac_clk: clk@01c20164 {
> + #clock-cells = <0>;
> + compatible = "allwinner,sun7i-a20-gmac-clk";
> + reg = <0x01c20164 0x4>;
> + clocks = <&mii_phy_tx_clk>, <&gmac_int_tx_clk>;
You should also document in which order you expect the parents to
be. Or it will probably be easier to just use clock-names here.
> + clock-output-names = "gmac";
> +};
> diff --git a/drivers/clk/sunxi/clk-sunxi.c b/drivers/clk/sunxi/clk-sunxi.c
> index 736fb60..0b361d2 100644
> --- a/drivers/clk/sunxi/clk-sunxi.c
> +++ b/drivers/clk/sunxi/clk-sunxi.c
> @@ -379,6 +379,89 @@ static void sun7i_a20_get_out_factors(u32 *freq, u32 parent_rate,
>
>
> /**
> + * sun7i_a20_gmac_clk_setup - Setup function for A20/A31 GMAC clock module
> + *
> + * This clock looks something like this
> + * ________________________
> + * MII TX clock from PHY >-----|___________ _________|----> to GMAC core
> + * GMAC Int. RGMII TX clk >----|___________\__/__gate---|----> to PHY
> + * Ext. 125MHz RGMII TX clk >--|__divider__/ |
> + * |________________________|
> + *
> + * The external 125 MHz reference is optional, i.e. GMAC can use its
> + * internal TX clock just fine. The A31 GMAC clock module does not have
> + * the divider controls for the external reference.
> + *
> + * To keep it simple, let the GMAC use either the MII TX clock for MII mode,
> + * and its internal TX clock for GMII and RGMII modes. The GMAC driver should
> + * select the appropriate source and gate/ungate the output to the PHY.
> + *
> + * Only the GMAC should use this clock. Altering the clock so that it doesn't
> + * match the GMAC's operation parameters will result in the GMAC not being
> + * able to send traffic out. The GMAC driver should set the clock rate and
> + * enable/disable this clock to configure the required state. The clock
> + * driver then responds by auto-reparenting the clock.
> + */
> +
> +#define SUN7I_A20_GMAC_GPIT 2
> +#define SUN7I_A20_GMAC_MASK 0x3
> +#define SUN7I_A20_GMAC_MAX_PARENTS 2
> +
> +static void __init sun7i_a20_gmac_clk_setup(struct device_node *node)
> +{
> + struct clk *clk;
> + struct clk_mux *mux;
> + struct clk_gate *gate;
> + const char *clk_name = node->name;
> + const char *parents[SUN7I_A20_GMAC_MAX_PARENTS];
> + void *reg;
> + int i = 0;
> +
> + /* allocate mux and gate clock structs */
> + mux = kzalloc(sizeof(struct clk_mux), GFP_KERNEL);
> + if (!mux)
> + return;
Newline.
> + gate = kzalloc(sizeof(struct clk_gate), GFP_KERNEL);
> + if (!gate) {
> + kfree(mux);
> + return;
> + }
> +
> + reg = of_iomap(node, 0);
You should check for the return code here.
> + of_property_read_string(node, "clock-output-names", &clk_name);
And here too, since you made the clock-output-names property mandatory
> + while (i < SUN7I_A20_GMAC_MAX_PARENTS &&
> + (parents[i] = of_clk_get_parent_name(node, i)) != NULL)
You should check for an error here too, but if you switch to using
clock-names, that will probably be refactored anyway.
> + i++;
> +
> + /* set up gate and fixed rate properties */
> + gate->reg = reg;
> + gate->bit_idx = SUN7I_A20_GMAC_GPIT;
> + gate->lock = &clk_lock;
> + mux->reg = reg;
> + mux->mask = SUN7I_A20_GMAC_MASK;
> + mux->flags = CLK_MUX_INDEX_BIT;
> + mux->lock = &clk_lock;
> +
> + clk = clk_register_composite(NULL, clk_name,
> + parents, i,
> + &mux->hw, &clk_mux_ops,
> + NULL, NULL,
> + &gate->hw, &clk_gate_ops,
> + 0);
> +
> + if (!IS_ERR(clk)) {
> + of_clk_add_provider(node, of_clk_src_simple_get, clk);
> + clk_register_clkdev(clk, clk_name, NULL);
> + }
> +}
> +CLK_OF_DECLARE(sun7i_a20_gmac, "allwinner,sun7i-a20-gmac-clk",
> + sun7i_a20_gmac_clk_setup);
> +
> +
> +
> +/**
> * sunxi_factors_clk_setup() - Setup function for factor clocks
> */
>
> --
> 1.9.rc1
>
It looks fine otherwise.
Thanks!
Maxime
--
Maxime Ripard, Free Electrons
Embedded Linux, Kernel and Android engineering
http://free-electrons.com
[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 836 bytes --]
^ permalink raw reply
* Re: [RFC] dtc: add ability to make nodes conditional on them being referenced
From: Maxime Ripard @ 2014-02-03 19:22 UTC (permalink / raw)
To: Heiko Stübner
Cc: Grant Likely, Rob Herring, devicetree-u79uwXL29TY76Z2rM5mHXA,
linux-kernel-u79uwXL29TY76Z2rM5mHXA, Shawn Guo,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r
In-Reply-To: <1578575.rVWgTPdq1W@phil>
[-- Attachment #1: Type: text/plain, Size: 2572 bytes --]
Hi,
On Thu, Jan 30, 2014 at 01:25:56PM +0100, Heiko Stübner wrote:
> From: Heiko Stuebner <heiko.stuebner-HCpLIkUQxWGakBO8gow8eQ@public.gmane.org>
>
> On i.MX, which carries a lot of pin-groups of which most are unused on
> individual boards, they noticed that this plehora of nodes also results
> in the runtime-lookup-performance also degrading [0].
>
> A i.MX-specific solution defining the pingroups in the board files but
> using macros to reference the pingroup-data was not well received
>
> This patch is trying to solve this issue in a more general way, by
> adding the ability to mark nodes as needing to be referenced somewhere
> in the tree.
>
> To mark a node a needing to be referenced it must be prefixed with
> /delete-unreferenced/. This makes dtc check the nodes reference-status
> when creating the flattened tree, dropping it if unreferenced.
>
> For example, the i.MX6SL pingroup
>
> /delete-uneferenced/ pinctrl_ecspi1_1: ecspi1grp-1 {
> fsl,pins = <
> MX6SL_PAD_ECSPI1_MISO__ECSPI1_MISO 0x100b1
> MX6SL_PAD_ECSPI1_MOSI__ECSPI1_MOSI 0x100b1
> MX6SL_PAD_ECSPI1_SCLK__ECSPI1_SCLK 0x100b1
> >;
> };
>
> would only be included in the dtb if it got referenced somewhere
> as pingroup via
>
> node {
> pinctrl-0 <&pinctrl_ecscpi1_1>;
> };
>
> [0] http://thread.gmane.org/gmane.linux.ports.arm.kernel/275912/
>
> Signed-off-by: Heiko Stuebner <heiko.stuebner-HCpLIkUQxWGakBO8gow8eQ@public.gmane.org>
> ---
> This is just the idea I had in [1] explored a bit more. I'm definitely
> not sure if this is a valid approach to the problem.
> Also this is my first venture into dtc as well as flex and bison :-) .
>
> [1] http://www.spinics.net/lists/arm-kernel/msg303731.html
This is a nice feature to have :)
However, I wonder wether it's the right way of implementing it. I'd
have another use case for this, which would be to embed a DT in a
first-stage bootloader. We have around 7kB available currently for the
DT, and this is actually less than any of our (very small already)
DTBs. So having this of feature makes complete sense to us
too. However, we also have some other tools that require most of the
nodes to be in the DTB.
So I guess turning wether we should delete a node if unreferenced into
a dtc option would make sense, since every DT user will be able to
choose, without having to duplicate the DT and make conflicting
changes.
Maxime
--
Maxime Ripard, Free Electrons
Embedded Linux, Kernel and Android engineering
http://free-electrons.com
[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 836 bytes --]
^ permalink raw reply
* Re: [PATCH] arm64: Add architecture support for PCI
From: kodiak furr @ 2014-02-03 19:21 UTC (permalink / raw)
To: Liviu Dudau
Cc: devicetree@vger.kernel.org, linaro-kernel, Catalin Marinas, LKML,
linux-pci, Bjorn Helgaas, LAKML
In-Reply-To: <20140203191837.GC4889@e106497-lin.cambridge.arm.com>
[-- Attachment #1.1: Type: text/plain, Size: 3753 bytes --]
kodiak furr liked your message with Boxer. On February 3, 2014 at 1:18:38 PM CST, Liviu Dudau wrote:On Mon, Feb 03, 2014 at 06:58:56PM +0000, Arnd Bergmann wrote:> On Monday 03 February 2014 18:43:48 Liviu Dudau wrote:> > diff --git a/arch/arm64/include/asm/io.h b/arch/arm64/include/asm/io.h> > index 4cc813e..ce5bad2 100644> > --- a/arch/arm64/include/asm/io.h> > +++ b/arch/arm64/include/asm/io.h> > @@ -120,9 +120,13 @@ static inline u64 __raw_readq(const volatile void __iomem *addr)> > /*> > * I/O port access primitives.> > */> > +#define arch_has_dev_port() (0)> > Why not?Maybe I got it the wrong way around, but the comment in include/linux/io.h says:/* * Some systems do not have legacy ISA devices. * /dev/port is not a valid interface on these systems. * So for those archs, should define the following symbol. */So ... defining it should mean no legacy ISA devices, right?> > > #define IO_SPACE_LIMIT 0xffff> > You probably want to increase this a bit, to allow multiple host bridges> to have their own I/O space.OK, but to what size?> > > #define PCI_IOBASE ((void __iomem *)(MODULES_VADDR - SZ_2M))> > And modify this location: There is no particular reason to have the I/O space> mapped exactly 2MB below the loadable modules, as virtual address space is> essentially free.Will talk with Catalin about where to place this.> > > +#define ioport_map(port, nr) (PCI_IOBASE + ((port) & IO_SPACE_LIMIT))> > +#define ioport_unmap(addr)> > inline functions?Will do, thanks!> > > static inline u8 inb(unsigned long addr)> > {> > return readb(addr + PCI_IOBASE);> > diff --git a/arch/arm64/include/asm/pci.h b/arch/arm64/include/asm/pci.h> > new file mode 100644> > index 0000000..dd084a3> > --- /dev/null> > +++ b/arch/arm64/include/asm/pci.h> > @@ -0,0 +1,35 @@> > +#ifndef __ASM_PCI_H> > +#define __ASM_PCI_H> > +#ifdef __KERNEL__> > +> > +#include > > +#include > > +#include > > +> > +#include > > +#include > > +#include > > +> > +#define PCIBIOS_MIN_IO 0> > +#define PCIBIOS_MIN_MEM 0> > PCIBIOS_MIN_IO is normally set to 0x1000, to stay out of the ISA range.:) No ISA support! (Die ISA, die!!) > > > diff --git a/arch/arm64/kernel/pci.c b/arch/arm64/kernel/pci.c> > new file mode 100644> > index 0000000..7b652cf> > --- /dev/null> > +++ b/arch/arm64/kernel/pci.c> > @@ -0,0 +1,112 @@> > None of this looks really arm64 specific, nor should it be. I think> we should try a little harder to move this as a default implementation> into common code, even if we start out by having all architectures> override it.Agree. This is the RFC version. I didn't dare to post a patch with fixesfor all architectures. :)> > > +int pci_ioremap_io(unsigned int offset, phys_addr_t phys_addr)> > +{> > + BUG_ON(offset + SZ_64K - 1 > IO_SPACE_LIMIT);> > +> > + return ioremap_page_range((unsigned long)PCI_IOBASE + offset,> > + (unsigned long)PCI_IOBASE + offset + SZ_64K,> > + phys_addr,> > + __pgprot(PROT_DEVICE_nGnRE));> > +}> > Not sure if we want to treat this one as architecture specific though.> It certainly won't be portable to x86, but it could be shared with> a couple of others. We may also want to redesign the interface.> I've been thinking we could make this function allocate space in the> Linux virtual I/O space aperture, and pass two resources into it> (physical I/O aperture and bus I/O range), and get the actual> io_offset as the return value, or a negative error number.Not sure I completely follow your idea.> > That way, you could have an arbitrary number of host bridges in the> system and each one gets a share of the virtual aperture until> it's full.One still needs to fix the pci_request_region use that checks againstioport_resource. But it is an interesting idea.> > Arnd> > Thanks for reviewing this patch!Liviu--
[-- Attachment #1.2: Type: text/html, Size: 5110 bytes --]
[-- Attachment #2: Type: text/plain, Size: 161 bytes --]
_______________________________________________
linaro-kernel mailing list
linaro-kernel@lists.linaro.org
http://lists.linaro.org/mailman/listinfo/linaro-kernel
^ permalink raw reply
* Re: [PATCH] arm64: Add architecture support for PCI
From: Liviu Dudau @ 2014-02-03 19:18 UTC (permalink / raw)
To: Arnd Bergmann
Cc: linux-pci, Bjorn Helgaas, Catalin Marinas, Will Deacon, LKML,
devicetree@vger.kernel.org, LAKML, linaro-kernel
In-Reply-To: <21596846.kVTqp7roW4@wuerfel>
On Mon, Feb 03, 2014 at 06:58:56PM +0000, Arnd Bergmann wrote:
> On Monday 03 February 2014 18:43:48 Liviu Dudau wrote:
> > diff --git a/arch/arm64/include/asm/io.h b/arch/arm64/include/asm/io.h
> > index 4cc813e..ce5bad2 100644
> > --- a/arch/arm64/include/asm/io.h
> > +++ b/arch/arm64/include/asm/io.h
> > @@ -120,9 +120,13 @@ static inline u64 __raw_readq(const volatile void __iomem *addr)
> > /*
> > * I/O port access primitives.
> > */
> > +#define arch_has_dev_port() (0)
>
> Why not?
Maybe I got it the wrong way around, but the comment in include/linux/io.h says:
/*
* Some systems do not have legacy ISA devices.
* /dev/port is not a valid interface on these systems.
* So for those archs, <asm/io.h> should define the following symbol.
*/
So ... defining it should mean no legacy ISA devices, right?
>
> > #define IO_SPACE_LIMIT 0xffff
>
> You probably want to increase this a bit, to allow multiple host bridges
> to have their own I/O space.
OK, but to what size?
>
> > #define PCI_IOBASE ((void __iomem *)(MODULES_VADDR - SZ_2M))
>
> And modify this location: There is no particular reason to have the I/O space
> mapped exactly 2MB below the loadable modules, as virtual address space is
> essentially free.
Will talk with Catalin about where to place this.
>
> > +#define ioport_map(port, nr) (PCI_IOBASE + ((port) & IO_SPACE_LIMIT))
> > +#define ioport_unmap(addr)
>
> inline functions?
Will do, thanks!
>
> > static inline u8 inb(unsigned long addr)
> > {
> > return readb(addr + PCI_IOBASE);
> > diff --git a/arch/arm64/include/asm/pci.h b/arch/arm64/include/asm/pci.h
> > new file mode 100644
> > index 0000000..dd084a3
> > --- /dev/null
> > +++ b/arch/arm64/include/asm/pci.h
> > @@ -0,0 +1,35 @@
> > +#ifndef __ASM_PCI_H
> > +#define __ASM_PCI_H
> > +#ifdef __KERNEL__
> > +
> > +#include <linux/types.h>
> > +#include <linux/slab.h>
> > +#include <linux/dma-mapping.h>
> > +
> > +#include <asm/io.h>
> > +#include <asm-generic/pci-bridge.h>
> > +#include <asm-generic/pci-dma-compat.h>
> > +
> > +#define PCIBIOS_MIN_IO 0
> > +#define PCIBIOS_MIN_MEM 0
>
> PCIBIOS_MIN_IO is normally set to 0x1000, to stay out of the ISA range.
:) No ISA support! (Die ISA, die!!)
>
> > diff --git a/arch/arm64/kernel/pci.c b/arch/arm64/kernel/pci.c
> > new file mode 100644
> > index 0000000..7b652cf
> > --- /dev/null
> > +++ b/arch/arm64/kernel/pci.c
> > @@ -0,0 +1,112 @@
>
> None of this looks really arm64 specific, nor should it be. I think
> we should try a little harder to move this as a default implementation
> into common code, even if we start out by having all architectures
> override it.
Agree. This is the RFC version. I didn't dare to post a patch with fixes
for all architectures. :)
>
> > +int pci_ioremap_io(unsigned int offset, phys_addr_t phys_addr)
> > +{
> > + BUG_ON(offset + SZ_64K - 1 > IO_SPACE_LIMIT);
> > +
> > + return ioremap_page_range((unsigned long)PCI_IOBASE + offset,
> > + (unsigned long)PCI_IOBASE + offset + SZ_64K,
> > + phys_addr,
> > + __pgprot(PROT_DEVICE_nGnRE));
> > +}
>
> Not sure if we want to treat this one as architecture specific though.
> It certainly won't be portable to x86, but it could be shared with
> a couple of others. We may also want to redesign the interface.
> I've been thinking we could make this function allocate space in the
> Linux virtual I/O space aperture, and pass two resources into it
> (physical I/O aperture and bus I/O range), and get the actual
> io_offset as the return value, or a negative error number.
Not sure I completely follow your idea.
>
> That way, you could have an arbitrary number of host bridges in the
> system and each one gets a share of the virtual aperture until
> it's full.
One still needs to fix the pci_request_region use that checks against
ioport_resource. But it is an interesting idea.
>
> Arnd
>
>
Thanks for reviewing this patch!
Liviu
--
====================
| I would like to |
| fix the world, |
| but they're not |
| giving me the |
\ source code! /
---------------
¯\_(ツ)_/¯
^ 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