ARM: tegra: Move SoC drivers to drivers/soc/tegra
RFC 1/4 ARM: tegra: Move SoC drivers to drivers/soc/tegra
From: Thierry Reding <[email protected]>
These drivers are closely coupled and need to be moved as a whole. One reason for moving them out of arch/arm/mach-tegra is to allow them to be shared with 64-bit ARM.
---
arch/arm/mach-tegra/Makefile | 32 --------
arch/arm/mach-tegra/common.h | 4 -
arch/arm/mach-tegra/io.c | 27 +++++-
arch/arm/mach-tegra/pmc.h | 62 --------------
arch/arm/mach-tegra/tegra.c | 9 --
drivers/soc/Makefile | 1 +
drivers/soc/tegra/Makefile | 34 ++++++++
.../soc/tegra}/cpuidle-tegra114.c | 0
.../soc/tegra}/cpuidle-tegra20.c | 6 +-
.../soc/tegra}/cpuidle-tegra30.c | 0
.../arm/mach-tegra => drivers/soc/tegra}/cpuidle.c | 0
.../arm/mach-tegra => drivers/soc/tegra}/cpuidle.h | 3 -
.../mach-tegra => drivers/soc/tegra}/flowctrl.c | 0
.../mach-tegra => drivers/soc/tegra}/flowctrl.h | 2 -
.../arm/mach-tegra => drivers/soc/tegra}/headsmp.S | 0
.../arm/mach-tegra => drivers/soc/tegra}/hotplug.c | 0
{arch/arm/mach-tegra => drivers/soc/tegra}/iomap.h | 0
.../arm/mach-tegra => drivers/soc/tegra}/irammap.h | 0
{arch/arm/mach-tegra => drivers/soc/tegra}/irq.c | 1 -
{arch/arm/mach-tegra => drivers/soc/tegra}/irq.h | 6 --
.../arm/mach-tegra => drivers/soc/tegra}/platsmp.c | 5 --
.../mach-tegra => drivers/soc/tegra}/pm-tegra20.c | 0
.../mach-tegra => drivers/soc/tegra}/pm-tegra30.c | 0
{arch/arm/mach-tegra => drivers/soc/tegra}/pm.c | 0
{arch/arm/mach-tegra => drivers/soc/tegra}/pm.h | 4 +-
{arch/arm/mach-tegra => drivers/soc/tegra}/pmc.c | 0
drivers/soc/tegra/pmc.h | 35 ++++++++
.../mach-tegra => drivers/soc/tegra}/powergate.c | 0
.../soc/tegra}/reset-handler.S | 0
{arch/arm/mach-tegra => drivers/soc/tegra}/reset.c | 0
{arch/arm/mach-tegra => drivers/soc/tegra}/reset.h | 2 -
.../soc/tegra}/sleep-tegra20.S | 0
.../soc/tegra}/sleep-tegra30.S | 0
{arch/arm/mach-tegra => drivers/soc/tegra}/sleep.S | 0
{arch/arm/mach-tegra => drivers/soc/tegra}/sleep.h | 2 -
include/linux/tegra-soc.h | 95 ++++++++++++++++++++++
36 files changed, 195 insertions(+), 135 deletions(-)
delete mode 100644 arch/arm/mach-tegra/common.h
delete mode 100644 arch/arm/mach-tegra/pmc.h
create mode 100644 drivers/soc/tegra/Makefile
rename {arch/arm/mach-tegra => drivers/soc/tegra}/cpuidle-tegra114.c (100%)
rename {arch/arm/mach-tegra => drivers/soc/tegra}/cpuidle-tegra20.c (100%)
rename {arch/arm/mach-tegra => drivers/soc/tegra}/cpuidle-tegra30.c (100%)
rename {arch/arm/mach-tegra => drivers/soc/tegra}/cpuidle.c (100%)
rename {arch/arm/mach-tegra => drivers/soc/tegra}/cpuidle.h (91%)
rename {arch/arm/mach-tegra => drivers/soc/tegra}/flowctrl.c (100%)
rename {arch/arm/mach-tegra => drivers/soc/tegra}/flowctrl.h (98%)
rename {arch/arm/mach-tegra => drivers/soc/tegra}/headsmp.S (100%)
rename {arch/arm/mach-tegra => drivers/soc/tegra}/hotplug.c (100%)
rename {arch/arm/mach-tegra => drivers/soc/tegra}/iomap.h (100%)
rename {arch/arm/mach-tegra => drivers/soc/tegra}/irammap.h (100%)
rename {arch/arm/mach-tegra => drivers/soc/tegra}/irq.c (99%)
rename {arch/arm/mach-tegra => drivers/soc/tegra}/irq.h (83%)
rename {arch/arm/mach-tegra => drivers/soc/tegra}/platsmp.c (98%)
rename {arch/arm/mach-tegra => drivers/soc/tegra}/pm-tegra20.c (100%)
rename {arch/arm/mach-tegra => drivers/soc/tegra}/pm-tegra30.c (100%)
rename {arch/arm/mach-tegra => drivers/soc/tegra}/pm.c (100%)
rename {arch/arm/mach-tegra => drivers/soc/tegra}/pm.h (94%)
rename {arch/arm/mach-tegra => drivers/soc/tegra}/pmc.c (100%)
create mode 100644 drivers/soc/tegra/pmc.h
rename {arch/arm/mach-tegra => drivers/soc/tegra}/powergate.c (100%)
rename {arch/arm/mach-tegra => drivers/soc/tegra}/reset-handler.S (100%)
rename {arch/arm/mach-tegra => drivers/soc/tegra}/reset.c (100%)
rename {arch/arm/mach-tegra => drivers/soc/tegra}/reset.h (97%)
rename {arch/arm/mach-tegra => drivers/soc/tegra}/sleep-tegra20.S (100%)
rename {arch/arm/mach-tegra => drivers/soc/tegra}/sleep-tegra30.S (100%)
rename {arch/arm/mach-tegra => drivers/soc/tegra}/sleep.S (100%)
rename {arch/arm/mach-tegra => drivers/soc/tegra}/sleep.h (98%)arch/arm/mach-tegra/Makefile +0 -32
@@ -1,38 +1,6 @@ asflags-y += -march=armv7-a obj-y += io.o -obj-y += irq.o -obj-y += pmc.o -obj-y += flowctrl.o -obj-y += powergate.o -obj-y += pm.o -obj-y += reset.o -obj-y += reset-handler.o -obj-y += sleep.o obj-y += tegra.o -obj-$(CONFIG_CPU_IDLE) += cpuidle.o -obj-$(CONFIG_ARCH_TEGRA_2x_SOC) += sleep-tegra20.o -obj-$(CONFIG_ARCH_TEGRA_2x_SOC) += pm-tegra20.o -ifeq ($(CONFIG_CPU_IDLE),y) -obj-$(CONFIG_ARCH_TEGRA_2x_SOC) += cpuidle-tegra20.o -endif -obj-$(CONFIG_ARCH_TEGRA_3x_SOC) += sleep-tegra30.o -obj-$(CONFIG_ARCH_TEGRA_3x_SOC) += pm-tegra30.o -ifeq ($(CONFIG_CPU_IDLE),y) -obj-$(CONFIG_ARCH_TEGRA_3x_SOC) += cpuidle-tegra30.o -endif -obj-$(CONFIG_SMP) += platsmp.o headsmp.o -obj-$(CONFIG_HOTPLUG_CPU) += hotplug.o - -obj-$(CONFIG_ARCH_TEGRA_114_SOC) += sleep-tegra30.o -obj-$(CONFIG_ARCH_TEGRA_114_SOC) += pm-tegra30.o -ifeq ($(CONFIG_CPU_IDLE),y) -obj-$(CONFIG_ARCH_TEGRA_114_SOC) += cpuidle-tegra114.o -endif -obj-$(CONFIG_ARCH_TEGRA_124_SOC) += sleep-tegra30.o -obj-$(CONFIG_ARCH_TEGRA_124_SOC) += pm-tegra30.o -ifeq ($(CONFIG_CPU_IDLE),y) -obj-$(CONFIG_ARCH_TEGRA_124_SOC) += cpuidle-tegra114.o -endif obj-$(CONFIG_ARCH_TEGRA_2x_SOC) += board-paz00.o
arch/arm/mach-tegra/common.h deleted +0 -4
@@ -1,4 +0,0 @@ -extern struct smp_operations tegra_smp_ops; - -extern int tegra_cpu_kill (unsigned int cpu); -extern void tegra_cpu_die (unsigned int cpu);
arch/arm/mach-tegra/io.c +26 -1
@@ -28,7 +28,32 @@#include <asm/mach/map.h> #include "board.h" -#include "iomap.h" + +/* +* On TEGRA, many peripherals are very closely packed in +* two 256MB io windows (that actually only use about 64KB +* at the start of each). +* +* We will just map the first MMU section of each window (to minimize +* pt entries needed) and provide a macro to transform physical +* io addresses to an appropriate void __iomem *. +*/ + +#define IO_IRAM_PHYS 0x40000000 +#define IO_IRAM_VIRT IOMEM(0xFE400000) +#define IO_IRAM_SIZE SZ_256K + +#define IO_CPU_PHYS 0x50040000 +#define IO_CPU_VIRT IOMEM(0xFE440000) +#define IO_CPU_SIZE SZ_16K + +#define IO_PPSB_PHYS 0x60000000 +#define IO_PPSB_VIRT IOMEM(0xFE200000) +#define IO_PPSB_SIZE SECTION_SIZE + +#define IO_APB_PHYS 0x70000000 +#define IO_APB_VIRT IOMEM(0xFE000000) +#define IO_APB_SIZE SECTION_SIZEstatic struct map_desc tegra_io_desc[]__initdata = { {
arch/arm/mach-tegra/pmc.h deleted +0 -62
62 lines not on this page · raw message
arch/arm/mach-tegra/tegra.c +0 -9
@@ -44,15 +44,6 @@#include <asm/trusted_foundations.h> #include "board.h" -#include "common.h" -#include "cpuidle.h" -#include "flowctrl.h" -#include "iomap.h" -#include "irq.h" -#include "pmc.h" -#include "pm.h" -#include "reset.h" -#include "sleep.h" /* * Storage for debug-macro.S's state.
drivers/soc/Makefile +1 -0
@@ -3,3 +3,4 @@ # obj-$(CONFIG_ARCH_QCOM) += qcom/ +obj-$(CONFIG_ARCH_TEGRA) += tegra/
drivers/soc/tegra/Makefile new file +34 -0
@@ -0,0 +1,34 @@ +asflags-y += -march=armv7-a + +obj-y += flowctrl.o +obj-y += irq.o +obj-y += pm.o +obj-y += pmc.o +obj-y += powergate.o +obj-y += reset.o +obj-y += reset-handler.o +obj-y += sleep.o + + +obj-$(CONFIG_HOTPLUG_CPU) += hotplug.o +obj-$(CONFIG_SMP) += platsmp.o headsmp.o + +obj-$(CONFIG_ARCH_TEGRA_2x_SOC) += pm-tegra20.o +obj-$(CONFIG_ARCH_TEGRA_2x_SOC) += sleep-tegra20.o + +obj-$(CONFIG_ARCH_TEGRA_3x_SOC) += pm-tegra30.o +obj-$(CONFIG_ARCH_TEGRA_3x_SOC) += sleep-tegra30.o + +obj-$(CONFIG_ARCH_TEGRA_114_SOC) += pm-tegra30.o +obj-$(CONFIG_ARCH_TEGRA_114_SOC) += sleep-tegra30.o + +obj-$(CONFIG_ARCH_TEGRA_124_SOC) += pm-tegra30.o +obj-$(CONFIG_ARCH_TEGRA_124_SOC) += sleep-tegra30.o + +ifeq ($(CONFIG_CPU_IDLE),y) +obj-y += cpuidle.o +obj-$(CONFIG_ARCH_TEGRA_2x_SOC) += cpuidle-tegra20.o +obj-$(CONFIG_ARCH_TEGRA_3x_SOC) += cpuidle-tegra30.o +obj-$(CONFIG_ARCH_TEGRA_114_SOC) += cpuidle-tegra114.o +obj-$(CONFIG_ARCH_TEGRA_124_SOC) += cpuidle-tegra114.o +endif
drivers/soc/tegra/cpuidle-tegra114.c renamed from arch/arm/mach-tegra/cpuidle-tegra114.c +0 -0
drivers/soc/tegra/cpuidle-tegra20.c renamed from arch/arm/mach-tegra/cpuidle-tegra20.c +3 -3
@@ -31,11 +31,11 @@#include <asm/suspend.h> #include <asm/smp_plat.h> -#include "pm.h" -#include "sleep.h" +#include "flowctrl.h" #include "iomap.h" #include "irq.h" -#include "flowctrl.h" +#include "pm.h" +#include "sleep.h" #ifdef CONFIG_PM_SLEEP static bool abort_flag;
drivers/soc/tegra/cpuidle-tegra30.c renamed from arch/arm/mach-tegra/cpuidle-tegra30.c +0 -0
drivers/soc/tegra/cpuidle.c renamed from arch/arm/mach-tegra/cpuidle.c +0 -0
drivers/soc/tegra/cpuidle.h renamed from arch/arm/mach-tegra/cpuidle.h +0 -3
@@ -22,9 +22,6 @@ int tegra20_cpuidle_init(void);void tegra20_cpuidle_pcie_irqs_in_use (void );int tegra30_cpuidle_init (void );int tegra114_cpuidle_init (void ); -void tegra_cpuidle_init (void ); -#else -static inline void tegra_cpuidle_init (void ) {}#endif #endif
drivers/soc/tegra/flowctrl.c renamed from arch/arm/mach-tegra/flowctrl.c +0 -0
drivers/soc/tegra/flowctrl.h renamed from arch/arm/mach-tegra/flowctrl.h +0 -2
@@ -59,8 +59,6 @@ void flowctrl_write_cpu_halt(unsigned int cpuid, u32 value);void flowctrl_cpu_suspend_enter (unsigned int cpuid);void flowctrl_cpu_suspend_exit (unsigned int cpuid); - -void tegra_flowctrl_init (void );#endif #endif
drivers/soc/tegra/headsmp.S renamed from arch/arm/mach-tegra/headsmp.S +0 -0
drivers/soc/tegra/hotplug.c renamed from arch/arm/mach-tegra/hotplug.c +0 -0
drivers/soc/tegra/iomap.h renamed from arch/arm/mach-tegra/iomap.h +0 -0
drivers/soc/tegra/irammap.h renamed from arch/arm/mach-tegra/irammap.h +0 -0
drivers/soc/tegra/irq.c renamed from arch/arm/mach-tegra/irq.c +0 -1
@@ -27,7 +27,6 @@#include <linux/irqchip/arm-gic.h> #include <linux/syscore_ops.h> -#include "board.h" #include "iomap.h" #define ICTLR_CPU_IEP_VFIQ 0x08
drivers/soc/tegra/irq.h renamed from arch/arm/mach-tegra/irq.h +0 -6
@@ -19,10 +19,4 @@bool tegra_pending_sgi (void ); -#ifdef CONFIG_PM_SLEEP -int tegra_legacy_irq_syscore_init (void ); -#else -static inline int tegra_legacy_irq_syscore_init (void ) {return 0 ; } -#endif -#endif
drivers/soc/tegra/platsmp.c renamed from arch/arm/mach-tegra/platsmp.c +0 -5
@@ -27,10 +27,6 @@#include <asm/smp_plat.h> #include "flowctrl.h" -#include "reset.h" -#include "pmc.h" - -#include "common.h" #include "iomap.h" static cpumask_t tegra_cpu_init_mask;
@@ -40,7 +36,6 @@ static void tegra_secondary_init(unsigned int cpu)cpumask_set_cpu (cpu, &tegra_cpu_init_mask); } -static int tegra20_boot_secondary (unsigned int cpu,struct task_struct *idle) { cpu =cpu_logical_map (cpu);
drivers/soc/tegra/pm-tegra20.c renamed from arch/arm/mach-tegra/pm-tegra20.c +0 -0
drivers/soc/tegra/pm-tegra30.c renamed from arch/arm/mach-tegra/pm-tegra30.c +0 -0
drivers/soc/tegra/pm.c renamed from arch/arm/mach-tegra/pm.c +0 -0
drivers/soc/tegra/pm.h renamed from arch/arm/mach-tegra/pm.h +1 -3
@@ -21,7 +21,7 @@ #ifndef _MACH_TEGRA_PM_H_ #define _MACH_TEGRA_PM_H_ -#include "pmc.h" +#include <linux/tegra-soc.h> struct tegra_lp1_iram { void *start_addr;
@@ -44,14 +44,12 @@ extern void (*tegra_tear_down_cpu)(void);#ifdef CONFIG_PM_SLEEP enum tegra_suspend_mode tegra_pm_validate_suspend_mode (enum tegra_suspend_mode mode); -void tegra_init_suspend (void );#else static inline enum tegra_suspend_mode tegra_pm_validate_suspend_mode (enum tegra_suspend_mode mode) {return TEGRA_SUSPEND_NONE ; } -static inline void tegra_init_suspend (void ) {}#endif #endif /* _MACH_TEGRA_PM_H_ */
drivers/soc/tegra/pmc.c renamed from arch/arm/mach-tegra/pmc.c +0 -0
drivers/soc/tegra/pmc.h new file +35 -0
@@ -0,0 +1,35 @@ +/* +* Copyright (C) 2012 NVIDIA CORPORATION. All rights reserved. +* +* This program is free software; you can redistribute it and/or modify it +* under the terms and conditions of the GNU General Public License, +* version 2, as published by the Free Software Foundation. +* +* This program is distributed in the hope it will be useful, but WITHOUT +* ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or +* FITNESS FOR A PARTICULAR PURPOSE. See the GNU General Public License for +* more details. +* +* You should have received a copy of the GNU General Public License +* along with this program. If not, see <http://www.gnu.org/licenses/>. +* +*/ + +#ifndef __MACH_TEGRA_PMC_H +#define __MACH_TEGRA_PMC_H + +#include <linux/io.h> + +extern void __iomem *tegra_pmc_base; + +static inline u32 tegra_pmc_readl (u32 reg) +{ +return readl (tegra_pmc_base + reg); +} + +static inline void tegra_pmc_writel (u32 val,u32 reg) +{ +writel (val, tegra_pmc_base + reg); +} + +#endif
drivers/soc/tegra/powergate.c renamed from arch/arm/mach-tegra/powergate.c +0 -0
drivers/soc/tegra/reset-handler.S renamed from arch/arm/mach-tegra/reset-handler.S +0 -0
drivers/soc/tegra/reset.c renamed from arch/arm/mach-tegra/reset.c +0 -0
drivers/soc/tegra/reset.h renamed from arch/arm/mach-tegra/reset.h +0 -2
@@ -57,7 +57,5 @@ void tegra_secondary_startup(void); (__tegra_cpu_reset_handler_end - \ __tegra_cpu_reset_handler_start) -void __init tegra_cpu_reset_handler_init (void ); -#endif #endif
drivers/soc/tegra/sleep-tegra20.S renamed from arch/arm/mach-tegra/sleep-tegra20.S +0 -0
drivers/soc/tegra/sleep-tegra30.S renamed from arch/arm/mach-tegra/sleep-tegra30.S +0 -0
drivers/soc/tegra/sleep.S renamed from arch/arm/mach-tegra/sleep.S +0 -0
drivers/soc/tegra/sleep.h renamed from arch/arm/mach-tegra/sleep.h +0 -2
@@ -121,7 +121,6 @@ .endm#else -void tegra_pen_lock (void );void tegra_pen_unlock (void );void tegra_resume (void );int tegra_sleep_cpu_finish (unsigned long );
@@ -130,7 +129,6 @@ void tegra_disable_clean_inv_dcache(u32 flag);#ifdef CONFIG_HOTPLUG_CPU void tegra20_hotplug_shutdown (void );void tegra30_hotplug_shutdown (void ); -void tegra_hotplug_init (void );#else static inline void tegra_hotplug_init (void ) {}#endif
include/linux/tegra-soc.h +95 -0
107 lines not on this page · raw message
Signature · 1 line
2.0.0
RFC 2/4 ARM: tegra: Add legacy interrupt controller nodes
From: Thierry Reding <[email protected]>
Add device tree nodes for the legacy interrupt controller so that the driver can get the register ranges from device tree rather than hard- coding them.
--- arch/arm/boot/dts/tegra114.dtsi | 9 +++++++++ arch/arm/boot/dts/tegra124.dtsi | 9 +++++++++ arch/arm/boot/dts/tegra20.dtsi | 9 +++++++++ arch/arm/boot/dts/tegra30.dtsi | 9 +++++++++ 4 files changed, 36 insertions(+)
arch/arm/boot/dts/tegra114.dtsi +9 -0
@@ -141,6 +141,15 @@ (GIC_CPU_MASK_SIMPLE(4) | IRQ_TYPE_LEVEL_HIGH)>; }; + interrupt-controller at 60004000 { + compatible = "nvidia,tegra20-ictlr"; + reg = <0x60004000 0x40 /* primary controller */ + 0x60004100 0x40 /* secondary controller */ + 0x60004200 0x40 /* tertiary controller */ + 0x60004300 0x40 /* quaternary controller */ + 0x60004400 0x40>; /* quinary controller */ + }; + timer at 60005000 { compatible = "nvidia,tegra114-timer", "nvidia,tegra20-timer"; reg = <0x60005000 0x400>;
arch/arm/boot/dts/tegra124.dtsi +9 -0
@@ -190,6 +190,15 @@ status = "disabled"; }; + interrupt-controller at 0,60004000 { + compatible = "nvidia,tegra20-ictlr"; + reg = <0x0 0x60004000 0x0 0x40 /* primary controller */ + 0x0 0x60004100 0x0 0x40 /* secondary controller */ + 0x0 0x60004200 0x0 0x40 /* tertiary controller */ + 0x0 0x60004300 0x0 0x40 /* quaternary controller */ + 0x0 0x60004400 0x0 0x40>; /* quinary controller */ + }; + timer at 0,60005000 { compatible = "nvidia,tegra124-timer", "nvidia,tegra20-timer"; reg = <0x0 0x60005000 0x0 0x400>;
arch/arm/boot/dts/tegra20.dtsi +9 -0
@@ -183,6 +183,15 @@ cache-level = <2>; }; + interrupt-controller at 60004000 { + compatible = "nvidia,tegra20-ictlr"; + reg = <0x60004000 0x40 /* primary controller */ + 0x60004100 0x40 /* secondary controller */ + 0x60004200 0x40 /* tertiary controller */ + 0x60004300 0x40 /* quaternary controller */ + 0x60004400 0x40>; /* quinary controller */ + }; + timer at 60005000 { compatible = "nvidia,tegra20-timer"; reg = <0x60005000 0x60>;
arch/arm/boot/dts/tegra30.dtsi +9 -0
@@ -262,6 +262,15 @@ cache-level = <2>; }; + interrupt-controller at 60004000 { + compatible = "nvidia,tegra20-ictlr"; + reg = <0x60004000 0x40 /* primary controller */ + 0x60004100 0x40 /* secondary controller */ + 0x60004200 0x40 /* tertiary controller */ + 0x60004300 0x40 /* quaternary controller */ + 0x60004400 0x40>; /* quinary controller */ + }; + timer at 60005000 { compatible = "nvidia,tegra30-timer", "nvidia,tegra20-timer"; reg = <0x60005000 0x400>;
Signature · 1 line
2.0.0
RFC 2/4 ARM: tegra: Add legacy interrupt controller nodes
Quoted 7 lines · Thierry Reding
From: Thierry Reding <[email protected]>
Add device tree nodes for the legacy interrupt controller so that the driver can get the register ranges from device tree rather than hard- coding them.
arch/arm/boot/dts/tegra20.dtsi
Quoted 9 lines
arch/arm/boot/dts/tegra20.dtsi +8
-0+ interrupt-controller at 60004000 { + compatible = "nvidia,tegra20-ictlr"; + reg = <0x60004000 0x40 /* primary controller */ + 0x60004100 0x40 /* secondary controller */ + 0x60004200 0x40 /* tertiary controller */ + 0x60004300 0x40 /* quaternary controller */ + 0x60004400 0x40>; /* quinary controller */ + };
The quinary controller doesn't exist on Tegra20.
arch/arm/boot/dts/tegra30.dtsi
Quoted 4 lines
arch/arm/boot/dts/tegra30.dtsi +2
-0+ interrupt-controller at 60004000 { + compatible = "nvidia,tegra20-ictlr";
At the least, each SoC should have an SoC-specific compatible value in addition to the base Tegra20 value in case we need to differentiate them in the future.
I'd be tempted to only include the SoC-specific value and omit the Tegra20-specific value so we don't have to care whether they're really 100% backwards-compatible, but it's probably safe to say they're all Tegra20 compatible (or all Tegra30 compatible given the 4-vs-5 controllers difference).
RFC 2/4 ARM: tegra: Add legacy interrupt controller nodes
Quoted 9 lines · Stephen Warren
Quoted 7 lines · Thierry Reding
From: Thierry Reding <[email protected]>
Add device tree nodes for the legacy interrupt controller so that the driver can get the register ranges from device tree rather than hard- coding them.
arch/arm/boot/dts/tegra20.dtsi +0
-0
Quoted 10 lines
arch/arm/boot/dts/tegra20.dtsi
Quoted 8 lines
arch/arm/boot/dts/tegra20.dtsi +8
-0+ interrupt-controller at 60004000 { + compatible = "nvidia,tegra20-ictlr"; + reg = <0x60004000 0x40 /* primary controller */ + 0x60004100 0x40 /* secondary controller */ + 0x60004200 0x40 /* tertiary controller */ + 0x60004300 0x40 /* quaternary controller */ + 0x60004400 0x40>; /* quinary controller */ + };The quinary controller doesn't exist on Tegra20.
Right, I've dropped it.
Quoted 9 lines
arch/arm/boot/dts/tegra30.dtsi
Quoted 4 lines
arch/arm/boot/dts/tegra30.dtsi +2
-0+ interrupt-controller at 60004000 { + compatible = "nvidia,tegra20-ictlr";At the least, each SoC should have an SoC-specific compatible value in addition to the base Tegra20 value in case we need to differentiate them in the future.
Quoted 5 lines
I'd be tempted to only include the SoC-specific value and omit the Tegra20-specific value so we don't have to care whether they're really 100% backwards-compatible, but it's probably safe to say they're all Tegra20 compatible (or all Tegra30 compatible given the 4-vs-5 controllers difference).
I've looked at the register specification files and I can't see any differences between Tegra20, Tegra30, Tegra114 and Tegra124. Except for the absence of a quinary controller on Tegra20.
I think I'll go with this:
tegra114.dtsi: compatible = "nvidia,tegra114-ictlr", "nvidia,tegra30-ictlr"; tegra124.dtsi: compatible = "nvidia,tegra124-ictlr", "nvidia,tegra30-ictlr"; tegra20.dtsi: compatible = "nvidia,tegra20-ictlr"; tegra30.dtsi: compatible = "nvidia,tegra30-ictlr";
Thierry
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 819 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20140628/242118ea/attachment.sig>
RFC 3/4 soc/tegra: Initialize interrupt controller from DT
In reply to Thierry RedingFrom: Thierry Reding <[email protected]>
Obtains the register ranges for the legacy interrupt controller from DT and provide hard-coded values as fallback.
--- drivers/soc/tegra/iomap.h | 18 ------------ drivers/soc/tegra/irq.c | 75 ++++++++++++++++++++++++++++++++++++----------- 2 files changed, 58 insertions(+), 35 deletions(-)
drivers/soc/tegra/iomap.h +0 -18
@@ -28,24 +28,6 @@#define TEGRA_ARM_PERIF_BASE 0x50040000#define TEGRA_ARM_PERIF_SIZE SZ_8K -#define TEGRA_ARM_INT_DIST_BASE 0x50041000 -#define TEGRA_ARM_INT_DIST_SIZE SZ_4K - -#define TEGRA_PRIMARY_ICTLR_BASE 0x60004000 -#define TEGRA_PRIMARY_ICTLR_SIZE SZ_64 - -#define TEGRA_SECONDARY_ICTLR_BASE 0x60004100 -#define TEGRA_SECONDARY_ICTLR_SIZE SZ_64 - -#define TEGRA_TERTIARY_ICTLR_BASE 0x60004200 -#define TEGRA_TERTIARY_ICTLR_SIZE SZ_64 - -#define TEGRA_QUATERNARY_ICTLR_BASE 0x60004300 -#define TEGRA_QUATERNARY_ICTLR_SIZE SZ_64 - -#define TEGRA_QUINARY_ICTLR_BASE 0x60004400 -#define TEGRA_QUINARY_ICTLR_SIZE SZ_64 -#define TEGRA_TMR1_BASE 0x60005000#define TEGRA_TMR1_SIZE SZ_8
drivers/soc/tegra/irq.c +58 -17
122 lines not on this page · raw message
Signature · 1 line
2.0.0
RFC 3/4 soc/tegra: Initialize interrupt controller from DT
Quoted 6 lines · Thierry Reding
From: Thierry Reding <[email protected]>
Obtains the register ranges for the legacy interrupt controller from DT and provide hard-coded values as fallback.
drivers/soc/tegra/irq.c static void tegra114_gic_cpu_pm_registration(void) · line 279
Quoted 9 lines
drivers/soc/tegra/irq.c +5
-1void __init tegra_init_irq (void ) - distbase =IO_ADDRESS (TEGRA_ARM_INT_DIST_BASE ); + np =of_find_matching_node (NULL , ictlr_matches); +if (np) { +for (i =0 ; i <ARRAY_SIZE (ictlr_regs); i++) +if (of_address_to_resource (np, i, &res) ==0 ) + ictlr_regs[i] = res;
It'd be nice to check that loop ran exactly the number of times expected based on the compatible value (i.e. SoC) if the legacy interrupt controller node.
What about erroring out if entries are missing or can't be parsed.
drivers/soc/tegra/irq.c static void tegra114_gic_cpu_pm_registration(void) · line 303
Quoted 4 lines
drivers/soc/tegra/irq.c +1
-1if (num_ictlrs >ARRAY_SIZE (ictlr_reg_base)) { -WARN (1 ,"Too many (%d) interrupt controllers found. Maximum is %d." , +WARN (1 ,"Too many (%d) interrupt controllers found. Maximum is %zu." , num_ictlrs,ARRAY_SIZE (ictlr_reg_base));
While we're changing this, maybe we should change that test to "num_ictlrs != the expected value", so too few is found as well.
RFC 3/4 soc/tegra: Initialize interrupt controller from DT
Quoted 21 lines · Stephen Warren
Quoted 6 lines · Thierry Reding
From: Thierry Reding <[email protected]>
Obtains the register ranges for the legacy interrupt controller from DT and provide hard-coded values as fallback.
drivers/soc/tegra/irq.c static void tegra114_gic_cpu_pm_registration(void) · line 279
Quoted 9 lines
drivers/soc/tegra/irq.c +5
-1void __init tegra_init_irq (void ) - distbase =IO_ADDRESS (TEGRA_ARM_INT_DIST_BASE ); + np =of_find_matching_node (NULL , ictlr_matches); +if (np) { +for (i =0 ; i <ARRAY_SIZE (ictlr_regs); i++) +if (of_address_to_resource (np, i, &res) ==0 ) + ictlr_regs[i] = res;It'd be nice to check that loop ran exactly the number of times expected based on the compatible value (i.e. SoC) if the legacy interrupt controller node.
Quoted 1 line
What about erroring out if entries are missing or can't be parsed.
I've added some strict checking of the expected number of entries. I decided against erroring out on missing entries or when they can't be parsed because we can still continue using the fallback entries in the ictlr_regs table. However if a mismatch between the number of detected entries and the expected entries is detected, the code will now WARN.
Quoted 7 lines
drivers/soc/tegra/irq.c static void tegra114_gic_cpu_pm_registration(void) · line 303
Quoted 4 lines
drivers/soc/tegra/irq.c +1
-1if (num_ictlrs >ARRAY_SIZE (ictlr_reg_base)) { -WARN (1 ,"Too many (%d) interrupt controllers found. Maximum is %d." , +WARN (1 ,"Too many (%d) interrupt controllers found. Maximum is %zu." , num_ictlrs,ARRAY_SIZE (ictlr_reg_base));While we're changing this, maybe we should change that test to "
num_ictlrs!= the expected value", so too few is found as well.
Done. This is slightly complicated by the fact that the non-DT code has no notion of how many are expected. The maximum number is only used to prevent overflows when accessing the ictlr_reg_base array.
I've solved this by selecting the maximum depending on tegra_chip_id. I have sent a v2 to the list with the patch removed that moves all the drivers to drivers/soc since more work will be required for that. In the meantime this change is separate and can be merged independent of that.
Thierry
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 819 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20140628/a0ff50f7/attachment.sig>
RFC 3/4 soc/tegra: Initialize interrupt controller from DT
In reply to Thierry RedingQuoted 5 lines · Thierry Reding
From: Thierry Reding <[email protected]>
Obtains the register ranges for the legacy interrupt controller from DT and provide hard-coded values as fallback.
Any reason this file cannot be in drivers/irqchip/ ?
Cheers,
Peter.
RFC 3/4 soc/tegra: Initialize interrupt controller from DT
Quoted 8 lines · Peter De Schrijver
Quoted 5 lines · Thierry Reding
From: Thierry Reding <[email protected]>
Obtains the register ranges for the legacy interrupt controller from DT and provide hard-coded values as fallback.
Any reason this file cannot be in
drivers/irqchip/?
I seem to remember that I tried that at one point and it didn't work, but I can't recall the exact reason. I'll give it another try.
Thierry
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 836 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20140630/4e814634/attachment.sig>
RFC 4/4 soc/tegra: Remove unused defines
In reply to Thierry RedingFrom: Thierry Reding <[email protected]>
Eventually the aim is to get rid of this file because it cannot be built on ARM64. Until it can be completely removed, eliminate unused entries to make it easier to see which are still used.
--- drivers/soc/tegra/iomap.h | 30 ------------------------------ 1 file changed, 30 deletions(-)
drivers/soc/tegra/iomap.h +0 -30
@@ -28,21 +28,9 @@#define TEGRA_ARM_PERIF_BASE 0x50040000#define TEGRA_ARM_PERIF_SIZE SZ_8K -#define TEGRA_TMR1_BASE 0x60005000 -#define TEGRA_TMR1_SIZE SZ_8 - -#define TEGRA_TMR2_BASE 0x60005008 -#define TEGRA_TMR2_SIZE SZ_8 -#define TEGRA_TMRUS_BASE 0x60005010#define TEGRA_TMRUS_SIZE SZ_64 -#define TEGRA_TMR3_BASE 0x60005050 -#define TEGRA_TMR3_SIZE SZ_8 - -#define TEGRA_TMR4_BASE 0x60005058 -#define TEGRA_TMR4_SIZE SZ_8 -#define TEGRA_CLK_RESET_BASE 0x60006000#define TEGRA_CLK_RESET_SIZE SZ_4K
@@ -58,21 +46,6 @@#define TEGRA_APB_MISC_BASE 0x70000000#define TEGRA_APB_MISC_SIZE SZ_4K -#define TEGRA_UARTA_BASE 0x70006000 -#define TEGRA_UARTA_SIZE SZ_64 - -#define TEGRA_UARTB_BASE 0x70006040 -#define TEGRA_UARTB_SIZE SZ_64 - -#define TEGRA_UARTC_BASE 0x70006200 -#define TEGRA_UARTC_SIZE SZ_256 - -#define TEGRA_UARTD_BASE 0x70006300 -#define TEGRA_UARTD_SIZE SZ_256 - -#define TEGRA_UARTE_BASE 0x70006400 -#define TEGRA_UARTE_SIZE SZ_256 -#define TEGRA_PMC_BASE 0x7000E400#define TEGRA_PMC_SIZE SZ_256
@@ -91,9 +64,6 @@#define TEGRA124_EMC_BASE 0x7001B000#define TEGRA124_EMC_SIZE SZ_2K -#define TEGRA_CSITE_BASE 0x70040000 -#define TEGRA_CSITE_SIZE SZ_256K -/* On TEGRA, many peripherals are very closely packed in * two 256MB io windows (that actually only use about 64KB * at the start of each).
Signature · 1 line
2.0.0
RFC 4/4 soc/tegra: Remove unused defines
Quoted 5 lines · Thierry Reding
From: Thierry Reding <[email protected]>
Eventually the aim is to get rid of this file because it cannot be built on ARM64. Until it can be completely removed, eliminate unused entries to make it easier to see which are still used.
RFC 4/4 soc/tegra: Remove unused defines
Quoted 8 lines · Stephen Warren
Quoted 5 lines · Thierry Reding
From: Thierry Reding <[email protected]>
Eventually the aim is to get rid of this file because it cannot be built on ARM64. Until it can be completely removed, eliminate unused entries to make it easier to see which are still used.
Reviewed-by Stephen Warren <[email protected]>
Thanks.
Thierry
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 819 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20140628/a256648d/attachment.sig>
RFC 1/4 ARM: tegra: Move SoC drivers to drivers/soc/tegra
In reply to Thierry Reding+Arnd, Greg, Catalin and Kumar,
Quoted 68 lines · Thierry Reding
From: Thierry Reding <[email protected]>
These drivers are closely coupled and need to be moved as a whole. One reason for moving them out of
arch/arm/mach-tegrais to allow them to be shared with 64-bit ARM.Signed-off-by Thierry Reding <[email protected]>--- arch/arm/mach-tegra/Makefile | 32 -------- arch/arm/mach-tegra/common.h | 4 - arch/arm/mach-tegra/io.c | 27 +++++- arch/arm/mach-tegra/pmc.h | 62 -------------- arch/arm/mach-tegra/tegra.c | 9 -- drivers/soc/Makefile | 1 + drivers/soc/tegra/Makefile | 34 ++++++++ .../soc/tegra}/cpuidle-tegra114.c | 0 .../soc/tegra}/cpuidle-tegra20.c | 6 +- .../soc/tegra}/cpuidle-tegra30.c | 0 .../arm/mach-tegra => drivers/soc/tegra}/cpuidle.c | 0 .../arm/mach-tegra => drivers/soc/tegra}/cpuidle.h | 3 - .../mach-tegra => drivers/soc/tegra}/flowctrl.c | 0 .../mach-tegra => drivers/soc/tegra}/flowctrl.h | 2 - .../arm/mach-tegra => drivers/soc/tegra}/headsmp.S | 0 .../arm/mach-tegra => drivers/soc/tegra}/hotplug.c | 0 {arch/arm/mach-tegra => drivers/soc/tegra}/iomap.h | 0 .../arm/mach-tegra => drivers/soc/tegra}/irammap.h | 0 {arch/arm/mach-tegra => drivers/soc/tegra}/irq.c | 1 - {arch/arm/mach-tegra => drivers/soc/tegra}/irq.h | 6 -- .../arm/mach-tegra => drivers/soc/tegra}/platsmp.c | 5 -- .../mach-tegra => drivers/soc/tegra}/pm-tegra20.c | 0 .../mach-tegra => drivers/soc/tegra}/pm-tegra30.c | 0 {arch/arm/mach-tegra => drivers/soc/tegra}/pm.c | 0 {arch/arm/mach-tegra => drivers/soc/tegra}/pm.h | 4 +- {arch/arm/mach-tegra => drivers/soc/tegra}/pmc.c | 0 drivers/soc/tegra/pmc.h | 35 ++++++++ .../mach-tegra => drivers/soc/tegra}/powergate.c | 0 .../soc/tegra}/reset-handler.S | 0 {arch/arm/mach-tegra => drivers/soc/tegra}/reset.c | 0 {arch/arm/mach-tegra => drivers/soc/tegra}/reset.h | 2 - .../soc/tegra}/sleep-tegra20.S | 0 .../soc/tegra}/sleep-tegra30.S | 0 {arch/arm/mach-tegra => drivers/soc/tegra}/sleep.S | 0 {arch/arm/mach-tegra => drivers/soc/tegra}/sleep.h | 2 - include/linux/tegra-soc.h | 95 ++++++++++++++++++++++ 36 files changed, 195 insertions(+), 135 deletions(-) delete mode 100644 arch/arm/mach-tegra/common.h delete mode 100644 arch/arm/mach-tegra/pmc.h create mode 100644 drivers/soc/tegra/Makefile rename {arch/arm/mach-tegra => drivers/soc/tegra}/cpuidle-tegra114.c (100%) rename {arch/arm/mach-tegra => drivers/soc/tegra}/cpuidle-tegra20.c (100%) rename {arch/arm/mach-tegra => drivers/soc/tegra}/cpuidle-tegra30.c (100%) rename {arch/arm/mach-tegra => drivers/soc/tegra}/cpuidle.c (100%) rename {arch/arm/mach-tegra => drivers/soc/tegra}/cpuidle.h (91%) rename {arch/arm/mach-tegra => drivers/soc/tegra}/flowctrl.c (100%) rename {arch/arm/mach-tegra => drivers/soc/tegra}/flowctrl.h (98%) rename {arch/arm/mach-tegra => drivers/soc/tegra}/headsmp.S (100%) rename {arch/arm/mach-tegra => drivers/soc/tegra}/hotplug.c (100%) rename {arch/arm/mach-tegra => drivers/soc/tegra}/iomap.h (100%) rename {arch/arm/mach-tegra => drivers/soc/tegra}/irammap.h (100%) rename {arch/arm/mach-tegra => drivers/soc/tegra}/irq.c (99%) rename {arch/arm/mach-tegra => drivers/soc/tegra}/irq.h (83%) rename {arch/arm/mach-tegra => drivers/soc/tegra}/platsmp.c (98%) rename {arch/arm/mach-tegra => drivers/soc/tegra}/pm-tegra20.c (100%) rename {arch/arm/mach-tegra => drivers/soc/tegra}/pm-tegra30.c (100%) rename {arch/arm/mach-tegra => drivers/soc/tegra}/pm.c (100%) rename {arch/arm/mach-tegra => drivers/soc/tegra}/pm.h (94%) rename {arch/arm/mach-tegra => drivers/soc/tegra}/pmc.c (100%) create mode 100644 drivers/soc/tegra/pmc.h
Quoted 9 lines
rename {arch/arm/mach-tegra => drivers/soc/tegra}/powergate.c (100%)
rename {arch/arm/mach-tegra => drivers/soc/tegra}/reset-handler.S (100%)
rename {arch/arm/mach-tegra => drivers/soc/tegra}/reset.c (100%)
rename {arch/arm/mach-tegra => drivers/soc/tegra}/reset.h (97%)
rename {arch/arm/mach-tegra => drivers/soc/tegra}/sleep-tegra20.S (100%)
rename {arch/arm/mach-tegra => drivers/soc/tegra}/sleep-tegra30.S (100%)
rename {arch/arm/mach-tegra => drivers/soc/tegra}/sleep.S (100%)
rename {arch/arm/mach-tegra => drivers/soc/tegra}/sleep.h (98%)NAK for this patch.
You are using drivers/soc/* as a dump yard for your SOC code which is not the intention we created drivers/soc/.
Its really for subsystem drivers which doesn't have appropriate home in Linux kernel today. From your above patch ...
Quoted 5 lines
rename {arch/arm/mach-tegra => drivers/soc/tegra}/cpuidle-tegra114.c (100%)
rename {arch/arm/mach-tegra => drivers/soc/tegra}/cpuidle-tegra20.c (100%)
rename {arch/arm/mach-tegra => drivers/soc/tegra}/cpuidle-tegra30.c (100%)
rename {arch/arm/mach-tegra => drivers/soc/tegra}/cpuidle.c (100%)
rename {arch/arm/mach-tegra => drivers/soc/tegra}/cpuidle.h (91%)This should go into drivers/idle/*. if you have dependencies, please sort them out.
Quoted 3 lines
rename {arch/arm/mach-tegra => drivers/soc/tegra}/reset-handler.S (100%)
rename {arch/arm/mach-tegra => drivers/soc/tegra}/reset.c (100%)
rename {arch/arm/mach-tegra => drivers/soc/tegra}/reset.h (97%)subsystem: drivers/power/reset/
For tegra/*pm*/, you can use drivers/power or drivers/base/power/
For SMP boot, ARMv8 expecting to have either PSCI based implementation or device tree based boot scheme. you can move towards that model if possible.
Please find appropriate subsystem to move your SOC code and if you don't find an appropriate subsystem, we can discuss adding that under drivers/soc. The drivers/soc/* isn't a dumping ground so please don't abuse it.
regards,
Santosh
RFC 1/4 ARM: tegra: Move SoC drivers to drivers/soc/tegra
Quoted 80 lines · Santosh Shilimkar
+Arnd, Greg, Catalin and Kumar,
Quoted 68 lines · Thierry Reding
From: Thierry Reding <[email protected]>
These drivers are closely coupled and need to be moved as a whole. One reason for moving them out of
arch/arm/mach-tegrais to allow them to be shared with 64-bit ARM.Signed-off-by Thierry Reding <[email protected]>--- arch/arm/mach-tegra/Makefile | 32 -------- arch/arm/mach-tegra/common.h | 4 - arch/arm/mach-tegra/io.c | 27 +++++- arch/arm/mach-tegra/pmc.h | 62 -------------- arch/arm/mach-tegra/tegra.c | 9 -- drivers/soc/Makefile | 1 + drivers/soc/tegra/Makefile | 34 ++++++++ .../soc/tegra}/cpuidle-tegra114.c | 0 .../soc/tegra}/cpuidle-tegra20.c | 6 +- .../soc/tegra}/cpuidle-tegra30.c | 0 .../arm/mach-tegra => drivers/soc/tegra}/cpuidle.c | 0 .../arm/mach-tegra => drivers/soc/tegra}/cpuidle.h | 3 - .../mach-tegra => drivers/soc/tegra}/flowctrl.c | 0 .../mach-tegra => drivers/soc/tegra}/flowctrl.h | 2 - .../arm/mach-tegra => drivers/soc/tegra}/headsmp.S | 0 .../arm/mach-tegra => drivers/soc/tegra}/hotplug.c | 0 {arch/arm/mach-tegra => drivers/soc/tegra}/iomap.h | 0 .../arm/mach-tegra => drivers/soc/tegra}/irammap.h | 0 {arch/arm/mach-tegra => drivers/soc/tegra}/irq.c | 1 - {arch/arm/mach-tegra => drivers/soc/tegra}/irq.h | 6 -- .../arm/mach-tegra => drivers/soc/tegra}/platsmp.c | 5 -- .../mach-tegra => drivers/soc/tegra}/pm-tegra20.c | 0 .../mach-tegra => drivers/soc/tegra}/pm-tegra30.c | 0 {arch/arm/mach-tegra => drivers/soc/tegra}/pm.c | 0 {arch/arm/mach-tegra => drivers/soc/tegra}/pm.h | 4 +- {arch/arm/mach-tegra => drivers/soc/tegra}/pmc.c | 0 drivers/soc/tegra/pmc.h | 35 ++++++++ .../mach-tegra => drivers/soc/tegra}/powergate.c | 0 .../soc/tegra}/reset-handler.S | 0 {arch/arm/mach-tegra => drivers/soc/tegra}/reset.c | 0 {arch/arm/mach-tegra => drivers/soc/tegra}/reset.h | 2 - .../soc/tegra}/sleep-tegra20.S | 0 .../soc/tegra}/sleep-tegra30.S | 0 {arch/arm/mach-tegra => drivers/soc/tegra}/sleep.S | 0 {arch/arm/mach-tegra => drivers/soc/tegra}/sleep.h | 2 - include/linux/tegra-soc.h | 95 ++++++++++++++++++++++ 36 files changed, 195 insertions(+), 135 deletions(-) delete mode 100644 arch/arm/mach-tegra/common.h delete mode 100644 arch/arm/mach-tegra/pmc.h create mode 100644 drivers/soc/tegra/Makefile rename {arch/arm/mach-tegra => drivers/soc/tegra}/cpuidle-tegra114.c (100%) rename {arch/arm/mach-tegra => drivers/soc/tegra}/cpuidle-tegra20.c (100%) rename {arch/arm/mach-tegra => drivers/soc/tegra}/cpuidle-tegra30.c (100%) rename {arch/arm/mach-tegra => drivers/soc/tegra}/cpuidle.c (100%) rename {arch/arm/mach-tegra => drivers/soc/tegra}/cpuidle.h (91%) rename {arch/arm/mach-tegra => drivers/soc/tegra}/flowctrl.c (100%) rename {arch/arm/mach-tegra => drivers/soc/tegra}/flowctrl.h (98%) rename {arch/arm/mach-tegra => drivers/soc/tegra}/headsmp.S (100%) rename {arch/arm/mach-tegra => drivers/soc/tegra}/hotplug.c (100%) rename {arch/arm/mach-tegra => drivers/soc/tegra}/iomap.h (100%) rename {arch/arm/mach-tegra => drivers/soc/tegra}/irammap.h (100%) rename {arch/arm/mach-tegra => drivers/soc/tegra}/irq.c (99%) rename {arch/arm/mach-tegra => drivers/soc/tegra}/irq.h (83%) rename {arch/arm/mach-tegra => drivers/soc/tegra}/platsmp.c (98%) rename {arch/arm/mach-tegra => drivers/soc/tegra}/pm-tegra20.c (100%) rename {arch/arm/mach-tegra => drivers/soc/tegra}/pm-tegra30.c (100%) rename {arch/arm/mach-tegra => drivers/soc/tegra}/pm.c (100%) rename {arch/arm/mach-tegra => drivers/soc/tegra}/pm.h (94%) rename {arch/arm/mach-tegra => drivers/soc/tegra}/pmc.c (100%) create mode 100644 drivers/soc/tegra/pmc.hQuoted 9 lines
rename {arch/arm/mach-tegra => drivers/soc/tegra}/powergate.c (100%) rename {arch/arm/mach-tegra => drivers/soc/tegra}/reset-handler.S (100%) rename {arch/arm/mach-tegra => drivers/soc/tegra}/reset.c (100%) rename {arch/arm/mach-tegra => drivers/soc/tegra}/reset.h (97%) rename {arch/arm/mach-tegra => drivers/soc/tegra}/sleep-tegra20.S (100%) rename {arch/arm/mach-tegra => drivers/soc/tegra}/sleep-tegra30.S (100%) rename {arch/arm/mach-tegra => drivers/soc/tegra}/sleep.S (100%) rename {arch/arm/mach-tegra => drivers/soc/tegra}/sleep.h (98%)
Quoted 4 lines
NAK for this patch.
You are using
drivers/soc/*as a dump yard for your SOC code which is not the intention we createddrivers/soc/.
That was not my intention. What remains in arch/arm/mach-tegra at this point doesn't actually have a corresponding subsystem (well, except maybe the cpuidle code).
Quoted 10 lines
Its really for subsystem drivers which doesn't have appropriate home in Linux kernel today. From your above patch ...
Quoted 5 lines
rename {arch/arm/mach-tegra => drivers/soc/tegra}/cpuidle-tegra114.c (100%) rename {arch/arm/mach-tegra => drivers/soc/tegra}/cpuidle-tegra20.c (100%) rename {arch/arm/mach-tegra => drivers/soc/tegra}/cpuidle-tegra30.c (100%) rename {arch/arm/mach-tegra => drivers/soc/tegra}/cpuidle.c (100%) rename {arch/arm/mach-tegra => drivers/soc/tegra}/cpuidle.h (91%)This should go into
drivers/idle/*. if you have dependencies, please sort them out.
What exactly is the difference between drivers/idle and drivers/cpuidle? There's an intel_idle driver in drivers/idle that includes cpuidle.h and registers with that subsystem. But there's also an i7300_idle driver that doesn't.
drivers/cpuidle seems like a better fit. I'll look into moving the code there.
Quoted 4 lines
Quoted 3 lines
rename {arch/arm/mach-tegra => drivers/soc/tegra}/reset-handler.S (100%) rename {arch/arm/mach-tegra => drivers/soc/tegra}/reset.c (100%) rename {arch/arm/mach-tegra => drivers/soc/tegra}/reset.h (97%)subsystem:
drivers/power/reset/
drivers/power/reset seems to be for drivers that register functions to reset a board. The above code for Tegra doesn't do that. Rather it sets up the reset handlers for secondary CPUs and for suspend/resume.
Quoted 1 line
For tegra/*pm*/, you can use
drivers/powerordrivers/base/power/
drivers/power seems to be exclusively battery charger drivers. The pm.c, pm-*.c and sleep-*.S set up suspend/resume. That doesn't seem to belong in drivers/base/power either.
pmc.c implements various routines to access the power management controller, some of which is needed by suspend/resume, some of it is needed by SMP. powergate.c implements a subset of the PMC that needs to be exported to drivers to enable power partitions on the SoC. I'm not aware of subsystems that deal with this kind of driver.
Quoted 2 lines
For SMP boot, ARMv8 expecting to have either PSCI based implementation or device tree based boot scheme. you can move towards that model if possible.
But we also have the code for SMP on 32-bit ARM. Should that remain in arch/arm/mach-tegra or can it move to drivers/soc/tegra?
So the only thing in the above that I think could be moved somewhere else is the cpuidle drivers. Or do you have any other suggestions for the remaining code?
Thierry
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 819 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20140628/e7cc45f2/attachment.sig>
RFC 1/4 ARM: tegra: Move SoC drivers to drivers/soc/tegra
Quoted 101 lines · Thierry Reding
Quoted 80 lines · Santosh Shilimkar
+Arnd, Greg, Catalin and Kumar,
Quoted 68 lines · Thierry Reding
From: Thierry Reding <[email protected]>
These drivers are closely coupled and need to be moved as a whole. One reason for moving them out of
arch/arm/mach-tegrais to allow them to be shared with 64-bit ARM.Signed-off-by Thierry Reding <[email protected]>--- arch/arm/mach-tegra/Makefile | 32 -------- arch/arm/mach-tegra/common.h | 4 - arch/arm/mach-tegra/io.c | 27 +++++- arch/arm/mach-tegra/pmc.h | 62 -------------- arch/arm/mach-tegra/tegra.c | 9 -- drivers/soc/Makefile | 1 + drivers/soc/tegra/Makefile | 34 ++++++++ .../soc/tegra}/cpuidle-tegra114.c | 0 .../soc/tegra}/cpuidle-tegra20.c | 6 +- .../soc/tegra}/cpuidle-tegra30.c | 0 .../arm/mach-tegra => drivers/soc/tegra}/cpuidle.c | 0 .../arm/mach-tegra => drivers/soc/tegra}/cpuidle.h | 3 - .../mach-tegra => drivers/soc/tegra}/flowctrl.c | 0 .../mach-tegra => drivers/soc/tegra}/flowctrl.h | 2 - .../arm/mach-tegra => drivers/soc/tegra}/headsmp.S | 0 .../arm/mach-tegra => drivers/soc/tegra}/hotplug.c | 0 {arch/arm/mach-tegra => drivers/soc/tegra}/iomap.h | 0 .../arm/mach-tegra => drivers/soc/tegra}/irammap.h | 0 {arch/arm/mach-tegra => drivers/soc/tegra}/irq.c | 1 - {arch/arm/mach-tegra => drivers/soc/tegra}/irq.h | 6 -- .../arm/mach-tegra => drivers/soc/tegra}/platsmp.c | 5 -- .../mach-tegra => drivers/soc/tegra}/pm-tegra20.c | 0 .../mach-tegra => drivers/soc/tegra}/pm-tegra30.c | 0 {arch/arm/mach-tegra => drivers/soc/tegra}/pm.c | 0 {arch/arm/mach-tegra => drivers/soc/tegra}/pm.h | 4 +- {arch/arm/mach-tegra => drivers/soc/tegra}/pmc.c | 0 drivers/soc/tegra/pmc.h | 35 ++++++++ .../mach-tegra => drivers/soc/tegra}/powergate.c | 0 .../soc/tegra}/reset-handler.S | 0 {arch/arm/mach-tegra => drivers/soc/tegra}/reset.c | 0 {arch/arm/mach-tegra => drivers/soc/tegra}/reset.h | 2 - .../soc/tegra}/sleep-tegra20.S | 0 .../soc/tegra}/sleep-tegra30.S | 0 {arch/arm/mach-tegra => drivers/soc/tegra}/sleep.S | 0 {arch/arm/mach-tegra => drivers/soc/tegra}/sleep.h | 2 - include/linux/tegra-soc.h | 95 ++++++++++++++++++++++ 36 files changed, 195 insertions(+), 135 deletions(-) delete mode 100644 arch/arm/mach-tegra/common.h delete mode 100644 arch/arm/mach-tegra/pmc.h create mode 100644 drivers/soc/tegra/Makefile rename {arch/arm/mach-tegra => drivers/soc/tegra}/cpuidle-tegra114.c (100%) rename {arch/arm/mach-tegra => drivers/soc/tegra}/cpuidle-tegra20.c (100%) rename {arch/arm/mach-tegra => drivers/soc/tegra}/cpuidle-tegra30.c (100%) rename {arch/arm/mach-tegra => drivers/soc/tegra}/cpuidle.c (100%) rename {arch/arm/mach-tegra => drivers/soc/tegra}/cpuidle.h (91%) rename {arch/arm/mach-tegra => drivers/soc/tegra}/flowctrl.c (100%) rename {arch/arm/mach-tegra => drivers/soc/tegra}/flowctrl.h (98%) rename {arch/arm/mach-tegra => drivers/soc/tegra}/headsmp.S (100%) rename {arch/arm/mach-tegra => drivers/soc/tegra}/hotplug.c (100%) rename {arch/arm/mach-tegra => drivers/soc/tegra}/iomap.h (100%) rename {arch/arm/mach-tegra => drivers/soc/tegra}/irammap.h (100%) rename {arch/arm/mach-tegra => drivers/soc/tegra}/irq.c (99%) rename {arch/arm/mach-tegra => drivers/soc/tegra}/irq.h (83%) rename {arch/arm/mach-tegra => drivers/soc/tegra}/platsmp.c (98%) rename {arch/arm/mach-tegra => drivers/soc/tegra}/pm-tegra20.c (100%) rename {arch/arm/mach-tegra => drivers/soc/tegra}/pm-tegra30.c (100%) rename {arch/arm/mach-tegra => drivers/soc/tegra}/pm.c (100%) rename {arch/arm/mach-tegra => drivers/soc/tegra}/pm.h (94%) rename {arch/arm/mach-tegra => drivers/soc/tegra}/pmc.c (100%) create mode 100644 drivers/soc/tegra/pmc.hQuoted 9 lines
rename {arch/arm/mach-tegra => drivers/soc/tegra}/powergate.c (100%) rename {arch/arm/mach-tegra => drivers/soc/tegra}/reset-handler.S (100%) rename {arch/arm/mach-tegra => drivers/soc/tegra}/reset.c (100%) rename {arch/arm/mach-tegra => drivers/soc/tegra}/reset.h (97%) rename {arch/arm/mach-tegra => drivers/soc/tegra}/sleep-tegra20.S (100%) rename {arch/arm/mach-tegra => drivers/soc/tegra}/sleep-tegra30.S (100%) rename {arch/arm/mach-tegra => drivers/soc/tegra}/sleep.S (100%) rename {arch/arm/mach-tegra => drivers/soc/tegra}/sleep.h (98%)Quoted 4 lines
NAK for this patch.
You are using
drivers/soc/*as a dump yard for your SOC code which is not the intention we createddrivers/soc/.That was not my intention. What remains in
arch/arm/mach-tegraat this point doesn't actually have a corresponding subsystem (well, except maybe the cpuidle code).Quoted 10 lines
Its really for subsystem drivers which doesn't have appropriate home in Linux kernel today. From your above patch ...
Quoted 5 lines
rename {arch/arm/mach-tegra => drivers/soc/tegra}/cpuidle-tegra114.c (100%) rename {arch/arm/mach-tegra => drivers/soc/tegra}/cpuidle-tegra20.c (100%) rename {arch/arm/mach-tegra => drivers/soc/tegra}/cpuidle-tegra30.c (100%) rename {arch/arm/mach-tegra => drivers/soc/tegra}/cpuidle.c (100%) rename {arch/arm/mach-tegra => drivers/soc/tegra}/cpuidle.h (91%)This should go into
drivers/idle/*. if you have dependencies, please sort them out.
Quoted 8 lines
What exactly is the difference between
drivers/idleanddrivers/cpuidle? There's anintel_idledriver indrivers/idlethat includescpuidle.hand registers with that subsystem. But there's also ani7300_idledriver that doesn't.
drivers/cpuidleseems like a better fit. I'll look into moving the code there.
I meant drivers/cpuidle.
Quoted 9 lines
Quoted 4 lines
Quoted 3 lines
rename {arch/arm/mach-tegra => drivers/soc/tegra}/reset-handler.S (100%) rename {arch/arm/mach-tegra => drivers/soc/tegra}/reset.c (100%) rename {arch/arm/mach-tegra => drivers/soc/tegra}/reset.h (97%)subsystem:
drivers/power/reset/
drivers/power/resetseems to be for drivers that register functions to reset a board. The above code for Tegra doesn't do that. Rather it sets up the reset handlers for secondary CPUs and for suspend/resume.
So this is the suspend code which should go along with rest of your PM code.
Quoted 6 lines
Quoted 1 line
For tegra/*pm*/, you can use
drivers/powerordrivers/base/power/
drivers/powerseems to be exclusively battery charger drivers. Thepm.c, pm-*.c and sleep-*.S set up suspend/resume. That doesn't seem to belong indrivers/base/powereither.
It does have AVS PM code as well and also home for power controller code. Similar efforts are happening on OMAP [1] to move the PM code under drivers/power/*
Quoted 6 lines
pmc.cimplements various routines to access the power management controller, some of which is needed by suspend/resume, some of it is needed by SMP.powergate.cimplements a subset of the PMC that needs to be exported to drivers to enable power partitions on the SoC. I'm not aware of subsystems that deal with this kind of driver.
Please see above.
Quoted 6 lines
Quoted 2 lines
For SMP boot, ARMv8 expecting to have either PSCI based implementation or device tree based boot scheme. you can move towards that model if possible.
But we also have the code for SMP on 32-bit ARM. Should that remain in
arch/arm/mach-tegraor can it move todrivers/soc/tegra?
You answered yourself. I don't see any point moving such a code to drivers which is really SMP bring up code for ARM 32 bit. For ARM 64 bit, as outline by maintainers (Catalin, Arnd), you should use PSCI or DT based boot scheme.
Quoted 4 lines
So the only thing in the above that I think could be moved somewhere else is the cpuidle drivers. Or do you have any other suggestions for the remaining code?
Infact all of your code already has a potential home and I suggest you discuss it with those subsystem maintainers.
[1] "[PATCH 00/55]: ARM: OMAP2+: PRCM move to drivers"
http://www.spinics.net/lists/arm-kernel/msg319360.html
RFC 1/4 ARM: tegra: Move SoC drivers to drivers/soc/tegra
Quoted 1 line · Santosh Shilimkar
On Friday 27 June 2014 07:27 PM, Thierry Reding wrote:
[...]
Quoted 7 lines
Quoted 4 lines
drivers/powerseems to be exclusively battery charger drivers. Thepm.c, pm-*.c and sleep-*.S set up suspend/resume. That doesn't seem to belong indrivers/base/powereither.It does have AVS PM code as well and also home for power controller code. Similar efforts are happening on OMAP [1] to move the PM code under
drivers/power/*
Quite frankly that doesn't sound any better than putting that code into drivers/soc. If there is no common framework for a set of drivers, then I don't see what improvement we get by putting all of them together. If anything it makes things more chaotic because we sprinkle random driver bits across the whole tree rather than keeping them together.
That sounds a lot like a dumping ground to me.
According to the MAINTAINERS file, drivers/power is:
POWER SUPPLY CLASS/SUBSYSTEM and DRIVERS
and that's just not what the Tegra PM code is. That said, it may have been a little premature to move this code out of arch/arm/mach-tegra, and I think I'll revisit at a later point.
Quoted 7 lines
Quoted 6 lines
pmc.cimplements various routines to access the power management controller, some of which is needed by suspend/resume, some of it is needed by SMP.powergate.cimplements a subset of the PMC that needs to be exported to drivers to enable power partitions on the SoC. I'm not aware of subsystems that deal with this kind of driver.Please see above.
Like I said, I don't see what business suspend/resume related code has in drivers/power. What we're talking about here really is functionality very specific to Tegra. Also some of that code needs to be run at very early points in the boot process, so we can't reasonably turn it into a proper driver anyway.
Also, the real win we get from moving code out into drivers/ is if we can provide a common framework for them. I don't see how we can possibly do that for this code since there simply isn't enough commonality between SoCs. At the same time we now have a situation where both 32-bit and 64-bit variants of some SoCs share some of the same hardware at the very low level and since we don't have mach-* directories for 64-bit ARM and shouldn't be duplicating code either, we need to find a new home for this type of code. drivers/soc seemed to fit perfectly well.
Thierry
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 819 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20140628/8cdfdb3a/attachment.sig>
RFC 1/4 ARM: tegra: Move SoC drivers to drivers/soc/tegra
Quoted 6 lines · On Saturday 28 June 2014 22:40:26 Thierry Reding wrote:
Quoted 6 lines
Quoted 6 lines
pmc.cimplements various routines to access the power management controller, some of which is needed by suspend/resume, some of it is needed by SMP.powergate.cimplements a subset of the PMC that needs to be exported to drivers to enable power partitions on the SoC. I'm not aware of subsystems that deal with this kind of driver.
Quoted 7 lines
Quoted 1 line
Please see above.
Like I said, I don't see what business suspend/resume related code has in
drivers/power. What we're talking about here really is functionality very specific to Tegra. Also some of that code needs to be run at very early points in the boot process, so we can't reasonably turn it into a proper driver anyway.
I believe the powergate.c stuff can be changed into pm_domain code, but we don't have a good subsystem with generic DT bindings yet, so that may need some more groundwork first. drivers/power or a subdirectory of that may end up being the right place though.
Quoted 8 lines
Also, the real win we get from moving code out into
drivers/is if we can provide a common framework for them. I don't see how we can possibly do that for this code since there simply isn't enough commonality between SoCs. At the same time we now have a situation where both 32-bit and 64-bit variants of some SoCs share some of the same hardware at the very low level and since we don't have mach-* directories for 64-bit ARM and shouldn't be duplicating code either, we need to find a new home for this type of code.drivers/socseemed to fit perfectly well.
For the low-level stuff yes, but I agree with Santosh there needs to be some more work trying to split out individual high-level drivers.
There are two common patterns for the interface between the low-level register access and the more high-level stuff: you can either use a "syscon" driver that just exports a struct regmap and that gets referenced from other drivers using a phandle in their device nodes, or you have a driver in drivers/soc that exports a somewhat higher-level interface and comes with its own header file that gets included by other drivers. At the moment, the syscon/regmap variant can only be used once device drivers are loaded, but there is some broad agreement that it should be changed to allow calling syscon_regmap_lookup_by_phandle() at early boot using just DT accessors.
Arnd
RFC 1/4 ARM: tegra: Move SoC drivers to drivers/soc/tegra
Quoted 15 lines · Arnd Bergmann
Quoted 6 lines · On Saturday 28 June 2014 22:40:26 Thierry Reding wrote:
Quoted 6 lines
Quoted 6 lines
pmc.cimplements various routines to access the power management controller, some of which is needed by suspend/resume, some of it is needed by SMP.powergate.cimplements a subset of the PMC that needs to be exported to drivers to enable power partitions on the SoC. I'm not aware of subsystems that deal with this kind of driver.Quoted 7 lines
Quoted 1 line
Please see above.
Like I said, I don't see what business suspend/resume related code has in
drivers/power. What we're talking about here really is functionality very specific to Tegra. Also some of that code needs to be run at very early points in the boot process, so we can't reasonably turn it into a proper driver anyway.
Quoted 4 lines
I believe the
powergate.cstuff can be changed intopm_domaincode, but we don't have a good subsystem with generic DT bindings yet, so that may need some more groundwork first.drivers/poweror a subdirectory of that may end up being the right place though.
Last time I checked the PM domain code didn't seem like a good fit. I'll go recheck and see if I can make it work.
One minor issue with putting the driver in drivers/power is that that directory is only built when POWER_SUPPLY is selected. And since this isn't really a power supply driver at all, either we need to change the drivers/Makefile to descend unconditionally or we need to find another home.
I'll see if I can come up with yet another generic binding for this in an attempt to move this out of arch/arm/mach-tegra...
Quoted 12 lines
Quoted 8 lines
Also, the real win we get from moving code out into
drivers/is if we can provide a common framework for them. I don't see how we can possibly do that for this code since there simply isn't enough commonality between SoCs. At the same time we now have a situation where both 32-bit and 64-bit variants of some SoCs share some of the same hardware at the very low level and since we don't have mach-* directories for 64-bit ARM and shouldn't be duplicating code either, we need to find a new home for this type of code.drivers/socseemed to fit perfectly well.For the low-level stuff yes, but I agree with Santosh there needs to be some more work trying to split out individual high-level drivers.
Quoted 10 lines
There are two common patterns for the interface between the low-level register access and the more high-level stuff: you can either use a "syscon" driver that just exports a struct regmap and that gets referenced from other drivers using a phandle in their device nodes, or you have a driver in
drivers/socthat exports a somewhat higher-level interface and comes with its own header file that gets included by other drivers. At the moment, the syscon/regmap variant can only be used once device drivers are loaded, but there is some broad agreement that it should be changed to allow callingsyscon_regmap_lookup_by_phandle()at early boot using just DT accessors.
Note that we already have all these drivers and they do work for earlier Tegra generations. My attempt to move these out of arch/arm/mach-tegra is merely about being able to share them with upcoming 64-bit variants. So it's not about adding new functionality but rather about keeping the existing level of functionality on 64-bit.
I'm not a fan of the syscon/regmap approach at all and the existing drivers use a higher-level API already, so I think we're going to stick with that.
Thierry
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 819 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20140630/bfb33e52/attachment.sig>
RFC 1/4 ARM: tegra: Move SoC drivers to drivers/soc/tegra
Quoted 25 lines · Thierry Reding
Quoted 13 lines · Arnd Bergmann
Quoted 8 lines · On Saturday 28 June 2014 22:40:26 Thierry Reding wrote:
Also, the real win we get from moving code out into
drivers/is if we can provide a common framework for them. I don't see how we can possibly do that for this code since there simply isn't enough commonality between SoCs. At the same time we now have a situation where both 32-bit and 64-bit variants of some SoCs share some of the same hardware at the very low level and since we don't have mach-* directories for 64-bit ARM and shouldn't be duplicating code either, we need to find a new home for this type of code.drivers/socseemed to fit perfectly well.For the low-level stuff yes, but I agree with Santosh there needs to be some more work trying to split out individual high-level drivers.
Quoted 10 lines
There are two common patterns for the interface between the low-level register access and the more high-level stuff: you can either use a "syscon" driver that just exports a struct regmap and that gets referenced from other drivers using a phandle in their device nodes, or you have a driver in
drivers/socthat exports a somewhat higher-level interface and comes with its own header file that gets included by other drivers. At the moment, the syscon/regmap variant can only be used once device drivers are loaded, but there is some broad agreement that it should be changed to allow callingsyscon_regmap_lookup_by_phandle()at early boot using just DT accessors.
Quoted 5 lines
Note that we already have all these drivers and they do work for earlier Tegra generations. My attempt to move these out of
arch/arm/mach-tegrais merely about being able to share them with upcoming 64-bit variants. So it's not about adding new functionality but rather about keeping the existing level of functionality on 64-bit.
Only that for arm64 we try to do things slightly differently and not because we just like to but because we want better standardisation across SoCs. One example is the booting protocol. Another example, you don't get some early initcalls for your SoC (no machine descriptor). The hardware should be configured by firmware in such a way that it boots at least up to arch_initcall() level (ideally, we should move anything to device_initcall() but it's not always easy).
Quoted 3 lines
I'm not a fan of the syscon/regmap approach at all and the existing drivers use a higher-level API already, so I think we're going to stick with that.
It's not about whether you are a fan of it or not but whether we can get more code sharing across several SoCs and not just between tegra arm32 and arm64 versions.
Signature · 1 line
Catalin
RFC 1/4 ARM: tegra: Move SoC drivers to drivers/soc/tegra
Quoted 32 lines · Catalin Marinas
Quoted 25 lines · Thierry Reding
Quoted 13 lines · Arnd Bergmann
Quoted 8 lines · On Saturday 28 June 2014 22:40:26 Thierry Reding wrote:
Also, the real win we get from moving code out into
drivers/is if we can provide a common framework for them. I don't see how we can possibly do that for this code since there simply isn't enough commonality between SoCs. At the same time we now have a situation where both 32-bit and 64-bit variants of some SoCs share some of the same hardware at the very low level and since we don't have mach-* directories for 64-bit ARM and shouldn't be duplicating code either, we need to find a new home for this type of code.drivers/socseemed to fit perfectly well.For the low-level stuff yes, but I agree with Santosh there needs to be some more work trying to split out individual high-level drivers.
Quoted 10 lines
There are two common patterns for the interface between the low-level register access and the more high-level stuff: you can either use a "syscon" driver that just exports a struct regmap and that gets referenced from other drivers using a phandle in their device nodes, or you have a driver in
drivers/socthat exports a somewhat higher-level interface and comes with its own header file that gets included by other drivers. At the moment, the syscon/regmap variant can only be used once device drivers are loaded, but there is some broad agreement that it should be changed to allow callingsyscon_regmap_lookup_by_phandle()at early boot using just DT accessors.Quoted 5 lines
Note that we already have all these drivers and they do work for earlier Tegra generations. My attempt to move these out of
arch/arm/mach-tegrais merely about being able to share them with upcoming 64-bit variants. So it's not about adding new functionality but rather about keeping the existing level of functionality on 64-bit.
Quoted 7 lines
Only that for arm64 we try to do things slightly differently and not because we just like to but because we want better standardisation across SoCs. One example is the booting protocol. Another example, you don't get some early initcalls for your SoC (no machine descriptor). The hardware should be configured by firmware in such a way that it boots at least up to
arch_initcall()level (ideally, we should move anything todevice_initcall()but it's not always easy).
Well, one of the problems on Tegra is that we need part of the PMC to power up CPUs. There's no firmware that could do this for us. We need also access to another block called flow controller. Both of those drivers need to be available very early for things to work. At the same time the driver exposes control over power domains. So while we possibly can push CPU bringup/teardown to firmware for ARM64, we can't do the same for the other parts of the PMC, so we end up with a weird kind of driver.
Parts of it can't register with the driver model because it isn't available that early, and at the same time we need to register parts only later because they require the driver model.
Quoted 7 lines
Quoted 3 lines
I'm not a fan of the syscon/regmap approach at all and the existing drivers use a higher-level API already, so I think we're going to stick with that.
It's not about whether you are a fan of it or not but whether we can get more code sharing across several SoCs and not just between tegra arm32 and arm64 versions.
syscon by definition cannot be shared between different SoCs.
Thierry
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 819 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20140630/a1391015/attachment.sig>
RFC 1/4 ARM: tegra: Move SoC drivers to drivers/soc/tegra
Quoted 50 lines · Thierry Reding
Quoted 32 lines · Catalin Marinas
Quoted 25 lines · Thierry Reding
Quoted 13 lines · Arnd Bergmann
Quoted 8 lines · On Saturday 28 June 2014 22:40:26 Thierry Reding wrote:
Also, the real win we get from moving code out into
drivers/is if we can provide a common framework for them. I don't see how we can possibly do that for this code since there simply isn't enough commonality between SoCs. At the same time we now have a situation where both 32-bit and 64-bit variants of some SoCs share some of the same hardware at the very low level and since we don't have mach-* directories for 64-bit ARM and shouldn't be duplicating code either, we need to find a new home for this type of code.drivers/socseemed to fit perfectly well.For the low-level stuff yes, but I agree with Santosh there needs to be some more work trying to split out individual high-level drivers.
Quoted 10 lines
There are two common patterns for the interface between the low-level register access and the more high-level stuff: you can either use a "syscon" driver that just exports a struct regmap and that gets referenced from other drivers using a phandle in their device nodes, or you have a driver in
drivers/socthat exports a somewhat higher-level interface and comes with its own header file that gets included by other drivers. At the moment, the syscon/regmap variant can only be used once device drivers are loaded, but there is some broad agreement that it should be changed to allow callingsyscon_regmap_lookup_by_phandle()at early boot using just DT accessors.Quoted 5 lines
Note that we already have all these drivers and they do work for earlier Tegra generations. My attempt to move these out of
arch/arm/mach-tegrais merely about being able to share them with upcoming 64-bit variants. So it's not about adding new functionality but rather about keeping the existing level of functionality on 64-bit.Quoted 7 lines
Only that for arm64 we try to do things slightly differently and not because we just like to but because we want better standardisation across SoCs. One example is the booting protocol. Another example, you don't get some early initcalls for your SoC (no machine descriptor). The hardware should be configured by firmware in such a way that it boots at least up to
arch_initcall()level (ideally, we should move anything todevice_initcall()but it's not always easy).Well, one of the problems on Tegra is that we need part of the PMC to power up CPUs. There's no firmware that could do this for us. We need also access to another block called flow controller. Both of those drivers need to be available very early for things to work. At the same time the driver exposes control over power domains. So while we possibly can push CPU bringup/teardown to firmware for ARM64, we can't do the same for the other parts of the PMC, so we end up with a weird kind of driver.
Quoted 3 lines
Parts of it can't register with the driver model because it isn't available that early, and at the same time we need to register parts only later because they require the driver model.
That sounds familiar and that's exactly the problem, and that's a problem that won't disappear by just moving code around directories (hey, it is not that we have not tried =)), as you (and I) know very well:
https://lkml.org/lkml/2013/8/16/399
http://lists.infradead.org/pipermail/linux-arm-kernel/2013-August/190067.html
Either a common way of dealing with this early CPU bring-up code is implemented (but it can't be platform specific otherwise we are back to square one) or we decide that this code does not belong in the kernel and should be abstracted away.
And I think that most of the early bring up issues are just related to powering-up/resetting a cpu for it to be booted, probably that's the abstraction we should be focusing on, because it should just require poking a bunch of registers to kickstart a CPU, no more than that, FW should be able to deal with that and that's yet another reason behind PSCI design.
I am not convinced that the early device model would be useful for any other reason, that's why shoehorning kernel changes in the current driver model just to bring up secondaries is not something I consider useful and proper, in the first place, but I am happy to hear other possible concerns.
Lorenzo
Quoted 18 lines
Quoted 8 lines
Quoted 4 lines
I'm not a fan of the syscon/regmap approach at all and the existing drivers use a higher-level API already, so I think we're going to stick with that.
It's not about whether you are a fan of it or not but whether we can get more code sharing across several SoCs and not just between tegra arm32 and arm64 versions.
syscon by definition cannot be shared between different SoCs.
Thierry
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel at lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
RFC 1/4 ARM: tegra: Move SoC drivers to drivers/soc/tegra
Quoted 59 lines · Lorenzo Pieralisi
Quoted 50 lines · Thierry Reding
Quoted 32 lines · Catalin Marinas
Quoted 25 lines · Thierry Reding
Quoted 13 lines · Arnd Bergmann
Quoted 8 lines · On Saturday 28 June 2014 22:40:26 Thierry Reding wrote:
Also, the real win we get from moving code out into
drivers/is if we can provide a common framework for them. I don't see how we can possibly do that for this code since there simply isn't enough commonality between SoCs. At the same time we now have a situation where both 32-bit and 64-bit variants of some SoCs share some of the same hardware at the very low level and since we don't have mach-* directories for 64-bit ARM and shouldn't be duplicating code either, we need to find a new home for this type of code.drivers/socseemed to fit perfectly well.For the low-level stuff yes, but I agree with Santosh there needs to be some more work trying to split out individual high-level drivers.
Quoted 10 lines
There are two common patterns for the interface between the low-level register access and the more high-level stuff: you can either use a "syscon" driver that just exports a struct regmap and that gets referenced from other drivers using a phandle in their device nodes, or you have a driver in
drivers/socthat exports a somewhat higher-level interface and comes with its own header file that gets included by other drivers. At the moment, the syscon/regmap variant can only be used once device drivers are loaded, but there is some broad agreement that it should be changed to allow callingsyscon_regmap_lookup_by_phandle()at early boot using just DT accessors.Quoted 5 lines
Note that we already have all these drivers and they do work for earlier Tegra generations. My attempt to move these out of
arch/arm/mach-tegrais merely about being able to share them with upcoming 64-bit variants. So it's not about adding new functionality but rather about keeping the existing level of functionality on 64-bit.Quoted 7 lines
Only that for arm64 we try to do things slightly differently and not because we just like to but because we want better standardisation across SoCs. One example is the booting protocol. Another example, you don't get some early initcalls for your SoC (no machine descriptor). The hardware should be configured by firmware in such a way that it boots at least up to
arch_initcall()level (ideally, we should move anything todevice_initcall()but it's not always easy).Well, one of the problems on Tegra is that we need part of the PMC to power up CPUs. There's no firmware that could do this for us. We need also access to another block called flow controller. Both of those drivers need to be available very early for things to work. At the same time the driver exposes control over power domains. So while we possibly can push CPU bringup/teardown to firmware for ARM64, we can't do the same for the other parts of the PMC, so we end up with a weird kind of driver.
Quoted 3 lines
Parts of it can't register with the driver model because it isn't available that early, and at the same time we need to register parts only later because they require the driver model.
That sounds familiar and that's exactly the problem, and that's a problem that won't disappear by just moving code around directories (hey, it is not that we have not tried =)), as you (and I) know very well:
Quoted 6 lines
https://lkml.org/lkml/2013/8/16/399
http://lists.infradead.org/pipermail/linux-arm-kernel/2013-August/190067.htmlEither a common way of dealing with this early CPU bring-up code is implemented (but it can't be platform specific otherwise we are back to square one)
I prototyped this based on an OF init table (much like IRQCHIP_DECLARE or CLOCKSOURCE_OF_DECLARE) that's run early in the boot process (at the very end of setup_arch()).
Quoted 8 lines
or we decide that this code does not belong in the kernel and should be abstracted away.
And I think that most of the early bring up issues are just related to powering-up/resetting a cpu for it to be booted, probably that's the abstraction we should be focusing on, because it should just require poking a bunch of registers to kickstart a CPU, no more than that, FW should be able to deal with that and that's yet another reason behind PSCI design.
Right, I agree that if we can push that into PSCI that would be great (provided there's an open-source implementation of PSCI). But for 32-bit ARM that's no longer a viable option, so we're pretty much stuck with what we have.
Quoted 5 lines
I am not convinced that the early device model would be useful for any other reason, that's why shoehorning kernel changes in the current driver model just to bring up secondaries is not something I consider useful and proper, in the first place, but I am happy to hear other possible concerns.
I agree, but we still want to support early and driver model code in the same source file to avoid duplication. What I prototyped is a driver that's initialized to a bare minimum very early on and then takes over when the driver model is up (using regular driver .probe()). I hope to get the patches cleaned up and send them out tomorrow. If you want I can add you on Cc.
Thierry
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 836 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20140630/9c8f3bdf/attachment.sig>
RFC 1/4 ARM: tegra: Move SoC drivers to drivers/soc/tegra
Quoted 9 lines · Thierry Reding
Quoted 5 lines · Lorenzo Pieralisi
And I think that most of the early bring up issues are just related to powering-up/resetting a cpu for it to be booted, probably that's the abstraction we should be focusing on, because it should just require poking a bunch of registers to kickstart a CPU, no more than that, FW should be able to deal with that and that's yet another reason behind PSCI design.
Right, I agree that if we can push that into PSCI that would be great (provided there's an open-source implementation of PSCI).
At least one (BSD-style license):
https://github.com/ARM-software/arm-trusted-firmware
There are also some patches for U-Boot (only covering secondary CPU booting for now and not merged yet).
Signature · 1 line
Catalin
RFC 1/4 ARM: tegra: Move SoC drivers to drivers/soc/tegra
Quoted 11 lines · Catalin Marinas
Quoted 9 lines · Thierry Reding
Quoted 5 lines · Lorenzo Pieralisi
And I think that most of the early bring up issues are just related to powering-up/resetting a cpu for it to be booted, probably that's the abstraction we should be focusing on, because it should just require poking a bunch of registers to kickstart a CPU, no more than that, FW should be able to deal with that and that's yet another reason behind PSCI design.
Right, I agree that if we can push that into PSCI that would be great (provided there's an open-source implementation of PSCI).
Quoted 6 lines
At least one (BSD-style license):
https://github.com/ARM-software/arm-trusted-firmware
There are also some patches for U-Boot (only covering secondary CPU booting for now and not merged yet).
Are the U-Boot patches:
a) Patches to make U-Boot provide a PSCI implementation.
b) Patches to make U-Boot use PSCI as a client.
If you have a link or patch subject to search for, that'd be interesting. Thanks.
RFC 1/4 ARM: tegra: Move SoC drivers to drivers/soc/tegra
Quoted 19 lines · Stephen Warren
Quoted 11 lines · Catalin Marinas
Quoted 9 lines · Thierry Reding
Quoted 5 lines · Lorenzo Pieralisi
And I think that most of the early bring up issues are just related to powering-up/resetting a cpu for it to be booted, probably that's the abstraction we should be focusing on, because it should just require poking a bunch of registers to kickstart a CPU, no more than that, FW should be able to deal with that and that's yet another reason behind PSCI design.
Right, I agree that if we can push that into PSCI that would be great (provided there's an open-source implementation of PSCI).
Quoted 6 lines
At least one (BSD-style license):
https://github.com/ARM-software/arm-trusted-firmware
There are also some patches for U-Boot (only covering secondary CPU booting for now and not merged yet).
Quoted 8 lines
Are the U-Boot patches:
a) Patches to make U-Boot provide a PSCI implementation.
b) Patches to make U-Boot use PSCI as a client.
If you have a link or patch subject to search for, that'd be interesting.
It's (a). See the base stuff:
https://git.kernel.org/cgit/linux/kernel/git/maz/u-boot.git/log/?h=wip/psci-v4
and Allwinner specifics:
https://git.kernel.org/cgit/linux/kernel/git/maz/u-boot.git/log/?h=wip/psci-v4-a20
Signature · 1 line
Catalin
RFC 1/4 ARM: tegra: Move SoC drivers to drivers/soc/tegra
In reply to Arnd BergmannQuoted 15 lines · Arnd Bergmann
Quoted 6 lines · On Saturday 28 June 2014 22:40:26 Thierry Reding wrote:
Quoted 6 lines
Quoted 6 lines
pmc.cimplements various routines to access the power management controller, some of which is needed by suspend/resume, some of it is needed by SMP.powergate.cimplements a subset of the PMC that needs to be exported to drivers to enable power partitions on the SoC. I'm not aware of subsystems that deal with this kind of driver.Quoted 7 lines
Quoted 1 line
Please see above.
Like I said, I don't see what business suspend/resume related code has in
drivers/power. What we're talking about here really is functionality very specific to Tegra. Also some of that code needs to be run at very early points in the boot process, so we can't reasonably turn it into a proper driver anyway.
Quoted 4 lines
I believe the
powergate.cstuff can be changed intopm_domaincode, but we don't have a good subsystem with generic DT bindings yet, so that may need some more groundwork first.drivers/poweror a subdirectory of that may end up being the right place though.
So I ended up implementing the powergates as generic_pm_domain, but that breaks existing drivers currently. The reason is that generic_pm_domains are automatically turned off on suspend and turned back on on resume. On Tegra if a partition is powered off then the whole module looses state and would need to be completely reinitialized. None of the drivers currently support that and I'm also not sure if it's really what we want since it means for example redetecting links and reenumerating devices on PCI, or probing display outputs in DRM. That's going to take a lot of time and may not be appropriate for suspend-to-RAM.
Unfortunately I haven't found a way to force a domain to remain powered during suspend/resume.
Thierry
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 836 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20140630/68ea991b/attachment-0001.sig>
RFC 1/4 ARM: tegra: Move SoC drivers to drivers/soc/tegra
Quoted 33 lines · Thierry Reding
* PGP Signed by an unknown key
Quoted 15 lines · Arnd Bergmann
Quoted 6 lines · On Saturday 28 June 2014 22:40:26 Thierry Reding wrote:
Quoted 6 lines
Quoted 6 lines
pmc.cimplements various routines to access the power management controller, some of which is needed by suspend/resume, some of it is needed by SMP.powergate.cimplements a subset of the PMC that needs to be exported to drivers to enable power partitions on the SoC. I'm not aware of subsystems that deal with this kind of driver.Quoted 7 lines
Quoted 1 line
Please see above.
Like I said, I don't see what business suspend/resume related code has in
drivers/power. What we're talking about here really is functionality very specific to Tegra. Also some of that code needs to be run at very early points in the boot process, so we can't reasonably turn it into a proper driver anyway.Quoted 4 lines
I believe the
powergate.cstuff can be changed intopm_domaincode, but we don't have a good subsystem with generic DT bindings yet, so that may need some more groundwork first.drivers/poweror a subdirectory of that may end up being the right place though.So I ended up implementing the powergates as
generic_pm_domain, but that breaks existing drivers currently. The reason is thatgeneric_pm_domainsare automatically turned off on suspend and turned back on on resume. On Tegra if a partition is powered off then the whole module looses state and would need to be completely reinitialized. None of the drivers currently support that and I'm also not sure if it's really what we want since it means for example redetecting links and reenumerating devices on PCI, or probing display outputs in DRM. That's going to take a lot of time and may not be appropriate for suspend-to-RAM.
Quoted 2 lines
Unfortunately I haven't found a way to force a domain to remain powered during suspend/resume.
If we make power off a NOP until LP0 gets implemented? Then device state will have to be saved/restored.
Cheers,
Peter.
RFC 1/4 ARM: tegra: Move SoC drivers to drivers/soc/tegra
In reply to Arnd Bergmann[ Gee, I had completely missed this thread because nobody bothered to cc me. Seems to be standard procedure on 64-bit these days. :( ]
Quoted 32 lines · Arnd Bergmann
Quoted 6 lines · On Saturday 28 June 2014 22:40:26 Thierry Reding wrote:
Quoted 6 lines
Quoted 6 lines
pmc.cimplements various routines to access the power management controller, some of which is needed by suspend/resume, some of it is needed by SMP.powergate.cimplements a subset of the PMC that needs to be exported to drivers to enable power partitions on the SoC. I'm not aware of subsystems that deal with this kind of driver.Quoted 7 lines
Quoted 1 line
Please see above.
Like I said, I don't see what business suspend/resume related code has in
drivers/power. What we're talking about here really is functionality very specific to Tegra. Also some of that code needs to be run at very early points in the boot process, so we can't reasonably turn it into a proper driver anyway.I believe the
powergate.cstuff can be changed intopm_domaincode, but we don't have a good subsystem with generic DT bindings yet, so that may need some more groundwork first.drivers/poweror a subdirectory of that may end up being the right place though.Quoted 8 lines
Also, the real win we get from moving code out into
drivers/is if we can provide a common framework for them. I don't see how we can possibly do that for this code since there simply isn't enough commonality between SoCs. At the same time we now have a situation where both 32-bit and 64-bit variants of some SoCs share some of the same hardware at the very low level and since we don't have mach-* directories for 64-bit ARM and shouldn't be duplicating code either, we need to find a new home for this type of code.drivers/socseemed to fit perfectly well.For the low-level stuff yes, but I agree with Santosh there needs to be some more work trying to split out individual high-level drivers.
Quoted 10 lines
There are two common patterns for the interface between the low-level register access and the more high-level stuff: you can either use a "syscon" driver that just exports a struct regmap and that gets referenced from other drivers using a phandle in their device nodes, or you have a driver in
drivers/socthat exports a somewhat higher-level interface and comes with its own header file that gets included by other drivers. At the moment, the syscon/regmap variant can only be used once device drivers are loaded, but there is some broad agreement that it should be changed to allow callingsyscon_regmap_lookup_by_phandle()at early boot using just DT accessors.
I'd strongly prefer to NOT tie this into DT and keep it as in-kernel implementation until we know more what a common subsystem might look like, if any.
If we keep it only in the kernel, then we're free to change it as needed. If we tie it into DT/syscon, then we get stick with stable-only ABIs from day one. That doesn't seem like a good idea.
-Olof
RFC 1/4 ARM: tegra: Move SoC drivers to drivers/soc/tegra
Quoted 48 lines · Olof Johansson
[ Gee, I had completely missed this thread because nobody bothered to cc me. Seems to be standard procedure on 64-bit these days. :( ]
Quoted 32 lines · Arnd Bergmann
Quoted 6 lines · On Saturday 28 June 2014 22:40:26 Thierry Reding wrote:
Quoted 6 lines
Quoted 6 lines
pmc.cimplements various routines to access the power management controller, some of which is needed by suspend/resume, some of it is needed by SMP.powergate.cimplements a subset of the PMC that needs to be exported to drivers to enable power partitions on the SoC. I'm not aware of subsystems that deal with this kind of driver.Quoted 7 lines
Quoted 1 line
Please see above.
Like I said, I don't see what business suspend/resume related code has in
drivers/power. What we're talking about here really is functionality very specific to Tegra. Also some of that code needs to be run at very early points in the boot process, so we can't reasonably turn it into a proper driver anyway.I believe the
powergate.cstuff can be changed intopm_domaincode, but we don't have a good subsystem with generic DT bindings yet, so that may need some more groundwork first.drivers/poweror a subdirectory of that may end up being the right place though.Quoted 8 lines
Also, the real win we get from moving code out into
drivers/is if we can provide a common framework for them. I don't see how we can possibly do that for this code since there simply isn't enough commonality between SoCs. At the same time we now have a situation where both 32-bit and 64-bit variants of some SoCs share some of the same hardware at the very low level and since we don't have mach-* directories for 64-bit ARM and shouldn't be duplicating code either, we need to find a new home for this type of code.drivers/socseemed to fit perfectly well.For the low-level stuff yes, but I agree with Santosh there needs to be some more work trying to split out individual high-level drivers.
Quoted 10 lines
There are two common patterns for the interface between the low-level register access and the more high-level stuff: you can either use a "syscon" driver that just exports a struct regmap and that gets referenced from other drivers using a phandle in their device nodes, or you have a driver in
drivers/socthat exports a somewhat higher-level interface and comes with its own header file that gets included by other drivers. At the moment, the syscon/regmap variant can only be used once device drivers are loaded, but there is some broad agreement that it should be changed to allow callingsyscon_regmap_lookup_by_phandle()at early boot using just DT accessors.
Quoted 7 lines
I'd strongly prefer to NOT tie this into DT and keep it as in-kernel implementation until we know more what a common subsystem might look like, if any.
If we keep it only in the kernel, then we're free to change it as needed. If we tie it into DT/syscon, then we get stick with stable-only ABIs from day one. That doesn't seem like a good idea.
There are two sides to keeping to an in-kernel API too: it may seem like we're free to change this at will and aren't subject to a stable ABI. However that's not entirely accurate.
Assume we don't put any information about a feature into DT but use an in-kernel API only. Once we've come up with a good way to represent that in DT and have a generic framework that we can use, we'll most likely still need to keep around the old API in the kernel to make sure the kernel still works with a DT that doesn't have nodes and/or properties for the new binding.
So the question arises: at that point is it really worth using a DT binding? Since we already have an API that works, why bother coming up with a new one? Especially if we can't get rid of the one we already have anyway?
Thierry
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 836 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20140716/89883d14/attachment.sig>
RFC 1/4 ARM: tegra: Move SoC drivers to drivers/soc/tegra
In reply to Olof JohanssonQuoted 2 lines · Olof Johansson
[ Gee, I had completely missed this thread because nobody bothered to cc me. Seems to be standard procedure on 64-bit these days. :( ]
Just to clarify this point, as per prior agreement I'm expecting the arm-soc guys to help reviewing/merging arm64-soc as well, even though there are no arch/arm64/{mach,plat}-* directories. That means that arm-soc folks should also be cc'ed on such patches.
However, the "ARM SUB-ARCHITECTURES" MAINTAINERS entry does not mention arm at kernel.org (neither Olof nor Arnd). Was this not meant as an arm-soc email alias?
Signature · 1 line
Catalin
RFC 1/4 ARM: tegra: Move SoC drivers to drivers/soc/tegra
Quoted 4 lines · Catalin Marinas
Quoted 2 lines · Olof Johansson
[ Gee, I had completely missed this thread because nobody bothered to cc me. Seems to be standard procedure on 64-bit these days. :( ]
Quoted 8 lines
Just to clarify this point, as per prior agreement I'm expecting the arm-soc guys to help reviewing/merging arm64-soc as well, even though there are no
arch/arm64/{mach,plat}-*directories. That means that arm-soc folks should also be cc'ed on such patches.However, the "ARM SUB-ARCHITECTURES"
MAINTAINERSentry does not mention arm at kernel.org (neither Olof nor Arnd). Was this not meant as an arm-soc email alias?
Yes, however we've been reluctant to add it because we don't want people to post patches directly to us, we mostly expect maintainers to send pull request and/or direct patches there.
We can do it and add annotation to not send patches directly there. I'll post a patch for that update.
-Olof
RFC 1/4 ARM: tegra: Move SoC drivers to drivers/soc/tegra
In reply to Santosh ShilimkarQuoted 10 lines · On Saturday 28 June 2014 13:15:09 Santosh Shilimkar wrote:
Quoted 6 lines
Quoted 2 lines
For SMP boot, ARMv8 expecting to have either PSCI based implementation or device tree based boot scheme. you can move towards that model if possible.
But we also have the code for SMP on 32-bit ARM. Should that remain in
arch/arm/mach-tegraor can it move todrivers/soc/tegra?You answered yourself. I don't see any point moving such a code to drivers which is really SMP bring up code for ARM 32 bit. For ARM 64 bit, as outline by maintainers (Catalin, Arnd), you should use PSCI or DT based boot scheme.
I was hoping that one day we could unify the SMP bootup code with the cpuidle infrastructure, as a lot of the underlying functions are shared on the majority of SoCs. I have no plans to work on that myself though, and it would have to be agreed on by the cpuidle maintainers.
For ARM64, the hope was indeed to use PSCI for all SoCs. I just have no idea how that would be enforced for mobile SoCs that get shipped to system integrators with an bootloader and kernel tree that doesn't even get reviewed anywhere first.
Arnd
RFC 1/4 ARM: tegra: Move SoC drivers to drivers/soc/tegra
Quoted 12 lines · Arnd Bergmann
Quoted 10 lines · On Saturday 28 June 2014 13:15:09 Santosh Shilimkar wrote:
Quoted 6 lines
Quoted 2 lines
For SMP boot, ARMv8 expecting to have either PSCI based implementation or device tree based boot scheme. you can move towards that model if possible.
But we also have the code for SMP on 32-bit ARM. Should that remain in
arch/arm/mach-tegraor can it move todrivers/soc/tegra?You answered yourself. I don't see any point moving such a code to drivers which is really SMP bring up code for ARM 32 bit. For ARM 64 bit, as outline by maintainers (Catalin, Arnd), you should use PSCI or DT based boot scheme.
Quoted 4 lines
I was hoping that one day we could unify the SMP bootup code with the cpuidle infrastructure, as a lot of the underlying functions are shared on the majority of SoCs. I have no plans to work on that myself though, and it would have to be agreed on by the cpuidle maintainers.
If you look at the arm64 implementation and Lorenzo's generic cpuidle code, that's not far off. Basically for arm64 we have a cpu_operations structure which implements boot, suspend, disable etc., placing SMP booting, hotplug and cpuidle together.
While PSCI is the (strongly) recommended way, the current structure allows for other implementations and spin-table is an example (though this lacks any form of parking CPUs back to firmware). What I don't want to see is every platform implementing its own booting method for no good reasons and especially when functionality is duplicated with other platforms.
In the tegra case, I suppose the arm32 implementation assumes Linux running in secure mode. On arm64 we don't support this (though it may work for certain configurations) and once you realise you need SMC calls for CPU up/down/suspend, I would rather standardise on PSCI (unless a better standard appears ;)).
Quoted 4 lines
For ARM64, the hope was indeed to use PSCI for all SoCs. I just have no idea how that would be enforced for mobile SoCs that get shipped to system integrators with an bootloader and kernel tree that doesn't even get reviewed anywhere first.
We can't enforce this but at least with enough "marketing" support, we can sell this as a good idea. For example, if one implements PSCI you get (generic) cpuidle for free (just DT bindings). That's definitely not enough and other things like a comprehensive validation suite for PSCI also helps (currently ARM only works on bare metal but it would be good to have a kernel-based test suite as well).
Signature · 1 line
Catalin
RFC 1/4 ARM: tegra: Move SoC drivers to drivers/soc/tegra
In reply to Arnd BergmannQuoted 17 lines · Arnd Bergmann
Quoted 10 lines · On Saturday 28 June 2014 13:15:09 Santosh Shilimkar wrote:
Quoted 6 lines
Quoted 2 lines
For SMP boot, ARMv8 expecting to have either PSCI based implementation or device tree based boot scheme. you can move towards that model if possible.
But we also have the code for SMP on 32-bit ARM. Should that remain in
arch/arm/mach-tegraor can it move todrivers/soc/tegra?You answered yourself. I don't see any point moving such a code to drivers which is really SMP bring up code for ARM 32 bit. For ARM 64 bit, as outline by maintainers (Catalin, Arnd), you should use PSCI or DT based boot scheme.
I was hoping that one day we could unify the SMP bootup code with the cpuidle infrastructure, as a lot of the underlying functions are shared on the majority of SoCs. I have no plans to work on that myself though, and it would have to be agreed on by the cpuidle maintainers.
Quoted 4 lines
For ARM64, the hope was indeed to use PSCI for all SoCs. I just have no idea how that would be enforced for mobile SoCs that get shipped to system integrators with an bootloader and kernel tree that doesn't even get reviewed anywhere first.
Indeed, I'm not sure that our downstream kernels use PSCI. There has been some discussion of that, but I'm not sure that it actually happened at least on Tegra132. Even if we do use PSCI, it's likely to be implemented in a binary blob firmware at the moment, which still seems less palatable to me than putting the code directly into the kernel. If the upstream mandate is "use PSCI or don't upstream", then given my and Thierry's limited bandwidth (we are after all only human), we likely can't port the kernel and write a whole new upstream-specific firmware just to provide PSCI, so this kinda makes the choice for us...
RFC 1/4 ARM: tegra: Move SoC drivers to drivers/soc/tegra
In reply to Thierry RedingQuoted 10 lines · Thierry Reding
Quoted 8 lines · Santosh Shilimkar
Quoted 5 lines · Thierry Reding
rename {arch/arm/mach-tegra => drivers/soc/tegra}/cpuidle-tegra114.c (100%) rename {arch/arm/mach-tegra => drivers/soc/tegra}/cpuidle-tegra20.c (100%) rename {arch/arm/mach-tegra => drivers/soc/tegra}/cpuidle-tegra30.c (100%) rename {arch/arm/mach-tegra => drivers/soc/tegra}/cpuidle.c (100%) rename {arch/arm/mach-tegra => drivers/soc/tegra}/cpuidle.h (91%)This should go into
drivers/idle/*. if you have dependencies, please sort them out.
Quoted 7 lines
What exactly is the difference between
drivers/idleanddrivers/cpuidle? There's anintel_idledriver indrivers/idlethat includescpuidle.hand registers with that subsystem. But there's also ani7300_idledriver that doesn't.
drivers/cpuidleseems like a better fit. I'll look into moving the code there.
Actually, please look at Lorenzo's generic cpuidle series. Basically most cpuidle drivers simply define some C states and call the corresponding platform back-end. On arm64, we aim to separate the back-end in the cpu_operations structure and just have a generic cpuidle driver with states defined in the DT (and passed to the back-end).
As for the back-end, what about using PSCI?
Quoted 8 lines
Quoted 4 lines
Quoted 3 lines
rename {arch/arm/mach-tegra => drivers/soc/tegra}/reset-handler.S (100%) rename {arch/arm/mach-tegra => drivers/soc/tegra}/reset.c (100%) rename {arch/arm/mach-tegra => drivers/soc/tegra}/reset.h (97%)subsystem:
drivers/power/reset/
drivers/power/resetseems to be for drivers that register functions to reset a board. The above code for Tegra doesn't do that. Rather it sets up the reset handlers for secondary CPUs and for suspend/resume.
PSCI again?
Signature · 1 line
Catalin
RFC 1/4 ARM: tegra: Move SoC drivers to drivers/soc/tegra
Quoted 30 lines · Catalin Marinas
Quoted 10 lines · Thierry Reding
Quoted 8 lines · Santosh Shilimkar
Quoted 5 lines · Thierry Reding
rename {arch/arm/mach-tegra => drivers/soc/tegra}/cpuidle-tegra114.c (100%) rename {arch/arm/mach-tegra => drivers/soc/tegra}/cpuidle-tegra20.c (100%) rename {arch/arm/mach-tegra => drivers/soc/tegra}/cpuidle-tegra30.c (100%) rename {arch/arm/mach-tegra => drivers/soc/tegra}/cpuidle.c (100%) rename {arch/arm/mach-tegra => drivers/soc/tegra}/cpuidle.h (91%)This should go into
drivers/idle/*. if you have dependencies, please sort them out.Quoted 7 lines
What exactly is the difference between
drivers/idleanddrivers/cpuidle? There's anintel_idledriver indrivers/idlethat includescpuidle.hand registers with that subsystem. But there's also ani7300_idledriver that doesn't.
drivers/cpuidleseems like a better fit. I'll look into moving the code there.Actually, please look at Lorenzo's generic cpuidle series. Basically most cpuidle drivers simply define some C states and call the corresponding platform back-end. On arm64, we aim to separate the back-end in the
cpu_operationsstructure and just have a generic cpuidle driver with states defined in the DT (and passed to the back-end).As for the back-end, what about using PSCI?
Quoted 3 lines
Quoted 3 lines
Quoted 3 lines
rename {arch/arm/mach-tegra => drivers/soc/tegra}/reset-handler.S (100%) rename {arch/arm/mach-tegra => drivers/soc/tegra}/reset.c (100%) rename {arch/arm/mach-tegra => drivers/soc/tegra}/reset.h (97%)
Quoted 7 lines
Quoted 5 lines
Quoted 1 line
subsystem:
drivers/power/reset/
drivers/power/resetseems to be for drivers that register functions to reset a board. The above code for Tegra doesn't do that. Rather it sets up the reset handlers for secondary CPUs and for suspend/resume.PSCI again?
I have yet to look at what exactly needs to be done on 64-bit Tegra to get CPUs up. So I'll revisit this part of the patches when that's happened. It may yet turn out that most of this doesn't need to be shared after all.
Thierry
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 819 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20140630/8dfcac35/attachment.sig>
RFC 1/4 ARM: tegra: Move SoC drivers to drivers/soc/tegra
In reply to Catalin MarinasQuoted 30 lines · Catalin Marinas
Quoted 10 lines · Thierry Reding
Quoted 8 lines · Santosh Shilimkar
Quoted 5 lines · Thierry Reding
rename {arch/arm/mach-tegra => drivers/soc/tegra}/cpuidle-tegra114.c (100%) rename {arch/arm/mach-tegra => drivers/soc/tegra}/cpuidle-tegra20.c (100%) rename {arch/arm/mach-tegra => drivers/soc/tegra}/cpuidle-tegra30.c (100%) rename {arch/arm/mach-tegra => drivers/soc/tegra}/cpuidle.c (100%) rename {arch/arm/mach-tegra => drivers/soc/tegra}/cpuidle.h (91%)This should go into
drivers/idle/*. if you have dependencies, please sort them out.Quoted 7 lines
What exactly is the difference between
drivers/idleanddrivers/cpuidle? There's anintel_idledriver indrivers/idlethat includescpuidle.hand registers with that subsystem. But there's also ani7300_idledriver that doesn't.
drivers/cpuidleseems like a better fit. I'll look into moving the code there.Actually, please look at Lorenzo's generic cpuidle series. Basically most cpuidle drivers simply define some C states and call the corresponding platform back-end. On arm64, we aim to separate the back-end in the
cpu_operationsstructure and just have a generic cpuidle driver with states defined in the DT (and passed to the back-end).As for the back-end, what about using PSCI?
Quoted 3 lines
Quoted 3 lines
Quoted 3 lines
rename {arch/arm/mach-tegra => drivers/soc/tegra}/reset-handler.S (100%) rename {arch/arm/mach-tegra => drivers/soc/tegra}/reset.c (100%) rename {arch/arm/mach-tegra => drivers/soc/tegra}/reset.h (97%)
Quoted 7 lines
Quoted 5 lines
Quoted 1 line
subsystem:
drivers/power/reset/
drivers/power/resetseems to be for drivers that register functions to reset a board. The above code for Tegra doesn't do that. Rather it sets up the reset handlers for secondary CPUs and for suspend/resume.PSCI again?
Not possible for boards where linux runs in NS (roth and tn7). The secure monitor on those is outside our control and does not implement PSCI. There might be some value for Tegra114 and Tegra124 if we would like to use HYP mode, but that's not on the radar today. It's a waste of time for Tegra20 and Tegra30.
Cheers,
Peter.
RFC 1/4 ARM: tegra: Move SoC drivers to drivers/soc/tegra
Quoted 33 lines · Peter De Schrijver
Quoted 32 lines · Catalin Marinas
Quoted 10 lines · Thierry Reding
Quoted 8 lines · Santosh Shilimkar
Quoted 5 lines · Thierry Reding
rename {arch/arm/mach-tegra => drivers/soc/tegra}/cpuidle-tegra114.c (100%) rename {arch/arm/mach-tegra => drivers/soc/tegra}/cpuidle-tegra20.c (100%) rename {arch/arm/mach-tegra => drivers/soc/tegra}/cpuidle-tegra30.c (100%) rename {arch/arm/mach-tegra => drivers/soc/tegra}/cpuidle.c (100%) rename {arch/arm/mach-tegra => drivers/soc/tegra}/cpuidle.h (91%)This should go into
drivers/idle/*. if you have dependencies, please sort them out.Quoted 7 lines
What exactly is the difference between
drivers/idleanddrivers/cpuidle? There's anintel_idledriver indrivers/idlethat includescpuidle.hand registers with that subsystem. But there's also ani7300_idledriver that doesn't.
drivers/cpuidleseems like a better fit. I'll look into moving the code there.Actually, please look at Lorenzo's generic cpuidle series. Basically most cpuidle drivers simply define some C states and call the corresponding platform back-end. On arm64, we aim to separate the back-end in the
cpu_operationsstructure and just have a generic cpuidle driver with states defined in the DT (and passed to the back-end).As for the back-end, what about using PSCI?
Quoted 5 lines
Quoted 4 lines
Quoted 3 lines
rename {arch/arm/mach-tegra => drivers/soc/tegra}/reset-handler.S (100%) rename {arch/arm/mach-tegra => drivers/soc/tegra}/reset.c (100%) rename {arch/arm/mach-tegra => drivers/soc/tegra}/reset.h (97%)subsystem:
drivers/power/reset/
Quoted 7 lines
Quoted 5 lines
Quoted 3 lines
drivers/power/resetseems to be for drivers that register functions to reset a board. The above code for Tegra doesn't do that. Rather it sets up the reset handlers for secondary CPUs and for suspend/resume.PSCI again?
Not possible for boards where linux runs in NS (roth and tn7).
That's one of the main use-cases for PSCI - Linux running in NS mode. AFAIK, the boards that you mentioned are not ARMv8? We don't intend to enforce PSCI on ARMv7 platforms, mainly because of the legacy firmware (though where starting from scratch it would be nice). That means that the code won't be shared with arm64 and you can leave it under arch/arm (it's a lot of AArch32 assembly anyway).
Quoted 2 lines
The secure monitor on those is outside our control and does not implement PSCI.
As I said, I don't think we should change firmware on existing ARMv7 SoCs but for a new ARMv8 SoC I strongly recommend PSCI. The firmware needs to be written anyway (different AArch64 exception model), so you can raise such requirement with your firmware provider (ARM also provides Trusted Firmware freely as a quick start which implements PSCI, though you can only use it as an example).
Quoted 3 lines
There might be some value for Tegra114 and Tegra124 if we would like to use HYP mode, but that's not on the radar today. It's a waste of time for Tegra20 and Tegra30.
I think you should keep the Hyp support in mind anyway and test Linux booting in NS mode on your platforms. It may not be on your radar today for a SoC but if you later decide that it is, we end up with needing different code paths in Linux for the same SoC depending on how it boots (and you can't easily detect this at boot time, nor you can pass it via DT).
Signature · 1 line
Catalin
RFC 1/4 ARM: tegra: Move SoC drivers to drivers/soc/tegra
Quoted 6 lines
Quoted 3 lines
Quoted 1 line
PSCI again?
Not possible for boards where linux runs in NS (roth and tn7).
That's one of the main use-cases for PSCI - Linux running in NS mode. AFAIK, the boards that you mentioned are not ARMv8? We don't intend to
They are v7 indeed...
Quoted 8 lines
enforce PSCI on ARMv7 platforms, mainly because of the legacy firmware (though where starting from scratch it would be nice). That means that the code won't be shared with arm64 and you can leave it under
arch/arm(it's a lot of AArch32 assembly anyway).Quoted 2 lines
The secure monitor on those is outside our control and does not implement PSCI.
Quoted 6 lines
As I said, I don't think we should change firmware on existing ARMv7 SoCs but for a new ARMv8 SoC I strongly recommend PSCI. The firmware needs to be written anyway (different AArch64 exception model), so you can raise such requirement with your firmware provider (ARM also provides Trusted Firmware freely as a quick start which implements PSCI, though you can only use it as an example).
For v8 this should be fine yes...
Quoted 11 lines
Quoted 4 lines
There might be some value for Tegra114 and Tegra124 if we would like to use HYP mode, but that's not on the radar today. It's a waste of time for Tegra20 and Tegra30.
I think you should keep the Hyp support in mind anyway and test Linux booting in NS mode on your platforms. It may not be on your radar today for a SoC but if you later decide that it is, we end up with needing different code paths in Linux for the same SoC depending on how it boots (and you can't easily detect this at boot time, nor you can pass it via DT).
You can just look for a psci DT node? If this node is missing, fallback to the existing tegra specific mechanism. At least, that's how I envision doing PSCI for HYP mode on v7 based boards where linux today runs in secure mode. u-boot loads a minimal secure monitor which only does PSCI (we don't care about any security as there are no keys available for signing on those boards anyway), adds the PSCI node to the DT and then boots linux in HYP mode. tegra_cpu_reset_handler_enable() checks for a PSCI node and uses it if available. Else it will fallback to the existing methods. Similar for cpuidle. No guarantees that this will ever be implemented though :) Maybe.
Cheers,
Peter.
RFC 1/4 ARM: tegra: Move SoC drivers to drivers/soc/tegra
Quoted 8 lines
Quoted 7 lines
I think you should keep the Hyp support in mind anyway and test Linux booting in NS mode on your platforms. It may not be on your radar today for a SoC but if you later decide that it is, we end up with needing different code paths in Linux for the same SoC depending on how it boots (and you can't easily detect this at boot time, nor you can pass it via DT).
Quoted 10 lines
You can just look for a psci DT node? If this node is missing, fallback to the existing tegra specific mechanism. At least, that's how I envision doing PSCI for HYP mode on v7 based boards where linux today runs in secure mode. u-boot loads a minimal secure monitor which only does PSCI (we don't care about any security as there are no keys available for signing on those boards anyway), adds the PSCI node to the DT and then boots linux in HYP mode.
tegra_cpu_reset_handler_enable()checks for a PSCI node and uses it if available. Else it will fallback to the existing methods. Similar for cpuidle. No guarantees that this will ever be implemented though :) Maybe.
Come to think of it, we follow almost the same approach for Tegra114 where we support boards with Trusted Foundations secure monitor and linux in secure mode with the same kernel image.
Cheers,
Peter.
RFC 1/4 ARM: tegra: Move SoC drivers to drivers/soc/tegra
In reply to Peter De SchrijverQuoted 11 lines · Peter De Schrijver
Quoted 10 lines
Quoted 3 lines
There might be some value for Tegra114 and Tegra124 if we would like to use HYP mode, but that's not on the radar today. It's a waste of time for Tegra20 and Tegra30.
I think you should keep the Hyp support in mind anyway and test Linux booting in NS mode on your platforms. It may not be on your radar today for a SoC but if you later decide that it is, we end up with needing different code paths in Linux for the same SoC depending on how it boots (and you can't easily detect this at boot time, nor you can pass it via DT).
Quoted 3 lines
You can just look for a psci DT node? If this node is missing, fallback to the existing tegra specific mechanism. At least, that's how I envision doing PSCI for HYP mode on v7 based boards where linux today runs in secure mode.
This should work, assuming that setup required before the DT is available is already handled by firmware (for example, SMP coherency bit in secure-only registers).
Quoted 3 lines
u-boot loads a minimal secure monitor which only does PSCI (we don't care about any security as there are no keys available for signing on those boards anyway), adds the PSCI node to the DT and then boots linux in HYP mode.
BTW, there are some patches under review for adding PSCI support to U-Boot.
Signature · 1 line
Catalin
RFC 1/4 ARM: tegra: Move SoC drivers to drivers/soc/tegra
In reply to Thierry RedingQuoted 5 lines · Thierry Reding
From: Thierry Reding <[email protected]>
These drivers are closely coupled and need to be moved as a whole. One reason for moving them out of
arch/arm/mach-tegrais to allow them to be shared with 64-bit ARM.
Aside from any discussions re: splitting out cpuidle, power domains, ... into separate subsystem directories, this patch looks conceptually fine to me.
That said, given that I think arch/arm64 isn't going to have mach-* directories or machine descriptors, I wonder how all this code is going to be invoked at boot. arch/arm/mach-tegra/tegra.c calls a bunch of these functions at boot right now. So, it seems like moving the code so that it can compile in both places is only part of the solution? Are we going to have an arm64-specific SoC driver that binds to the SoC compatible in order to initialize everything? If so, I wonder if the same can work for arch/arm so everything works the same way?
RFC 1/4 ARM: tegra: Move SoC drivers to drivers/soc/tegra
Quoted 11 lines · Stephen Warren
Quoted 5 lines · Thierry Reding
From: Thierry Reding <[email protected]>
These drivers are closely coupled and need to be moved as a whole. One reason for moving them out of
arch/arm/mach-tegrais to allow them to be shared with 64-bit ARM.Aside from any discussions re: splitting out cpuidle, power domains, ... into separate subsystem directories, this patch looks conceptually fine to me.
Quoted 5 lines
That said, given that I think
arch/arm64isn't going to have mach-* directories or machine descriptors, I wonder how all this code is going to be invoked at boot.arch/arm/mach-tegra/tegra.ccalls a bunch of these functions at boot right now. So, it seems like moving the code so that it can compile in both places is only part of the solution?
Yes, that's correct. My primary motivation for moving this outside of arch/arm/mach-tegra was because we need the powergate APIs for 64-bit builds. I can look at moving out only that driver in a first step and then look at moving cpuidle where it belongs. As for the other pieces maybe a better solution would be to keep them in arch/arm/mach-tegra for now until we've determined which of them are really needed for 64-bit and move them out on an as-needed basis. Untangling these on by one will take some effort, though.
Quoted 3 lines
Are we going to have an arm64-specific SoC driver that binds to the SoC compatible in order to initialize everything? If so, I wonder if the same can work for
arch/armso everything works the same way?
I think we'll have to do something along those lines. But I'm not sure how well it will work out because some of these drivers need to be set up very early, before any of the driver core is up.
Thierry
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 819 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20140628/d9b8c160/attachment-0001.sig>