* [PATCH 2/3] ARM: tegra: make debug-macro.S work standalone
From: Stephen Warren @ 2012-10-02 19:07 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1349204866-21810-1-git-send-email-swarren@wwwdotorg.org>
From: Stephen Warren <swarren@nvidia.com>
Prior to this change, Tegra's debug-macro.S relied on uncompress.h having
determined which UART to use, and whether it was safe to use the UART
(i.e. is it not in reset, and clocked). This determination was
communicated from uncompress.h to debug-macro.S using a few bytes of
Tegra's IRAM (an on-SoC RAM). This had the disadvantage that uncompress.h
was a required part of the kernel boot process; booting a non-compressed
kernel would not allow earlyprintk to operate.
This change duplicates the UART selection and validation logic into
debug-macro.S so that the reliance on uncompress.h is removed.
This also helps out with single-zImage work, since there is currently no
support for using any uncompress with single-zImage.
Signed-off-by: Stephen Warren <swarren@nvidia.com>
---
arch/arm/mach-tegra/common.c | 3 +-
arch/arm/mach-tegra/include/mach/debug-macro.S | 151 ++++++++++++++++++++---
arch/arm/mach-tegra/include/mach/irammap.h | 9 --
arch/arm/mach-tegra/include/mach/uncompress.h | 13 --
4 files changed, 133 insertions(+), 43 deletions(-)
diff --git a/arch/arm/mach-tegra/common.c b/arch/arm/mach-tegra/common.c
index 0913d1f..72ec650 100644
--- a/arch/arm/mach-tegra/common.c
+++ b/arch/arm/mach-tegra/common.c
@@ -44,13 +44,14 @@
* kernel is loaded. The data is declared here rather than debug-macro.S so
* that multiple inclusions of debug-macro.S point at the same data.
*/
-u32 tegra_uart_config[3] = {
+u32 tegra_uart_config[4] = {
/* Debug UART initialization required */
1,
/* Debug UART physical address */
0,
/* Debug UART virtual address */
0,
+ /* Scratch space for debug macro */
};
#ifdef CONFIG_OF
diff --git a/arch/arm/mach-tegra/include/mach/debug-macro.S b/arch/arm/mach-tegra/include/mach/debug-macro.S
index 8ce0661..6ba3502 100644
--- a/arch/arm/mach-tegra/include/mach/debug-macro.S
+++ b/arch/arm/mach-tegra/include/mach/debug-macro.S
@@ -27,7 +27,42 @@
#include <linux/serial_reg.h>
#include <mach/iomap.h>
-#include <mach/irammap.h>
+
+#define UART_SHIFT 2
+
+#define TEGRA_CLK_RST_DEVICES_L (TEGRA_CLK_RESET_BASE + 0x04)
+#define TEGRA_CLK_RST_DEVICES_H (TEGRA_CLK_RESET_BASE + 0x08)
+#define TEGRA_CLK_RST_DEVICES_U (TEGRA_CLK_RESET_BASE + 0x0c)
+#define TEGRA_CLK_OUT_ENB_L (TEGRA_CLK_RESET_BASE + 0x10)
+#define TEGRA_CLK_OUT_ENB_H (TEGRA_CLK_RESET_BASE + 0x14)
+#define TEGRA_CLK_OUT_ENB_U (TEGRA_CLK_RESET_BASE + 0x18)
+#define TEGRA_PMC_SCRATCH20 (TEGRA_PMC_BASE + 0xa0)
+#define TEGRA_APB_MISC_GP_HIDREV (TEGRA_APB_MISC_BASE + 0x804)
+
+#define checkuart(rp, rv, lhu, bit, uart) \
+ /* Load address of CLK_RST register */ \
+ movw rp, #TEGRA_CLK_RST_DEVICES_##lhu & 0xffff ; \
+ movt rp, #TEGRA_CLK_RST_DEVICES_##lhu >> 16 ; \
+ /* Load value from CLK_RST register */ \
+ ldr rp, [rp, #0] ; \
+ /* Test UART's reset bit */ \
+ tst rp, #(1 << bit) ; \
+ /* If set, can't use UART; jump to save no UART */ \
+ bne 90f ; \
+ /* Load address of CLK_OUT_ENB register */ \
+ movw rp, #TEGRA_CLK_OUT_ENB_##lhu & 0xffff ; \
+ movt rp, #TEGRA_CLK_OUT_ENB_##lhu >> 16 ; \
+ /* Load value from CLK_OUT_ENB register */ \
+ ldr rp, [rp, #0] ; \
+ /* Test UART's clock enable bit */ \
+ tst rp, #(1 << bit) ; \
+ /* If clear, can't use UART; jump to save no UART */ \
+ beq 90f ; \
+ /* Passed all tests, load address of UART registers */ \
+ movw rp, #TEGRA_UART##uart##_BASE & 0xffff ; \
+ movt rp, #TEGRA_UART##uart##_BASE >> 16 ; \
+ /* Jump to save UART address */ \
+ b 91f
.macro addruart, rp, rv, tmp
adr \rp, 99f @ actual addr of 99f
@@ -36,22 +71,101 @@
ldr \rp, [\rp, #4] @ linked tegra_uart_config
sub \tmp, \rp, \rv @ actual tegra_uart_config
ldr \rp, [\tmp] @ Load tegra_uart_config
- cmp \rp, #1 @ needs intitialization?
+ cmp \rp, #1 @ needs initialization?
bne 100f @ no; go load the addresses
mov \rv, #0 @ yes; record init is done
str \rv, [\tmp]
- mov \rp, #TEGRA_IRAM_BASE @ See if cookie is in IRAM
- ldr \rv, [\rp, #TEGRA_IRAM_DEBUG_UART_OFFSET]
- movw \rp, #TEGRA_IRAM_DEBUG_UART_COOKIE & 0xffff
- movt \rp, #TEGRA_IRAM_DEBUG_UART_COOKIE >> 16
- cmp \rv, \rp @ Cookie present?
- bne 100f @ No, use default UART
- mov \rp, #TEGRA_IRAM_BASE @ Load UART address from IRAM
- ldr \rv, [\rp, #TEGRA_IRAM_DEBUG_UART_OFFSET + 4]
- str \rv, [\tmp, #4] @ Store in tegra_uart_phys
- sub \rv, \rv, #IO_APB_PHYS @ Calculate virt address
+
+#ifdef CONFIG_TEGRA_DEBUG_UART_AUTO_ODMDATA
+ /* Check ODMDATA */
+10: movw \rp, #TEGRA_PMC_SCRATCH20 & 0xffff
+ movt \rp, #TEGRA_PMC_SCRATCH20 >> 16
+ ldr \rp, [\rp, #0] @ Load PMC_SCRATCH20
+ ubfx \rv, \rp, #18, #2 @ 19:18 are console type
+ cmp \rv, #2 @ 2 and 3 mean DCC, UART
+ beq 11f @ some boards swap the meaning
+ cmp \rv, #3 @ so accept either
+ bne 90f
+11: ubfx \rv, \rp, #15, #3 @ 17:15 are UART ID
+ cmp \rv, #0 @ UART 0?
+ beq 20f
+ cmp \rv, #1 @ UART 1?
+ beq 21f
+ cmp \rv, #2 @ UART 2?
+ beq 22f
+ cmp \rv, #3 @ UART 3?
+ beq 23f
+ cmp \rv, #4 @ UART 4?
+ beq 24f
+ b 90f @ invalid
+#endif
+
+#if defined(CONFIG_TEGRA_DEBUG_UARTA) || \
+ defined(CONFIG_TEGRA_DEBUG_UART_AUTO_ODMDATA)
+ /* Check UART A validity */
+20: checkuart(\rp, \rv, L, 6, A)
+#endif
+
+#if defined(CONFIG_TEGRA_DEBUG_UARTB) || \
+ defined(CONFIG_TEGRA_DEBUG_UART_AUTO_ODMDATA)
+ /* Check UART B validity */
+21: checkuart(\rp, \rv, L, 7, B)
+#endif
+
+#if defined(CONFIG_TEGRA_DEBUG_UARTC) || \
+ defined(CONFIG_TEGRA_DEBUG_UART_AUTO_ODMDATA)
+ /* Check UART C validity */
+22: checkuart(\rp, \rv, H, 23, C)
+#endif
+
+#if defined(CONFIG_TEGRA_DEBUG_UARTD) || \
+ defined(CONFIG_TEGRA_DEBUG_UART_AUTO_ODMDATA)
+ /* Check UART D validity */
+23: checkuart(\rp, \rv, U, 1, D)
+#endif
+
+#if defined(CONFIG_TEGRA_DEBUG_UARTE) || \
+ defined(CONFIG_TEGRA_DEBUG_UART_AUTO_ODMDATA)
+ /* Check UART E validity */
+24:
+ checkuart(\rp, \rv, U, 2, E)
+#endif
+
+ /* No valid UART found */
+90: mov \rp, #0
+ /* fall through */
+
+ /* Record whichever UART we chose */
+91: str \rp, [\tmp, #4] @ Store in tegra_uart_phys
+ cmp \rp, #0 @ Valid UART address?
+ bne 92f @ Yes, go process it
+ str \rp, [\tmp, #8] @ Store 0 in tegra_uart_phys
+ b 100f @ Done
+92: sub \rv, \rp, #IO_APB_PHYS @ Calculate virt address
add \rv, \rv, #IO_APB_VIRT
str \rv, [\tmp, #8] @ Store in tegra_uart_virt
+ movw \rv, #TEGRA_APB_MISC_GP_HIDREV & 0xffff
+ movt \rv, #TEGRA_APB_MISC_GP_HIDREV >> 16
+ ldr \rv, [\rv, #0] @ Load HIDREV
+ ubfx \rv, \rv, #8, #8 @ 15:8 are SoC version
+ cmp \rv, #0x20 @ Tegra20?
+ moveq \rv, #0x75 @ Tegra20 divisor
+ movne \rv, #0xdd @ Tegra30 divisor
+ str \rv, [\tmp, #12] @ Save divisor to scratch
+ /* uart[UART_LCR] = UART_LCR_WLEN8 | UART_LCR_DLAB; */
+ mov \rv, #UART_LCR_WLEN8 | UART_LCR_DLAB
+ str \rv, [\rp, #UART_LCR << UART_SHIFT]
+ /* uart[UART_DLL] = div & 0xff; */
+ ldr \rv, [\tmp, #12]
+ and \rv, \rv, #0xff
+ str \rv, [\rp, #UART_DLL << UART_SHIFT]
+ /* uart[UART_DLM] = div >> 8; */
+ ldr \rv, [\tmp, #12]
+ lsr \rv, \rv, #8
+ str \rv, [\rp, #UART_DLM << UART_SHIFT]
+ /* uart[UART_LCR] = UART_LCR_WLEN8; */
+ mov \rv, #UART_LCR_WLEN8
+ str \rv, [\rp, #UART_LCR << UART_SHIFT]
b 100f
.align
@@ -59,27 +173,24 @@
.word tegra_uart_config
.ltorg
+ /* Load previously selected UART address */
100: ldr \rp, [\tmp, #4] @ Load tegra_uart_phys
ldr \rv, [\tmp, #8] @ Load tegra_uart_virt
.endm
-#define UART_SHIFT 2
-
/*
* Code below is swiped from <asm/hardware/debug-8250.S>, but add an extra
- * check to make sure that we aren't in the CONFIG_TEGRA_DEBUG_UART_NONE case.
- * We use the fact that all 5 valid UART addresses all have something in the
- * 2nd-to-lowest byte.
+ * check to make sure that the UART address is actually valid.
*/
.macro senduart, rd, rx
- tst \rx, #0x0000ff00
+ cmp \rx, #0
strneb \rd, [\rx, #UART_TX << UART_SHIFT]
1001:
.endm
.macro busyuart, rd, rx
- tst \rx, #0x0000ff00
+ cmp \rx, #0
beq 1002f
1001: ldrb \rd, [\rx, #UART_LSR << UART_SHIFT]
and \rd, \rd, #UART_LSR_TEMT | UART_LSR_THRE
@@ -90,7 +201,7 @@
.macro waituart, rd, rx
#ifdef FLOW_CONTROL
- tst \rx, #0x0000ff00
+ cmp \rx, #0
beq 1002f
1001: ldrb \rd, [\rx, #UART_MSR << UART_SHIFT]
tst \rd, #UART_MSR_CTS
diff --git a/arch/arm/mach-tegra/include/mach/irammap.h b/arch/arm/mach-tegra/include/mach/irammap.h
index 0cbe632..501952a 100644
--- a/arch/arm/mach-tegra/include/mach/irammap.h
+++ b/arch/arm/mach-tegra/include/mach/irammap.h
@@ -23,13 +23,4 @@
#define TEGRA_IRAM_RESET_HANDLER_OFFSET 0
#define TEGRA_IRAM_RESET_HANDLER_SIZE SZ_1K
-/*
- * These locations are written to by uncompress.h, and read by debug-macro.S.
- * The first word holds the cookie value if the data is valid. The second
- * word holds the UART physical address.
- */
-#define TEGRA_IRAM_DEBUG_UART_OFFSET SZ_1K
-#define TEGRA_IRAM_DEBUG_UART_SIZE 8
-#define TEGRA_IRAM_DEBUG_UART_COOKIE 0x55415254
-
#endif
diff --git a/arch/arm/mach-tegra/include/mach/uncompress.h b/arch/arm/mach-tegra/include/mach/uncompress.h
index d5b86ce..51ea92c 100644
--- a/arch/arm/mach-tegra/include/mach/uncompress.h
+++ b/arch/arm/mach-tegra/include/mach/uncompress.h
@@ -29,7 +29,6 @@
#include <linux/serial_reg.h>
#include <mach/iomap.h>
-#include <mach/irammap.h>
#define BIT(x) (1 << (x))
#define ARRAY_SIZE(arr) (sizeof(arr) / sizeof((arr)[0]))
@@ -52,17 +51,6 @@ static inline void flush(void)
{
}
-static inline void save_uart_address(void)
-{
- u32 *buf = (u32 *)(TEGRA_IRAM_BASE + TEGRA_IRAM_DEBUG_UART_OFFSET);
-
- if (uart) {
- buf[0] = TEGRA_IRAM_DEBUG_UART_COOKIE;
- buf[1] = (u32)uart;
- } else
- buf[0] = 0;
-}
-
static const struct {
u32 base;
u32 reset_reg;
@@ -169,7 +157,6 @@ static inline void arch_decomp_setup(void)
else
uart = (volatile u8 *)uarts[uart_id].base;
- save_uart_address();
if (uart == NULL)
return;
--
1.7.0.4
^ permalink raw reply related
* [PATCH 1/3] ARM: tegra: simplify DEBUG_LL UART selection options
From: Stephen Warren @ 2012-10-02 19:07 UTC (permalink / raw)
To: linux-arm-kernel
From: Stephen Warren <swarren@nvidia.com>
Delete CONFIG_TEGRA_DEBUG_UART_AUTO_SCRATCH; it's not useful any more:
* No upstream bootloader currently or will ever support this option.
* CONFIG_TEGRA_DEBUG_UART_AUTO_ODMDATA is a much more direct alternative.
Merge the fixed and automatic UART selection menus into a single choice
for simplicity; now you either pick AUTO_ODMDATA or a single fixed UART,
rather than potentially having an AUTO option override whatever fixed
option was chosen.
Remove TEGRA_DEBUG_UART_NONE; if you don't want a Tegra DEBUG_LL UART,
simply don't turn on DEBUG_LL. NONE used to be the default option, so
pick AUTO_ODMDATA as the new default.
Signed-off-by: Stephen Warren <swarren@nvidia.com>
---
arch/arm/mach-tegra/Kconfig | 41 +++++---------------
arch/arm/mach-tegra/common.c | 5 +-
arch/arm/mach-tegra/include/mach/iomap.h | 14 -------
arch/arm/mach-tegra/include/mach/uncompress.h | 52 ++-----------------------
4 files changed, 16 insertions(+), 96 deletions(-)
diff --git a/arch/arm/mach-tegra/Kconfig b/arch/arm/mach-tegra/Kconfig
index 1219d87..87f0e2d 100644
--- a/arch/arm/mach-tegra/Kconfig
+++ b/arch/arm/mach-tegra/Kconfig
@@ -58,11 +58,17 @@ config TEGRA_AHB
perfomance parameters(priority, prefech size).
choice
- prompt "Default low-level debug console UART"
- default TEGRA_DEBUG_UART_NONE
+ prompt "Low-level debug console UART"
+ default TEGRA_DEBUG_UART_AUTO_ODMDATA
-config TEGRA_DEBUG_UART_NONE
- bool "None"
+config TEGRA_DEBUG_UART_AUTO_ODMDATA
+ bool "Via ODMDATA"
+ help
+ Automatically determines which UART to use for low-level debug based
+ on the ODMDATA value. This value is part of the BCT, and is written
+ to the boot memory device using nvflash, or other flashing tool.
+ When bits 19:18 are 3, then bits 17:15 indicate which UART to use;
+ 0/1/2/3/4 are UART A/B/C/D/E.
config TEGRA_DEBUG_UARTA
bool "UART-A"
@@ -81,33 +87,6 @@ config TEGRA_DEBUG_UARTE
endchoice
-choice
- prompt "Automatic low-level debug console UART"
- default TEGRA_DEBUG_UART_AUTO_NONE
-
-config TEGRA_DEBUG_UART_AUTO_NONE
- bool "None"
-
-config TEGRA_DEBUG_UART_AUTO_ODMDATA
- bool "Via ODMDATA"
- help
- Automatically determines which UART to use for low-level debug based
- on the ODMDATA value. This value is part of the BCT, and is written
- to the boot memory device using nvflash, or other flashing tool.
- When bits 19:18 are 3, then bits 17:15 indicate which UART to use;
- 0/1/2/3/4 are UART A/B/C/D/E.
-
-config TEGRA_DEBUG_UART_AUTO_SCRATCH
- bool "Via UART scratch register"
- help
- Automatically determines which UART to use for low-level debug based
- on the UART scratch register value. Some bootloaders put ASCII 'D'
- in this register when they initialize their own console UART output.
- Using this option allows the kernel to automatically pick the same
- UART.
-
-endchoice
-
config TEGRA_EMC_SCALING_ENABLE
bool "Enable scaling the memory frequency"
diff --git a/arch/arm/mach-tegra/common.c b/arch/arm/mach-tegra/common.c
index 0b0a5f5..0913d1f 100644
--- a/arch/arm/mach-tegra/common.c
+++ b/arch/arm/mach-tegra/common.c
@@ -44,14 +44,13 @@
* kernel is loaded. The data is declared here rather than debug-macro.S so
* that multiple inclusions of debug-macro.S point at the same data.
*/
-#define TEGRA_DEBUG_UART_OFFSET (TEGRA_DEBUG_UART_BASE & 0xFFFF)
u32 tegra_uart_config[3] = {
/* Debug UART initialization required */
1,
/* Debug UART physical address */
- (u32)(IO_APB_PHYS + TEGRA_DEBUG_UART_OFFSET),
+ 0,
/* Debug UART virtual address */
- (u32)(IO_APB_VIRT + TEGRA_DEBUG_UART_OFFSET),
+ 0,
};
#ifdef CONFIG_OF
diff --git a/arch/arm/mach-tegra/include/mach/iomap.h b/arch/arm/mach-tegra/include/mach/iomap.h
index fee3a94..4f1d9a3 100644
--- a/arch/arm/mach-tegra/include/mach/iomap.h
+++ b/arch/arm/mach-tegra/include/mach/iomap.h
@@ -263,20 +263,6 @@
#define TEGRA_SDMMC4_BASE 0xC8000600
#define TEGRA_SDMMC4_SIZE SZ_512
-#if defined(CONFIG_TEGRA_DEBUG_UART_NONE)
-# define TEGRA_DEBUG_UART_BASE 0
-#elif defined(CONFIG_TEGRA_DEBUG_UARTA)
-# define TEGRA_DEBUG_UART_BASE TEGRA_UARTA_BASE
-#elif defined(CONFIG_TEGRA_DEBUG_UARTB)
-# define TEGRA_DEBUG_UART_BASE TEGRA_UARTB_BASE
-#elif defined(CONFIG_TEGRA_DEBUG_UARTC)
-# define TEGRA_DEBUG_UART_BASE TEGRA_UARTC_BASE
-#elif defined(CONFIG_TEGRA_DEBUG_UARTD)
-# define TEGRA_DEBUG_UART_BASE TEGRA_UARTD_BASE
-#elif defined(CONFIG_TEGRA_DEBUG_UARTE)
-# define TEGRA_DEBUG_UART_BASE TEGRA_UARTE_BASE
-#endif
-
/* On TEGRA, many peripherals are very closely packed in
* two 256MB io windows (that actually only use about 64KB
* at the start of each).
diff --git a/arch/arm/mach-tegra/include/mach/uncompress.h b/arch/arm/mach-tegra/include/mach/uncompress.h
index 937c4c5..d5b86ce 100644
--- a/arch/arm/mach-tegra/include/mach/uncompress.h
+++ b/arch/arm/mach-tegra/include/mach/uncompress.h
@@ -139,51 +139,19 @@ int auto_odmdata(void)
}
#endif
-#ifdef CONFIG_TEGRA_DEBUG_UART_AUTO_SCRATCH
-int auto_scratch(void)
-{
- int i;
-
- /*
- * Look for the first UART that:
- * a) Is not in reset.
- * b) Is clocked.
- * c) Has a 'D' in the scratchpad register.
- *
- * Note that on Tegra30, the first two conditions are required, since
- * if not true, accesses to the UART scratch register will hang.
- * Tegra20 doesn't have this issue.
- *
- * The intent is that the bootloader will tell the kernel which UART
- * to use by setting up those conditions. If nothing found, we'll fall
- * back to what's specified in TEGRA_DEBUG_UART_BASE.
- */
- for (i = 0; i < ARRAY_SIZE(uarts); i++) {
- if (!uart_clocked(i))
- continue;
-
- uart = (volatile u8 *)uarts[i].base;
- if (uart[UART_SCR << DEBUG_UART_SHIFT] != 'D')
- continue;
-
- return i;
- }
-
- return -1;
-}
-#endif
-
/*
* Setup before decompression. This is where we do UART selection for
* earlyprintk and init the uart_base register.
*/
static inline void arch_decomp_setup(void)
{
- int uart_id, auto_uart_id;
+ int uart_id;
volatile u32 *apb_misc = (volatile u32 *)TEGRA_APB_MISC_BASE;
u32 chip, div;
-#if defined(CONFIG_TEGRA_DEBUG_UARTA)
+#if defined(CONFIG_TEGRA_DEBUG_UART_AUTO_ODMDATA)
+ uart_id = auto_odmdata();
+#elif defined(CONFIG_TEGRA_DEBUG_UARTA)
uart_id = 0;
#elif defined(CONFIG_TEGRA_DEBUG_UARTB)
uart_id = 1;
@@ -193,19 +161,7 @@ static inline void arch_decomp_setup(void)
uart_id = 3;
#elif defined(CONFIG_TEGRA_DEBUG_UARTE)
uart_id = 4;
-#else
- uart_id = -1;
-#endif
-
-#if defined(CONFIG_TEGRA_DEBUG_UART_AUTO_ODMDATA)
- auto_uart_id = auto_odmdata();
-#elif defined(CONFIG_TEGRA_DEBUG_UART_AUTO_SCRATCH)
- auto_uart_id = auto_scratch();
-#else
- auto_uart_id = -1;
#endif
- if (auto_uart_id != -1)
- uart_id = auto_uart_id;
if (uart_id < 0 || uart_id >= ARRAY_SIZE(uarts) ||
!uart_clocked(uart_id))
--
1.7.0.4
^ permalink raw reply related
* [PATCH] ARM: tegra: update *.dts for regulator-compatible deprecation
From: Stephen Warren @ 2012-10-02 19:07 UTC (permalink / raw)
To: linux-arm-kernel
From: Stephen Warren <swarren@nvidia.com>
Commit 13511de "regulator: deprecate regulator-compatible DT property"
now allows for simpler content within the regulators node within a PMIC.
Modify all the Tegra device tree files to take advantage of this.
Signed-off-by: Stephen Warren <swarren@nvidia.com>
---
arch/arm/boot/dts/tegra20-harmony.dts | 63 ++++------------
arch/arm/boot/dts/tegra20-paz00.dts | 59 ++++------------
arch/arm/boot/dts/tegra20-seaboard.dts | 59 ++++------------
arch/arm/boot/dts/tegra20-tamonten.dtsi | 63 ++++------------
arch/arm/boot/dts/tegra20-ventana.dts | 59 ++++------------
arch/arm/boot/dts/tegra20-whistler.dts | 119 ++++++++-----------------------
arch/arm/boot/dts/tegra30-cardhu.dtsi | 47 +++---------
7 files changed, 112 insertions(+), 357 deletions(-)
diff --git a/arch/arm/boot/dts/tegra20-harmony.dts b/arch/arm/boot/dts/tegra20-harmony.dts
index c3ef1ad..74b8a47 100644
--- a/arch/arm/boot/dts/tegra20-harmony.dts
+++ b/arch/arm/boot/dts/tegra20-harmony.dts
@@ -297,131 +297,98 @@
vinldo9-supply = <&sm2_reg>;
regulators {
- #address-cells = <1>;
- #size-cells = <0>;
-
- sys_reg: regulator at 0 {
- reg = <0>;
- regulator-compatible = "sys";
+ sys_reg: sys {
regulator-name = "vdd_sys";
regulator-always-on;
};
- regulator at 1 {
- reg = <1>;
- regulator-compatible = "sm0";
+ sm0 {
regulator-name = "vdd_sm0,vdd_core";
regulator-min-microvolt = <1200000>;
regulator-max-microvolt = <1200000>;
regulator-always-on;
};
- regulator at 2 {
- reg = <2>;
- regulator-compatible = "sm1";
+ sm1 {
regulator-name = "vdd_sm1,vdd_cpu";
regulator-min-microvolt = <1000000>;
regulator-max-microvolt = <1000000>;
regulator-always-on;
};
- sm2_reg: regulator at 3 {
- reg = <3>;
- regulator-compatible = "sm2";
+ sm2_reg: sm2 {
regulator-name = "vdd_sm2,vin_ldo*";
regulator-min-microvolt = <3700000>;
regulator-max-microvolt = <3700000>;
regulator-always-on;
};
- regulator at 4 {
- reg = <4>;
- regulator-compatible = "ldo0";
+ ldo0 {
regulator-name = "vdd_ldo0,vddio_pex_clk";
regulator-min-microvolt = <3300000>;
regulator-max-microvolt = <3300000>;
};
- regulator at 5 {
- reg = <5>;
- regulator-compatible = "ldo1";
+ ldo1 {
regulator-name = "vdd_ldo1,avdd_pll*";
regulator-min-microvolt = <1100000>;
regulator-max-microvolt = <1100000>;
regulator-always-on;
};
- regulator at 6 {
- reg = <6>;
- regulator-compatible = "ldo2";
+ ldo2 {
regulator-name = "vdd_ldo2,vdd_rtc";
regulator-min-microvolt = <1200000>;
regulator-max-microvolt = <1200000>;
};
- regulator at 7 {
- reg = <7>;
- regulator-compatible = "ldo3";
+ ldo3 {
regulator-name = "vdd_ldo3,avdd_usb*";
regulator-min-microvolt = <3300000>;
regulator-max-microvolt = <3300000>;
regulator-always-on;
};
- regulator at 8 {
- reg = <8>;
- regulator-compatible = "ldo4";
+ ldo4 {
regulator-name = "vdd_ldo4,avdd_osc,vddio_sys";
regulator-min-microvolt = <1800000>;
regulator-max-microvolt = <1800000>;
regulator-always-on;
};
- regulator at 9 {
- reg = <9>;
- regulator-compatible = "ldo5";
+ ldo5 {
regulator-name = "vdd_ldo5,vcore_mmc";
regulator-min-microvolt = <2850000>;
regulator-max-microvolt = <2850000>;
regulator-always-on;
};
- regulator at 10 {
- reg = <10>;
- regulator-compatible = "ldo6";
+ ldo6 {
regulator-name = "vdd_ldo6,avdd_vdac";
regulator-min-microvolt = <1800000>;
regulator-max-microvolt = <1800000>;
};
- regulator at 11 {
- reg = <11>;
- regulator-compatible = "ldo7";
+ ldo7 {
regulator-name = "vdd_ldo7,avdd_hdmi";
regulator-min-microvolt = <3300000>;
regulator-max-microvolt = <3300000>;
};
- regulator at 12 {
- reg = <12>;
- regulator-compatible = "ldo8";
+ ldo8 {
regulator-name = "vdd_ldo8,avdd_hdmi_pll";
regulator-min-microvolt = <1800000>;
regulator-max-microvolt = <1800000>;
};
- regulator at 13 {
- reg = <13>;
- regulator-compatible = "ldo9";
+ ldo9 {
regulator-name = "vdd_ldo9,avdd_2v85,vdd_ddr_rx";
regulator-min-microvolt = <2850000>;
regulator-max-microvolt = <2850000>;
regulator-always-on;
};
- regulator at 14 {
- reg = <14>;
- regulator-compatible = "ldo_rtc";
+ ldo_rtc {
regulator-name = "vdd_rtc_out,vdd_cell";
regulator-min-microvolt = <3300000>;
regulator-max-microvolt = <3300000>;
diff --git a/arch/arm/boot/dts/tegra20-paz00.dts b/arch/arm/boot/dts/tegra20-paz00.dts
index ddf287f..6a93d14 100644
--- a/arch/arm/boot/dts/tegra20-paz00.dts
+++ b/arch/arm/boot/dts/tegra20-paz00.dts
@@ -291,37 +291,26 @@
vinldo9-supply = <&sm2_reg>;
regulators {
- #address-cells = <1>;
- #size-cells = <0>;
-
- sys_reg: regulator at 0 {
- reg = <0>;
- regulator-compatible = "sys";
+ sys_reg: sys {
regulator-name = "vdd_sys";
regulator-always-on;
};
- regulator at 1 {
- reg = <1>;
- regulator-compatible = "sm0";
+ sm0 {
regulator-name = "+1.2vs_sm0,vdd_core";
regulator-min-microvolt = <1200000>;
regulator-max-microvolt = <1200000>;
regulator-always-on;
};
- regulator at 2 {
- reg = <2>;
- regulator-compatible = "sm1";
+ sm1 {
regulator-name = "+1.0vs_sm1,vdd_cpu";
regulator-min-microvolt = <1000000>;
regulator-max-microvolt = <1000000>;
regulator-always-on;
};
- sm2_reg: regulator at 3 {
- reg = <3>;
- regulator-compatible = "sm2";
+ sm2_reg: sm2 {
regulator-name = "+3.7vs_sm2,vin_ldo*";
regulator-min-microvolt = <3700000>;
regulator-max-microvolt = <3700000>;
@@ -330,53 +319,41 @@
/* LDO0 is not connected to anything */
- regulator at 5 {
- reg = <5>;
- regulator-compatible = "ldo1";
+ ldo1 {
regulator-name = "+1.1vs_ldo1,avdd_pll*";
regulator-min-microvolt = <1100000>;
regulator-max-microvolt = <1100000>;
regulator-always-on;
};
- regulator at 6 {
- reg = <6>;
- regulator-compatible = "ldo2";
+ ldo2 {
regulator-name = "+1.2vs_ldo2,vdd_rtc";
regulator-min-microvolt = <1200000>;
regulator-max-microvolt = <1200000>;
};
- regulator at 7 {
- reg = <7>;
- regulator-compatible = "ldo3";
+ ldo3 {
regulator-name = "+3.3vs_ldo3,avdd_usb*";
regulator-min-microvolt = <3300000>;
regulator-max-microvolt = <3300000>;
regulator-always-on;
};
- regulator at 8 {
- reg = <8>;
- regulator-compatible = "ldo4";
+ ldo4 {
regulator-name = "+1.8vs_ldo4,avdd_osc,vddio_sys";
regulator-min-microvolt = <1800000>;
regulator-max-microvolt = <1800000>;
regulator-always-on;
};
- regulator at 9 {
- reg = <9>;
- regulator-compatible = "ldo5";
+ ldo5 {
regulator-name = "+2.85vs_ldo5,vcore_mmc";
regulator-min-microvolt = <2850000>;
regulator-max-microvolt = <2850000>;
regulator-always-on;
};
- regulator at 10 {
- reg = <10>;
- regulator-compatible = "ldo6";
+ ldo6 {
/*
* Research indicates this should be
* 1.8v; other boards that use this
@@ -390,34 +367,26 @@
regulator-max-microvolt = <1800000>;
};
- regulator at 11 {
- reg = <11>;
- regulator-compatible = "ldo7";
+ ldo7 {
regulator-name = "+3.3vs_ldo7,avdd_hdmi";
regulator-min-microvolt = <3300000>;
regulator-max-microvolt = <3300000>;
};
- regulator at 12 {
- reg = <12>;
- regulator-compatible = "ldo8";
+ ldo8 {
regulator-name = "+1.8vs_ldo8,avdd_hdmi_pll";
regulator-min-microvolt = <1800000>;
regulator-max-microvolt = <1800000>;
};
- regulator at 13 {
- reg = <13>;
- regulator-compatible = "ldo9";
+ ldo9 {
regulator-name = "+2.85vs_ldo9,vdd_ddr_rx";
regulator-min-microvolt = <2850000>;
regulator-max-microvolt = <2850000>;
regulator-always-on;
};
- regulator at 14 {
- reg = <14>;
- regulator-compatible = "ldo_rtc";
+ ldo_rtc {
regulator-name = "+3.3vs_rtc";
regulator-min-microvolt = <3300000>;
regulator-max-microvolt = <3300000>;
diff --git a/arch/arm/boot/dts/tegra20-seaboard.dts b/arch/arm/boot/dts/tegra20-seaboard.dts
index f0ba901..33ae813 100644
--- a/arch/arm/boot/dts/tegra20-seaboard.dts
+++ b/arch/arm/boot/dts/tegra20-seaboard.dts
@@ -395,37 +395,26 @@
vinldo9-supply = <&sm2_reg>;
regulators {
- #address-cells = <1>;
- #size-cells = <0>;
-
- sys_reg: regulator at 0 {
- reg = <0>;
- regulator-compatible = "sys";
+ sys_reg: sys {
regulator-name = "vdd_sys";
regulator-always-on;
};
- regulator at 1 {
- reg = <1>;
- regulator-compatible = "sm0";
+ sm0 {
regulator-name = "vdd_sm0,vdd_core";
regulator-min-microvolt = <1300000>;
regulator-max-microvolt = <1300000>;
regulator-always-on;
};
- regulator at 2 {
- reg = <2>;
- regulator-compatible = "sm1";
+ sm1 {
regulator-name = "vdd_sm1,vdd_cpu";
regulator-min-microvolt = <1125000>;
regulator-max-microvolt = <1125000>;
regulator-always-on;
};
- sm2_reg: regulator at 3 {
- reg = <3>;
- regulator-compatible = "sm2";
+ sm2_reg: sm2 {
regulator-name = "vdd_sm2,vin_ldo*";
regulator-min-microvolt = <3700000>;
regulator-max-microvolt = <3700000>;
@@ -434,86 +423,66 @@
/* LDO0 is not connected to anything */
- regulator at 5 {
- reg = <5>;
- regulator-compatible = "ldo1";
+ ldo1 {
regulator-name = "vdd_ldo1,avdd_pll*";
regulator-min-microvolt = <1100000>;
regulator-max-microvolt = <1100000>;
regulator-always-on;
};
- regulator at 6 {
- reg = <6>;
- regulator-compatible = "ldo2";
+ ldo2 {
regulator-name = "vdd_ldo2,vdd_rtc";
regulator-min-microvolt = <1200000>;
regulator-max-microvolt = <1200000>;
};
- regulator at 7 {
- reg = <7>;
- regulator-compatible = "ldo3";
+ ldo3 {
regulator-name = "vdd_ldo3,avdd_usb*";
regulator-min-microvolt = <3300000>;
regulator-max-microvolt = <3300000>;
regulator-always-on;
};
- regulator at 8 {
- reg = <8>;
- regulator-compatible = "ldo4";
+ ldo4 {
regulator-name = "vdd_ldo4,avdd_osc,vddio_sys";
regulator-min-microvolt = <1800000>;
regulator-max-microvolt = <1800000>;
regulator-always-on;
};
- regulator at 9 {
- reg = <9>;
- regulator-compatible = "ldo5";
+ ldo5 {
regulator-name = "vdd_ldo5,vcore_mmc";
regulator-min-microvolt = <2850000>;
regulator-max-microvolt = <2850000>;
regulator-always-on;
};
- regulator at 10 {
- reg = <10>;
- regulator-compatible = "ldo6";
+ ldo6 {
regulator-name = "vdd_ldo6,avdd_vdac,vddio_vi,vddio_cam";
regulator-min-microvolt = <1800000>;
regulator-max-microvolt = <1800000>;
};
- regulator at 11 {
- reg = <11>;
- regulator-compatible = "ldo7";
+ ldo7 {
regulator-name = "vdd_ldo7,avdd_hdmi,vdd_fuse";
regulator-min-microvolt = <3300000>;
regulator-max-microvolt = <3300000>;
};
- regulator at 12 {
- reg = <12>;
- regulator-compatible = "ldo8";
+ ldo8 {
regulator-name = "vdd_ldo8,avdd_hdmi_pll";
regulator-min-microvolt = <1800000>;
regulator-max-microvolt = <1800000>;
};
- regulator at 13 {
- reg = <13>;
- regulator-compatible = "ldo9";
+ ldo9 {
regulator-name = "vdd_ldo9,avdd_2v85,vdd_ddr_rx";
regulator-min-microvolt = <2850000>;
regulator-max-microvolt = <2850000>;
regulator-always-on;
};
- regulator at 14 {
- reg = <14>;
- regulator-compatible = "ldo_rtc";
+ ldo_rtc {
regulator-name = "vdd_rtc_out,vdd_cell";
regulator-min-microvolt = <3300000>;
regulator-max-microvolt = <3300000>;
diff --git a/arch/arm/boot/dts/tegra20-tamonten.dtsi b/arch/arm/boot/dts/tegra20-tamonten.dtsi
index f18cec9..5b3d8b1 100644
--- a/arch/arm/boot/dts/tegra20-tamonten.dtsi
+++ b/arch/arm/boot/dts/tegra20-tamonten.dtsi
@@ -271,97 +271,72 @@
vinldo9-supply = <&sm2_reg>;
regulators {
- #address-cells = <1>;
- #size-cells = <0>;
-
- sys_reg: regulator at 0 {
- reg = <0>;
- regulator-compatible = "sys";
+ sys_reg: sys {
regulator-name = "vdd_sys";
regulator-always-on;
};
- regulator at 1 {
- reg = <1>;
- regulator-compatible = "sm0";
+ sm0 {
regulator-name = "vdd_sys_sm0,vdd_core";
regulator-min-microvolt = <1200000>;
regulator-max-microvolt = <1200000>;
regulator-always-on;
};
- regulator at 2 {
- reg = <2>;
- regulator-compatible = "sm1";
+ sm1 {
regulator-name = "vdd_sys_sm1,vdd_cpu";
regulator-min-microvolt = <1000000>;
regulator-max-microvolt = <1000000>;
regulator-always-on;
};
- sm2_reg: regulator at 3 {
- reg = <3>;
- regulator-compatible = "sm2";
+ sm2_reg: sm2 {
regulator-name = "vdd_sys_sm2,vin_ldo*";
regulator-min-microvolt = <3700000>;
regulator-max-microvolt = <3700000>;
regulator-always-on;
};
- regulator at 4 {
- reg = <4>;
- regulator-compatible = "ldo0";
+ ldo0 {
regulator-name = "vdd_ldo0,vddio_pex_clk";
regulator-min-microvolt = <3300000>;
regulator-max-microvolt = <3300000>;
};
- regulator at 5 {
- reg = <5>;
- regulator-compatible = "ldo1";
+ ldo1 {
regulator-name = "vdd_ldo1,avdd_pll*";
regulator-min-microvolt = <1100000>;
regulator-max-microvolt = <1100000>;
regulator-always-on;
};
- regulator at 6 {
- reg = <6>;
- regulator-compatible = "ldo2";
+ ldo2 {
regulator-name = "vdd_ldo2,vdd_rtc";
regulator-min-microvolt = <1200000>;
regulator-max-microvolt = <1200000>;
};
- regulator at 7 {
- reg = <7>;
- regulator-compatible = "ldo3";
+ ldo3 {
regulator-name = "vdd_ldo3,avdd_usb*";
regulator-min-microvolt = <3300000>;
regulator-max-microvolt = <3300000>;
regulator-always-on;
};
- regulator at 8 {
- reg = <8>;
- regulator-compatible = "ldo4";
+ ldo4 {
regulator-name = "vdd_ldo4,avdd_osc,vddio_sys";
regulator-min-microvolt = <1800000>;
regulator-max-microvolt = <1800000>;
regulator-always-on;
};
- regulator at 9 {
- reg = <9>;
- regulator-compatible = "ldo5";
+ ldo5 {
regulator-name = "vdd_ldo5,vcore_mmc";
regulator-min-microvolt = <2850000>;
regulator-max-microvolt = <2850000>;
};
- regulator at 10 {
- reg = <10>;
- regulator-compatible = "ldo6";
+ ldo6 {
regulator-name = "vdd_ldo6,avdd_vdac";
/*
* According to the Tegra 2 Automotive
@@ -373,25 +348,19 @@
regulator-max-microvolt = <2850000>;
};
- regulator at 11 {
- reg = <11>;
- regulator-compatible = "ldo7";
+ ldo7 {
regulator-name = "vdd_ldo7,avdd_hdmi";
regulator-min-microvolt = <3300000>;
regulator-max-microvolt = <3300000>;
};
- regulator at 12 {
- reg = <12>;
- regulator-compatible = "ldo8";
+ ldo8 {
regulator-name = "vdd_ldo8,avdd_hdmi_pll";
regulator-min-microvolt = <1800000>;
regulator-max-microvolt = <1800000>;
};
- regulator at 13 {
- reg = <13>;
- regulator-compatible = "ldo9";
+ ldo9 {
regulator-name = "vdd_ldo9,vdd_ddr_rx,avdd_cam";
/*
* According to the Tegra 2 Automotive
@@ -404,9 +373,7 @@
regulator-always-on;
};
- regulator at 14 {
- reg = <14>;
- regulator-compatible = "ldo_rtc";
+ ldo_rtc {
regulator-name = "vdd_rtc_out";
regulator-min-microvolt = <3300000>;
regulator-max-microvolt = <3300000>;
diff --git a/arch/arm/boot/dts/tegra20-ventana.dts b/arch/arm/boot/dts/tegra20-ventana.dts
index 3e5952f..86854f1 100644
--- a/arch/arm/boot/dts/tegra20-ventana.dts
+++ b/arch/arm/boot/dts/tegra20-ventana.dts
@@ -311,37 +311,26 @@
vinldo9-supply = <&sm2_reg>;
regulators {
- #address-cells = <1>;
- #size-cells = <0>;
-
- sys_reg: regulator at 0 {
- reg = <0>;
- regulator-compatible = "sys";
+ sys_reg: sys {
regulator-name = "vdd_sys";
regulator-always-on;
};
- regulator at 1 {
- reg = <1>;
- regulator-compatible = "sm0";
+ sm0 {
regulator-name = "vdd_sm0,vdd_core";
regulator-min-microvolt = <1200000>;
regulator-max-microvolt = <1200000>;
regulator-always-on;
};
- regulator at 2 {
- reg = <2>;
- regulator-compatible = "sm1";
+ sm1 {
regulator-name = "vdd_sm1,vdd_cpu";
regulator-min-microvolt = <1000000>;
regulator-max-microvolt = <1000000>;
regulator-always-on;
};
- sm2_reg: regulator at 3 {
- reg = <3>;
- regulator-compatible = "sm2";
+ sm2_reg: sm2 {
regulator-name = "vdd_sm2,vin_ldo*";
regulator-min-microvolt = <3700000>;
regulator-max-microvolt = <3700000>;
@@ -350,86 +339,66 @@
/* LDO0 is not connected to anything */
- regulator at 5 {
- reg = <5>;
- regulator-compatible = "ldo1";
+ ldo1 {
regulator-name = "vdd_ldo1,avdd_pll*";
regulator-min-microvolt = <1100000>;
regulator-max-microvolt = <1100000>;
regulator-always-on;
};
- regulator at 6 {
- reg = <6>;
- regulator-compatible = "ldo2";
+ ldo2 {
regulator-name = "vdd_ldo2,vdd_rtc";
regulator-min-microvolt = <1200000>;
regulator-max-microvolt = <1200000>;
};
- regulator at 7 {
- reg = <7>;
- regulator-compatible = "ldo3";
+ ldo3 {
regulator-name = "vdd_ldo3,avdd_usb*";
regulator-min-microvolt = <3300000>;
regulator-max-microvolt = <3300000>;
regulator-always-on;
};
- regulator at 8 {
- reg = <8>;
- regulator-compatible = "ldo4";
+ ldo4 {
regulator-name = "vdd_ldo4,avdd_osc,vddio_sys";
regulator-min-microvolt = <1800000>;
regulator-max-microvolt = <1800000>;
regulator-always-on;
};
- regulator at 9 {
- reg = <9>;
- regulator-compatible = "ldo5";
+ ldo5 {
regulator-name = "vdd_ldo5,vcore_mmc";
regulator-min-microvolt = <2850000>;
regulator-max-microvolt = <2850000>;
regulator-always-on;
};
- regulator at 10 {
- reg = <10>;
- regulator-compatible = "ldo6";
+ ldo6 {
regulator-name = "vdd_ldo6,avdd_vdac";
regulator-min-microvolt = <1800000>;
regulator-max-microvolt = <1800000>;
};
- regulator at 11 {
- reg = <11>;
- regulator-compatible = "ldo7";
+ ldo7 {
regulator-name = "vdd_ldo7,avdd_hdmi,vdd_fuse";
regulator-min-microvolt = <3300000>;
regulator-max-microvolt = <3300000>;
};
- regulator at 12 {
- reg = <12>;
- regulator-compatible = "ldo8";
+ ldo8 {
regulator-name = "vdd_ldo8,avdd_hdmi_pll";
regulator-min-microvolt = <1800000>;
regulator-max-microvolt = <1800000>;
};
- regulator at 13 {
- reg = <13>;
- regulator-compatible = "ldo9";
+ ldo9 {
regulator-name = "vdd_ldo9,avdd_2v85,vdd_ddr_rx";
regulator-min-microvolt = <2850000>;
regulator-max-microvolt = <2850000>;
regulator-always-on;
};
- regulator at 14 {
- reg = <14>;
- regulator-compatible = "ldo_rtc";
+ ldo_rtc {
regulator-name = "vdd_rtc_out,vdd_cell";
regulator-min-microvolt = <3300000>;
regulator-max-microvolt = <3300000>;
diff --git a/arch/arm/boot/dts/tegra20-whistler.dts b/arch/arm/boot/dts/tegra20-whistler.dts
index c636d00..94a71c9 100644
--- a/arch/arm/boot/dts/tegra20-whistler.dts
+++ b/arch/arm/boot/dts/tegra20-whistler.dts
@@ -295,243 +295,182 @@
in20-supply = <&mbatt_reg>;
regulators {
- #address-cells = <1>;
- #size-cells = <0>;
-
- mbatt_reg: regulator at 0 {
- reg = <0>;
- regulator-compatible = "mbatt";
+ mbatt_reg: mbatt {
regulator-name = "vbat_pmu";
regulator-always-on;
};
- regulator at 1 {
- reg = <1>;
- regulator-compatible = "sd1";
+ sd1 {
regulator-name = "nvvdd_sv1,vdd_cpu_pmu";
regulator-min-microvolt = <1000000>;
regulator-max-microvolt = <1000000>;
regulator-always-on;
};
- regulator at 2 {
- reg = <2>;
- regulator-compatible = "sd2";
+ sd2 {
regulator-name = "nvvdd_sv2,vdd_core";
regulator-min-microvolt = <1200000>;
regulator-max-microvolt = <1200000>;
regulator-always-on;
};
- nvvdd_sv3_reg: regulator at 3 {
- reg = <3>;
- regulator-compatible = "sd3";
+ nvvdd_sv3_reg: sd3 {
regulator-name = "nvvdd_sv3";
regulator-min-microvolt = <1800000>;
regulator-max-microvolt = <1800000>;
regulator-always-on;
};
- regulator at 4 {
- reg = <4>;
- regulator-compatible = "ldo1";
+ ldo1 {
regulator-name = "nvvdd_ldo1,vddio_rx_ddr,vcore_acc";
regulator-min-microvolt = <3300000>;
regulator-max-microvolt = <3300000>;
regulator-always-on;
};
- regulator at 5 {
- reg = <5>;
- regulator-compatible = "ldo2";
+ ldo2 {
regulator-name = "nvvdd_ldo2,avdd_pll*";
regulator-min-microvolt = <1100000>;
regulator-max-microvolt = <1100000>;
regulator-always-on;
};
- regulator at 6 {
- reg = <6>;
- regulator-compatible = "ldo3";
+ ldo3 {
regulator-name = "nvvdd_ldo3,vcom_1v8b";
regulator-min-microvolt = <1800000>;
regulator-max-microvolt = <1800000>;
regulator-always-on;
};
- regulator at 7 {
- reg = <7>;
- regulator-compatible = "ldo4";
+ ldo4 {
regulator-name = "nvvdd_ldo4,avdd_usb*";
regulator-min-microvolt = <3300000>;
regulator-max-microvolt = <3300000>;
regulator-always-on;
};
- regulator at 8 {
- reg = <8>;
- regulator-compatible = "ldo5";
+ ldo5 {
regulator-name = "nvvdd_ldo5,vcore_mmc,avdd_lcd1,vddio_1wire";
regulator-min-microvolt = <2800000>;
regulator-max-microvolt = <2800000>;
regulator-always-on;
};
- regulator at 9 {
- reg = <9>;
- regulator-compatible = "ldo6";
+ ldo6 {
regulator-name = "nvvdd_ldo6,avdd_hdmi_pll";
regulator-min-microvolt = <1800000>;
regulator-max-microvolt = <1800000>;
};
- regulator at 10 {
- reg = <10>;
- regulator-compatible = "ldo7";
+ ldo7 {
regulator-name = "nvvdd_ldo7,avddio_audio";
regulator-min-microvolt = <2800000>;
regulator-max-microvolt = <2800000>;
regulator-always-on;
};
- regulator at 11 {
- reg = <11>;
- regulator-compatible = "ldo8";
+ ldo8 {
regulator-name = "nvvdd_ldo8,vcom_3v0,vcore_cmps";
regulator-min-microvolt = <3000000>;
regulator-max-microvolt = <3000000>;
};
- regulator at 12 {
- reg = <12>;
- regulator-compatible = "ldo9";
+ ldo9 {
regulator-name = "nvvdd_ldo9,avdd_cam*";
regulator-min-microvolt = <2800000>;
regulator-max-microvolt = <2800000>;
};
- regulator at 13 {
- reg = <13>;
- regulator-compatible = "ldo10";
+ ldo10 {
regulator-name = "nvvdd_ldo10,avdd_usb_ic_3v0";
regulator-min-microvolt = <3000000>;
regulator-max-microvolt = <3000000>;
regulator-always-on;
};
- regulator at 14 {
- reg = <14>;
- regulator-compatible = "ldo11";
+ ldo11 {
regulator-name = "nvvdd_ldo11,vddio_pex_clk,vcom_33,avdd_hdmi";
regulator-min-microvolt = <3300000>;
regulator-max-microvolt = <3300000>;
};
- regulator at 15 {
- reg = <15>;
- regulator-compatible = "ldo12";
+ ldo12 {
regulator-name = "nvvdd_ldo12,vddio_sdio";
regulator-min-microvolt = <2800000>;
regulator-max-microvolt = <2800000>;
regulator-always-on;
};
- regulator at 16 {
- reg = <16>;
- regulator-compatible = "ldo13";
+ ldo13 {
regulator-name = "nvvdd_ldo13,vcore_phtn,vdd_af";
regulator-min-microvolt = <2800000>;
regulator-max-microvolt = <2800000>;
};
- regulator at 17 {
- reg = <17>;
- regulator-compatible = "ldo14";
+ ldo14 {
regulator-name = "nvvdd_ldo14,avdd_vdac";
regulator-min-microvolt = <2800000>;
regulator-max-microvolt = <2800000>;
};
- regulator at 18 {
- reg = <18>;
- regulator-compatible = "ldo15";
+ ldo15 {
regulator-name = "nvvdd_ldo15,vcore_temp,vddio_hdcp";
regulator-min-microvolt = <3300000>;
regulator-max-microvolt = <3300000>;
};
- regulator at 19 {
- reg = <19>;
- regulator-compatible = "ldo16";
+ ldo16 {
regulator-name = "nvvdd_ldo16,vdd_dbrtr";
regulator-min-microvolt = <1300000>;
regulator-max-microvolt = <1300000>;
};
- regulator at 20 {
- reg = <20>;
- regulator-compatible = "ldo17";
+ ldo17 {
regulator-name = "nvvdd_ldo17,vddio_mipi";
regulator-min-microvolt = <1200000>;
regulator-max-microvolt = <1200000>;
};
- regulator at 21 {
- reg = <21>;
- regulator-compatible = "ldo18";
+ ldo18 {
regulator-name = "nvvdd_ldo18,vddio_vi,vcore_cam*";
regulator-min-microvolt = <1800000>;
regulator-max-microvolt = <1800000>;
};
- regulator at 22 {
- reg = <22>;
- regulator-compatible = "ldo19";
+ ldo19 {
regulator-name = "nvvdd_ldo19,avdd_lcd2,vddio_lx";
regulator-min-microvolt = <2800000>;
regulator-max-microvolt = <2800000>;
};
- regulator at 23 {
- reg = <23>;
- regulator-compatible = "ldo20";
+ ldo20 {
regulator-name = "nvvdd_ldo20,vddio_ddr_1v2,vddio_hsic,vcom_1v2";
regulator-min-microvolt = <1200000>;
regulator-max-microvolt = <1200000>;
regulator-always-on;
};
- regulator at 24 {
- reg = <24>;
- regulator-compatible = "out5v";
+ out5v {
regulator-name = "usb0_vbus_reg";
};
- regulator at 25 {
- reg = <25>;
- regulator-compatible = "out33v";
+ out33v {
regulator-name = "pmu_out3v3";
};
- regulator at 26 {
- reg = <26>;
- regulator-compatible = "bbat";
+ bbat {
regulator-name = "pmu_bbat";
regulator-min-microvolt = <2400000>;
regulator-max-microvolt = <2400000>;
regulator-always-on;
};
- regulator at 27 {
- reg = <27>;
- regulator-compatible = "sdby";
+ sdby {
regulator-name = "vdd_aon";
regulator-always-on;
};
- regulator at 28 {
- reg = <28>;
- regulator-compatible = "vrtc";
+ vrtc {
regulator-name = "vrtc,pmu_vccadc";
regulator-always-on;
};
diff --git a/arch/arm/boot/dts/tegra30-cardhu.dtsi b/arch/arm/boot/dts/tegra30-cardhu.dtsi
index d10c9c5..b1271a8 100644
--- a/arch/arm/boot/dts/tegra30-cardhu.dtsi
+++ b/arch/arm/boot/dts/tegra30-cardhu.dtsi
@@ -171,56 +171,41 @@
vccio-supply = <&vdd_ac_bat_reg>;
regulators {
- #address-cells = <1>;
- #size-cells = <0>;
-
- vdd1_reg: regulator at 0 {
- reg = <0>;
- regulator-compatible = "vdd1";
+ vdd1_reg: vdd1 {
regulator-name = "vddio_ddr_1v2";
regulator-min-microvolt = <1200000>;
regulator-max-microvolt = <1200000>;
regulator-always-on;
};
- vdd2_reg: regulator at 1 {
- reg = <1>;
- regulator-compatible = "vdd2";
+ vdd2_reg: vdd2 {
regulator-name = "vdd_1v5_gen";
regulator-min-microvolt = <1500000>;
regulator-max-microvolt = <1500000>;
regulator-always-on;
};
- vddctrl_reg: regulator at 2 {
- reg = <2>;
- regulator-compatible = "vddctrl";
+ vddctrl_reg: vddctrl {
regulator-name = "vdd_cpu,vdd_sys";
regulator-min-microvolt = <1000000>;
regulator-max-microvolt = <1000000>;
regulator-always-on;
};
- vio_reg: regulator at 3 {
- reg = <3>;
- regulator-compatible = "vio";
+ vio_reg: vio {
regulator-name = "vdd_1v8_gen";
regulator-min-microvolt = <1800000>;
regulator-max-microvolt = <1800000>;
regulator-always-on;
};
- ldo1_reg: regulator at 4 {
- reg = <4>;
- regulator-compatible = "ldo1";
+ ldo1_reg: ldo1 {
regulator-name = "vdd_pexa,vdd_pexb";
regulator-min-microvolt = <1050000>;
regulator-max-microvolt = <1050000>;
};
- ldo2_reg: regulator at 5 {
- reg = <5>;
- regulator-compatible = "ldo2";
+ ldo2_reg: ldo2 {
regulator-name = "vdd_sata,avdd_plle";
regulator-min-microvolt = <1050000>;
regulator-max-microvolt = <1050000>;
@@ -228,44 +213,34 @@
/* LDO3 is not connected to anything */
- ldo4_reg: regulator at 7 {
- reg = <7>;
- regulator-compatible = "ldo4";
+ ldo4_reg: ldo4 {
regulator-name = "vdd_rtc";
regulator-min-microvolt = <1200000>;
regulator-max-microvolt = <1200000>;
regulator-always-on;
};
- ldo5_reg: regulator at 8 {
- reg = <8>;
- regulator-compatible = "ldo5";
+ ldo5_reg: ldo5 {
regulator-name = "vddio_sdmmc,avdd_vdac";
regulator-min-microvolt = <3300000>;
regulator-max-microvolt = <3300000>;
regulator-always-on;
};
- ldo6_reg: regulator at 9 {
- reg = <9>;
- regulator-compatible = "ldo6";
+ ldo6_reg: ldo6 {
regulator-name = "avdd_dsi_csi,pwrdet_mipi";
regulator-min-microvolt = <1200000>;
regulator-max-microvolt = <1200000>;
};
- ldo7_reg: regulator at 10 {
- reg = <10>;
- regulator-compatible = "ldo7";
+ ldo7_reg: ldo7 {
regulator-name = "vdd_pllm,x,u,a_p_c_s";
regulator-min-microvolt = <1200000>;
regulator-max-microvolt = <1200000>;
regulator-always-on;
};
- ldo8_reg: regulator at 11 {
- reg = <11>;
- regulator-compatible = "ldo8";
+ ldo8_reg: ldo8 {
regulator-name = "vdd_ddr_hs";
regulator-min-microvolt = <1000000>;
regulator-max-microvolt = <1000000>;
--
1.7.0.4
^ permalink raw reply related
* [PATCH] ARM: pxa: Fix build error caused by sram.h rename
From: Chris Ball @ 2012-10-02 19:03 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1347368390-31252-7-git-send-email-arnd@arndb.de>
Commit 293b2da1b61 ("ARM: pxa: move platform_data definitions")
renamed arch/arm/mach-mmp/include/mach/sram.h to
include/linux/platform_data/dma-mmp_tdma.h, but didn't update
mmp-pcm.c which uses the header. Fix the build error.
Signed-off-by: Chris Ball <cjb@laptop.org>
---
sound/soc/pxa/mmp-pcm.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/sound/soc/pxa/mmp-pcm.c b/sound/soc/pxa/mmp-pcm.c
index 73ac546..e834faf 100644
--- a/sound/soc/pxa/mmp-pcm.c
+++ b/sound/soc/pxa/mmp-pcm.c
@@ -15,13 +15,13 @@
#include <linux/slab.h>
#include <linux/dma-mapping.h>
#include <linux/dmaengine.h>
+#include <linux/platform_data/dma-mmp_tdma.h>
#include <linux/platform_data/mmp_audio.h>
#include <sound/pxa2xx-lib.h>
#include <sound/core.h>
#include <sound/pcm.h>
#include <sound/pcm_params.h>
#include <sound/soc.h>
-#include <mach/sram.h>
#include <sound/dmaengine_pcm.h>
struct mmp_dma_data {
--
Chris Ball <cjb@laptop.org> <http://printf.net/>
One Laptop Per Child
^ permalink raw reply related
* [PATCH v6 3/5] watchdog: at91sam9_wdt: add device tree support
From: Jean-Christophe PLAGNIOL-VILLARD @ 2012-10-02 19:00 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CAHkwnC83DcKXZOtLse_xnYe7zOZ5qwGJVimLkBzDwSJ7Y5vL_Q@mail.gmail.com>
On 17:04 Tue 02 Oct , Fabio Porcedda wrote:
> On Mon, Oct 1, 2012 at 3:06 PM, Andrew Lunn <andrew@lunn.ch> wrote:
> > On Mon, Oct 01, 2012 at 02:54:55PM +0200, Fabio Porcedda wrote:
> >> On Mon, Oct 1, 2012 at 2:48 PM, Fabio Porcedda <fabio.porcedda@gmail.com> wrote:
> >> > On Mon, Oct 1, 2012 at 2:45 PM, Andrew Lunn <andrew@lunn.ch> wrote:
> >> >> On Mon, Oct 01, 2012 at 02:24:39PM +0200, Fabio Porcedda wrote:
> >> >>> Tested on an at91sam9260 board (evk-pro3)
> >> >>>
> >> >>> Signed-off-by: Fabio Porcedda <fabio.porcedda@gmail.com>
> >> >>> ---
> >> >>> .../devicetree/bindings/watchdog/atmel-wdt.txt | 19 +++++++++++++++++++
> >> >>> drivers/watchdog/at91sam9_wdt.c | 21 +++++++++++++++++++++
> >> >>> 2 files changed, 40 insertions(+)
> >> >>> create mode 100644 Documentation/devicetree/bindings/watchdog/atmel-wdt.txt
> >> >>>
> >> >>> diff --git a/Documentation/devicetree/bindings/watchdog/atmel-wdt.txt b/Documentation/devicetree/bindings/watchdog/atmel-wdt.txt
> >> >>> new file mode 100644
> >> >>> index 0000000..65c1755
> >> >>> --- /dev/null
> >> >>> +++ b/Documentation/devicetree/bindings/watchdog/atmel-wdt.txt
> >> >>> @@ -0,0 +1,19 @@
> >> >>> +* Atmel Watchdog Timers
> >> >>> +
> >> >>> +** at91sam9-wdt
> >> >>> +
> >> >>> +Required properties:
> >> >>> +- compatible: must be "atmel,at91sam9260-wdt".
> >> >>> +- reg: physical base address of the controller and length of memory mapped
> >> >>> + region.
> >> >>> +
> >> >>> +Optional properties:
> >> >>> +- timeout: contains the watchdog timeout in seconds.
> >> >>> +
> >> >>> +Example:
> >> >>> +
> >> >>> + watchdog at fffffd40 {
> >> >>> + compatible = "atmel,at91sam9260-wdt";
> >> >>> + reg = <0xfffffd40 0x10>;
> >> >>> + timeout = <10>;
> >> >>> + };
> >> >>> diff --git a/drivers/watchdog/at91sam9_wdt.c b/drivers/watchdog/at91sam9_wdt.c
> >> >>> index 05e1be8..c9e6bfa 100644
> >> >>> --- a/drivers/watchdog/at91sam9_wdt.c
> >> >>> +++ b/drivers/watchdog/at91sam9_wdt.c
> >> >>> @@ -32,6 +32,7 @@
> >> >>> #include <linux/timer.h>
> >> >>> #include <linux/bitops.h>
> >> >>> #include <linux/uaccess.h>
> >> >>> +#include <linux/of.h>
> >> >>>
> >> >>> #include "at91sam9_wdt.h"
> >> >>>
> >> >>> @@ -254,6 +255,14 @@ static struct miscdevice at91wdt_miscdev = {
> >> >>> .fops = &at91wdt_fops,
> >> >>> };
> >> >>>
> >> >>> +static inline void __init at91wdt_probe_dt(struct device_node *node)
> >> >>> +{
> >> >>> + if (!node)
> >> >>> + return;
> >> >>> +
> >> >>> + of_property_read_u32(node, "timeout", &heartbeat);
> >> >>> +}
> >> >>> +
> >> >>
> >> >> In patch #1 you add a function to do this, and then you don't make use
> >> >> of it here ?
> >> >>
> >> >> Or am i missing something?
> >> >
> >> > I'm using it on the patch #2 for the orion_wdt driver.
> >> > Do you think it's better to join the #1 and the #2 patch?
> >> >
> >> > Best regards
> >> > --
> >> > Fabio Porcedda
> >>
> >> I'm sorry, only now i understand your question.
> >> The at91sam9_wdt driver don't use the watchdog core framework si i
> >> can't use that function cleanly.
> >
> >> The patch #1 and #2 are for introducing the same property as the
> >> at91sam9_wdt driver.
> >
> > So maybe split this up into two different patchsets. One patchset to
> > add the helper function, and the use of this helper to all watchdog
> > divers that can use it. I think the following drivers should be
> > modified:
> >
> > orion_wdt.c
> > pnx4008_wdt.c
> > s3c2410_wdt.c
> >
> > In a second patchset, convert the AT91SAM9 driver over to the watchdog
> > core framework, and then use the helper function.
>
> I was thinking to add a more generic helper function like this:
>
> static inline void watchdog_get_dttimeout(struct device_node *node,
> u32 *timeout)
> {
> if (node)
> of_property_read_u32(node, "timeout", &wdd->timeout);
> }
>
> This way i can use this helper function in the at91sam9_wdt driver too.
> What do you think?
timeout_sec and this can be move at of.h level
as this is not watchdog framework secific
Best Regards,
J.
^ permalink raw reply
* [PATCH] xen: resolve merge conflict with 617276307cd4cdb9a95c77efaa3063695af63aa7
From: Konrad Rzeszutek Wilk @ 2012-10-02 18:51 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <alpine.DEB.2.02.1210021724300.29232@kaball.uk.xensource.com>
On Tue, Oct 2, 2012 at 1:29 PM, Stefano Stabellini
<stefano.stabellini@eu.citrix.com> wrote:
> The Xen tree tries to add a line to
> arch/arm/mach-vexpress/Makefile.boot that has been removed by the
> following commit in Linus' master:
>
> commit 617276307cd4cdb9a95c77efaa3063695af63aa7
> Author: Rob Herring <rob.herring@calxeda.com>
> Date: Thu Sep 6 13:43:04 2012 -0500
>
> ARM: vexpress: convert to multi-platform
>
> In fact the dts Makefile is now arch/arm/boot/dts/Makefile, as per
> commit 9cd11c0c47b8690b47e7573311ce5c483cb344ed.
>
>
> This is the merge resolution patch.
>
> Signed-off-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Great. Thanks for posting it!
^ permalink raw reply
* [kvmarm] [PATCH v2 08/10] ARM: KVM: VGIC initialisation code
From: Peter Maydell @ 2012-10-02 18:31 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <C24866D7-ED20-402F-B769-1FE4D5561C77@virtualopensystems.com>
On 2 October 2012 18:55, Christoffer Dall <c.dall@virtualopensystems.com> wrote:
> On Oct 2, 2012, at 6:25 AM, Marc Zyngier <marc.zyngier@arm.com> wrote:
>> On Tue, 2 Oct 2012 10:24:13 +0100, Will Deacon <will.deacon@arm.com>
>>> We really don't want the physical memory map for the guest hardwired in
>> the
>>> kernel. Please find a way to parameterise this from userspace.
>>
>> Yes, this is a known problem. KVM doesn't offer a standard way of passing
>> the address of an interrupt controller (none of the other architectures
>> have it memory mapped).
>>
>> We probably need a separate ioctl
>
> Thoughts on how to make this API flexible enough?
>
> Can we somehow provide a device tree to the host kernel, which would
> be the same device tree the guest uses, which may also describe virtio
> features, or is this completely sci fi?
I'm not really in favour of trying to shoehorn device trees in here
(among other things, the virtual machine we create should be the actual
machine matching the hardware, not something randomly generated
from the device tree. Also requiring userspace to manufacture a
device tree from scratch is kind of awkward: there's no reason
the guest has to be using one, and it's a lot of effort to go to
to pass a single address into the kernel...)
We probably want to be passing in the "base of the cpu-internal
peripherals", rather than "base of the GIC" specifically. For the
A15 these are the same thing, but that's not inherent [compare the
A9 which has more devices at fixed offsets from a configurable
base address].
On hardware this is done by having an input signal that's sampled
at reset that tells the CPU where the peripherals are; is there
an equivalent of that for any other CPU properties that we have
already in the KVM API?
-- PMM
^ permalink raw reply
* Booting vanilla kernel on the beaglebone
From: Richard Cochran @ 2012-10-02 17:58 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <50693ECD.4000000@ti.com>
On Mon, Oct 01, 2012 at 12:27:17PM +0530, Vaibhav Hiremath wrote:
>
> As far as kernel is concerned, All the required patches have been merged
> for v3.7, so if you use linux-next/master branch, you should be able to
> boot without any issues. You just need to apply one minor patch which is
> left behind - https://patchwork.kernel.org/patch/1499411/
>
> I have just tested it to cross-check and it boots up fine with
> linux-next/master branch. I have pasted boot log below for your reference.
Thanks, this is just the information that I was lookings for. In the
mean time I have something working based on the arago kernel, and I
will wait until 3.7-rc1 to try the vanilla kernel again.
Cheers,
Richard
^ permalink raw reply
* [PATCH v2 08/10] ARM: KVM: VGIC initialisation code
From: Christoffer Dall @ 2012-10-02 17:55 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <b4b11d71544812cff978b3457a99b90e@localhost>
On Oct 2, 2012, at 6:25 AM, Marc Zyngier <marc.zyngier@arm.com> wrote:
> On Tue, 2 Oct 2012 10:24:13 +0100, Will Deacon <will.deacon@arm.com>
> wrote:
>> On Mon, Oct 01, 2012 at 10:14:26AM +0100, Christoffer Dall wrote:
>>> From: Marc Zyngier <marc.zyngier@arm.com>
>>>
>>> Add the init code for the hypervisor, the virtual machine, and
>>> the virtual CPUs.
>>>
>>> An interrupt handler is also wired to allow the VGIC maintenance
>>> interrupts, used to deal with level triggered interrupts and LR
>>> underflows.
>>>
>>> Signed-off-by: Marc Zyngier <marc.zyngier@arm.com>
>>> Signed-off-by: Christoffer Dall <c.dall@virtualopensystems.com>
>>> ---
>>
>> [...]
>>
>>> diff --git a/arch/arm/kvm/vgic.c b/arch/arm/kvm/vgic.c
>>> index b52d4c2..fc2a138 100644
>>> --- a/arch/arm/kvm/vgic.c
>>> +++ b/arch/arm/kvm/vgic.c
>>> @@ -20,7 +20,14 @@
>>> #include <linux/kvm_host.h>
>>> #include <linux/interrupt.h>
>>> #include <linux/io.h>
>>> +#include <linux/of.h>
>>> +#include <linux/of_address.h>
>>> +#include <linux/of_irq.h>
>>> +
>>> #include <asm/kvm_emulate.h>
>>> +#include <asm/hardware/gic.h>
>>> +#include <asm/kvm_arm.h>
>>> +#include <asm/kvm_mmu.h>
>>>
>>> /*
>>> * How the whole thing works (courtesy of Christoffer Dall):
>>> @@ -61,6 +68,13 @@
>>> /* Temporary hacks, need to be provided by userspace emulation */
>>> #define VGIC_DIST_BASE 0x2c001000
>>> #define VGIC_DIST_SIZE 0x1000
>>> +#define VGIC_CPU_BASE 0x2c002000
>>> +#define VGIC_CPU_SIZE 0x2000
>>
>> We really don't want the physical memory map for the guest hardwired in
> the
>> kernel. Please find a way to parameterise this from userspace.
>
> Yes, this is a known problem. KVM doesn't offer a standard way of passing
> the address of an interrupt controller (none of the other architectures
> have it memory mapped).
>
> We probably need a separate ioctl
Thoughts on how to make this API flexible enough?
Can we somehow provide a device tree to the host kernel, which would be the same device tree the guest uses, which may also describe virtio features, or is this completely sci fi?
-Christoffer
^ permalink raw reply
* [RFC PATCH 1/2] ARM: use generic strnlen_user and strncpy_from_user functions
From: Uwe Kleine-König @ 2012-10-02 17:53 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1339169935-31775-2-git-send-email-will.deacon@arm.com>
Hello,
On Fri, Jun 08, 2012 at 04:38:54PM +0100, Will Deacon wrote:
> This patch implements the word-at-a-time interface for ARM using the
> same algorithm as x86. Although we have a clz instruction from ARMv5,
> this only saves us one mov instruction when building with Thumb-2 and
> makes no difference when targetting ARM, so we use the magic 0x0ff0001
> constant for all CPUs. For big-endian configurations, we use the
> implementation from asm-generic.
>
> With this implemented, we can replace our byte-at-a-time strnlen_user
> and strncpy_from_user functions with the optimised generic versions.
This patch is in Linus tree as 8c56cc8be5b38e3684eba96dc9b3f7ca7e495755
now and it broke my booting my Cortex-M3 machine. I didn't debug that
yet, but wanted to let you know already now before I call it a day.
> +#define user_addr_max() \
> + (segment_eq(get_fs(), USER_DS) ? TASK_SIZE : ~0UL)
> +
I think this is the problem as for no-mmu USER_DS == KERNEL_DS. I will
take a look tomorrow.
Best regards
Uwe
--
Pengutronix e.K. | Uwe Kleine-K?nig |
Industrial Linux Solutions | http://www.pengutronix.de/ |
^ permalink raw reply
* [PATCH] [ARM] Build failure CONFIG_ARCH_KIRKWOOD_DT relies on CACHE_FEROCEON_L2
From: Jason Gunthorpe @ 2012-10-02 17:50 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CAOesGMhQpqdCRoV85vW+7THstbx+HWmCkR3Q6bpK6uLEmhKqfw@mail.gmail.com>
On Mon, Oct 01, 2012 at 07:31:58AM -0700, Olof Johansson wrote:
> Ah. diff took out the #else in the middle and I didn't look at the
> file. Obviously correct as-is.
>
> In some other places we choose to put the ifdef outside the function
> and provide a static inline stub in the header file instead. Either
> way works fine though.
I don't actually expect anyone will run CONFIG_ARCH_KIRKWOOD_DT
without CACHE_FEROCEON_L2 - I had thought about just forcing kconfig
to include CACHE_FEROCEON_L2, but figured there was some reason they
were separate..
Is there anything further I should do to get this patch upstream?
Thanks,
Jason
^ permalink raw reply
* [PATCH] [ARM] Use AT() in the linker script to create correct program headers
From: Jason Gunthorpe @ 2012-10-02 17:47 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20121002102346.GB2108@linaro.org>
On Tue, Oct 02, 2012 at 11:23:46AM +0100, Dave Martin wrote:
> > Well, no, it boots ELFs, so it can boot anything, with any memory
> > layout. A 2nd stage loader would be required to boot standard kernels,
> > that loader would be an ELF with 1 section for the 2nd stage, 1
> > section for the zImage and 1 section for the initrd, with proper load
> > headers.
>
> Don't you already have to treat Linux as a special case though? How
> do you know where to load ATAGs, DT and/or initramfs, and how to
> initalise the registers? None of that is part of any ELF specification,
> and would be inappropriate if you boot any non-linux images.
Experience with our PPC systems has been that linking the DTB into
vmlinux is the way to go - so we have a trivally small,
non-upstreamble change (for PPC and ARM) to put the DTB(s) in vmlinux
and capture the CPU registers values (entry call function arguments)
that are set from the bootloader.
Some DTB fixup code (supported by the OF kernel routines) in vmlinux
edits the DTB chosen node to include the information from the
bootloader.
>From there any other DTB fixups (eg fetching a MAC address from I2C)
plus other register initializations are done in Linux (typically by
the upstream drivers, though not 100%), with the MMU on, with full
kernel services. This is a much easier development environment :)
All in all it is basically about 100 lines of code to do what I've
described in vmlinux. This is dramatically less code than would be
required if we tried to conform to the standard vmlinux boot protocol.
> As you observe, GNU ld behaviour in this area tends to be rather patchily
> specified, buggy or both. That does argue in favour of reusing the
> same techniques already used for other arches, though.
It is good to know PHDRS seems to be working better now, maybe things
can migrate someday!
> A question does occur to me: do your changes work with XIP_KERNEL?
> I'm not very familiar with XIP_KERNEL myself, so I'm currently not
> clear on whether there's an impact here.
I looked at the XIP defines and they didn't seem to conflict. Since
this change only effects the values in the LOAD headers, not the
actual image I doubt it has any impact.
> Beyond this, I think the approach doesn't look unreasonable.
Great, should I do anything further to get this patch into mainline.
> You store vmlinux.gz in a cramfs? Is that a typo, or have you already
> compressed the kernel twice?
The compression can either be intrisic to cramfs or a raw elf that has
been gzip'd.
Jason
^ permalink raw reply
* [PATCH] ARM: hw_breakpoint: Clear breakpoints before enabling monitor mode
From: Stephen Boyd @ 2012-10-02 17:47 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20121002091301.GA8847@mudshark.cambridge.arm.com>
On 10/02/12 02:13, Will Deacon wrote:
>
> Thanks Stephen. I've also got some patches for OS save/restore of the debug
> registers using the various hardware locking and readout mechanisms, so that
> debug state can be persisted across low-power states.
>
> Do any of the Qualcomm chips (v7 as opposed to v7.1) implement the save/restore
> registers?
Yes, we have save and restore registers.
--
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
hosted by The Linux Foundation
^ permalink raw reply
* [PATCH] xen: resolve merge conflict with 617276307cd4cdb9a95c77efaa3063695af63aa7
From: Stefano Stabellini @ 2012-10-02 17:29 UTC (permalink / raw)
To: linux-arm-kernel
The Xen tree tries to add a line to
arch/arm/mach-vexpress/Makefile.boot that has been removed by the
following commit in Linus' master:
commit 617276307cd4cdb9a95c77efaa3063695af63aa7
Author: Rob Herring <rob.herring@calxeda.com>
Date: Thu Sep 6 13:43:04 2012 -0500
ARM: vexpress: convert to multi-platform
In fact the dts Makefile is now arch/arm/boot/dts/Makefile, as per
commit 9cd11c0c47b8690b47e7573311ce5c483cb344ed.
This is the merge resolution patch.
Signed-off-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
diff --cc arch/arm/boot/dts/Makefile
index 43c084c,0000000..4745c1f
mode 100644,000000..100644
--- a/arch/arm/boot/dts/Makefile
+++ b/arch/arm/boot/dts/Makefile
@@@ -1,101 -1,0 +1,102 @@@
+ifeq ($(CONFIG_OF),y)
+
+dtb-$(CONFIG_ARCH_AT91) += aks-cdu.dtb \
+ at91sam9263ek.dtb \
+ at91sam9g20ek_2mmc.dtb \
+ at91sam9g20ek.dtb \
+ at91sam9g25ek.dtb \
+ at91sam9m10g45ek.dtb \
+ at91sam9n12ek.dtb \
+ ethernut5.dtb \
+ evk-pro3.dtb \
+ kizbox.dtb \
+ tny_a9260.dtb \
+ tny_a9263.dtb \
+ tny_a9g20.dtb \
+ usb_a9260.dtb \
+ usb_a9263.dtb \
+ usb_a9g20.dtb
+dtb-$(CONFIG_ARCH_BCM2835) += bcm2835-rpi-b.dtb
+dtb-$(CONFIG_ARCH_EXYNOS) += exynos4210-origen.dtb \
+ exynos4210-smdkv310.dtb \
+ exynos4210-trats.dtb \
+ exynos5250-smdk5250.dtb
+dtb-$(CONFIG_ARCH_HIGHBANK) += highbank.dtb
+dtb-$(CONFIG_ARCH_IMX5) += imx51-babbage.dtb \
+ imx53-ard.dtb \
+ imx53-evk.dtb \
+ imx53-qsb.dtb \
+ imx53-smd.dtb
+dtb-$(CONFIG_SOC_IMX6Q) += imx6q-arm2.dtb \
+ imx6q-sabrelite.dtb \
+ imx6q-sabresd.dtb
+dtb-$(CONFIG_ARCH_LPC32XX) += ea3250.dtb phy3250.dtb
+dtb-$(CONFIG_ARCH_KIRKWOOD) += kirkwood-dns320.dtb \
+ kirkwood-dns325.dtb \
+ kirkwood-dreamplug.dtb \
+ kirkwood-goflexnet.dtb \
+ kirkwood-ib62x0.dtb \
+ kirkwood-iconnect.dtb \
+ kirkwood-lschlv2.dtb \
+ kirkwood-lsxhl.dtb \
+ kirkwood-ts219-6281.dtb \
+ kirkwood-ts219-6282.dtb
+dtb-$(CONFIG_ARCH_MSM) += msm8660-surf.dtb \
+ msm8960-cdp.dtb
+dtb-$(CONFIG_ARCH_MVEBU) += armada-370-db.dtb \
+ armada-xp-db.dtb
+dtb-$(CONFIG_ARCH_MXC) += imx51-babbage.dtb \
+ imx53-ard.dtb \
+ imx53-evk.dtb \
+ imx53-qsb.dtb \
+ imx53-smd.dtb \
+ imx6q-arm2.dtb \
+ imx6q-sabrelite.dtb \
+ imx6q-sabresd.dtb
+dtb-$(CONFIG_ARCH_MXS) += imx23-evk.dtb \
+ imx23-olinuxino.dtb \
+ imx23-stmp378x_devb.dtb \
+ imx28-apx4devkit.dtb \
+ imx28-cfa10036.dtb \
+ imx28-cfa10049.dtb \
+ imx28-evk.dtb \
+ imx28-m28evk.dtb \
+ imx28-tx28.dtb
+dtb-$(CONFIG_ARCH_OMAP2PLUS) += omap2420-h4.dtb \
+ omap3-beagle-xm.dtb \
+ omap3-evm.dtb \
+ omap3-tobi.dtb \
+ omap4-panda.dtb \
+ omap4-pandaES.dtb \
+ omap4-var_som.dtb \
+ omap4-sdp.dtb \
+ omap5-evm.dtb
+dtb-$(CONFIG_ARCH_PRIMA2) += prima2-evb.dtb
+dtb-$(CONFIG_ARCH_U8500) += snowball.dtb
+dtb-$(CONFIG_ARCH_SHMOBILE) += emev2-kzm9d.dtb \
+ r8a7740-armadillo800eva.dtb \
+ sh73a0-kzm9g.dtb
+dtb-$(CONFIG_ARCH_SPEAR13XX) += spear1310-evb.dtb \
+ spear1340-evb.dtb
+dtb-$(CONFIG_ARCH_SPEAR3XX)+= spear300-evb.dtb \
+ spear310-evb.dtb \
+ spear320-evb.dtb
+dtb-$(CONFIG_ARCH_SPEAR6XX)+= spear600-evb.dtb
+dtb-$(CONFIG_ARCH_TEGRA) += tegra20-harmony.dtb \
+ tegra20-medcom-wide.dtb \
+ tegra20-paz00.dtb \
+ tegra20-plutux.dtb \
+ tegra20-seaboard.dtb \
+ tegra20-tec.dtb \
+ tegra20-trimslice.dtb \
+ tegra20-ventana.dtb \
+ tegra20-whistler.dtb \
+ tegra30-cardhu-a02.dtb \
+ tegra30-cardhu-a04.dtb
+dtb-$(CONFIG_ARCH_VEXPRESS) += vexpress-v2p-ca5s.dtb \
+ vexpress-v2p-ca9.dtb \
+ vexpress-v2p-ca15-tc1.dtb \
- vexpress-v2p-ca15_a7.dtb
++ vexpress-v2p-ca15_a7.dtb \
++ xenvm-4.2.dtb
+
+endif
^ permalink raw reply
* [alsa-devel] [PATCH 2/3] ASoC: Davinci: pcm: add support for sram-support-less platforms
From: Matt Porter @ 2012-10-02 17:28 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <506B1B46.2070006@gmail.com>
On Tue, Oct 02, 2012 at 06:50:14PM +0200, Daniel Mack wrote:
> On 02.10.2012 18:41, Matt Porter wrote:
> > On Tue, Oct 02, 2012 at 03:42:47PM +0200, Daniel Mack wrote:
> >> On 02.10.2012 13:06, Sekhar Nori wrote:
> >>> On 10/2/2012 4:03 PM, Daniel Mack wrote:
> >>>> On 02.10.2012 11:37, Mark Brown wrote:
> >>>>> On Tue, Oct 02, 2012 at 10:48:53AM +0300, Peter Ujfalusi wrote:
> >>>>>
> >>>>>> I also agree that ifdef is not a good solution.
> >>>>>> It is better to have this information passed as device_data and via DT it can
> >>>>>> be decided based on the compatible property for the device.
> >>>>>
> >>>>> That's not really the problem here - the problem is that the APIs used
> >>>>> to get the SRAM are DaVinci only so it's not possible to build on OMAP
> >>>>> or other platforms. The SRAM code needs to move to a standard API.
> >>>>
> >>>> What about following Matt Porter's idea and ignore the SRAM code
> >>>> entirely and port the entire PCM code to generic dmaengine code first?
> >>>> The EDMA driver needs to learn support for cyclic DMA for that, and I
> >>>> might give that a try in near future.
> >>>>
> >>>> Later on, the SRAM ping-pong code can get added back using genalloc
> >>>> functions, as Sekhar proposed. That needs to be done by someone who has
> >>>> access to a Davinci board though, I only have a AM33xx/OMAP here.
> >>>
> >>> We cannot "get rid" of SRAM code and add it back "later". It is required
> >>> for most DaVinci parts. The SRAM code can be converted to use genalloc
> >>> (conversion should be straightforward and I can help test it) and the
> >>> code that uses SRAM can probably keep using the private EDMA API till
> >>> the dmaengine EDMA driver has cyclic DMA support. Matt has already
> >>> posted patches to move private EDMA APIs to a common location. That
> >>> should keep AM335x build from breaking. Is this something that is feasible?
> >>
> >> Yes - by "later" I just meant in a subsequent patch. But you're probably
> >> right, we can also do that first.
> >>
> >> I'm looking at that right now and the problem seems that we don't have a
> >> sane way to dynamically look up gen_pools independently of the actual
> >> run-time platform. All users of gen_pools seem to know which platform
> >> they run on and access a platform-specific pool. So I don't currently
> >> see how we could implement multi-platform code, gen_pools are fine but
> >> don't solve the problem here.
> >>
> >> Would it be an idea to add a char* member to gen_pools and a function
> >> that can be used to dynamically look it up again? If a buffer with a
> >> certain name exists, we can use it and install that ping-pong buffer,
> >> otherwise we just don't. While that would be easy to do, it's a
> >> tree-wide change.
> >>
> >> Is there a better way that I miss?
> >
> > At the high level there's two platform models we have to handle, the
> > boot from board file !DT case, and then the boot from DT case. Since
> > Davinci is just starting DT conversion, we mostly care about the !DT
> > base in which the struct gen_pool * is passed in pdata to the ASoC
> > driver. It is then selectable on a per-platform basis where the decision
> > should be made.
> >
> > Given a separate discussion with Sekhar, we're only going to have one
> > SRAM pool on any DaVinci part right now...this was only a question on
> > L138 anyway. But regardless, the created gen_pool will be passed via
> > pdata.
>
> I thought about this too, as mmp does it that way.
>
> > Since DT conversion is starting and we need to consider that now,
> > the idea there is to use the DT-based generic sram driver [1] such that
> > when we do boot from DT on Davinci, the genpool is provided via phandle
> > and the pointer extracted with the OF helpers that are part of the
> > series.
>
> A phandle is the cleanest way I think, yes.
See the of_get_named_gen_pool() helper example in the series
http://comments.gmane.org/gmane.linux.kernel/1352210
> > That's pretty much it. I'm reworking the backend support as discussed
> > with Sekhar wrt to my uio_pruss series. I can post a standalone series
> > that just replaces sram_* with genalloc for davinci ASoC.
>
> As you can also test it, it would be easiest if you came up with a patch
> for that, yes. I can have a look at the dma bits laters, once my OMAP
> board finally works with the code as it currently stands. I'm still
> fighting with the mcasp driver right now ...
Ok. Also, as Sekhar pointed out, dmaengine itself isn't a blocker since
we can have AM33xx use the private EDMA API for ASoC until I finish
cyclic DMA support. Handling the ping-pong and normal case transparently
within the dmaengine driver will require a further look but at least
genalloc is our first step there.
-Matt
^ permalink raw reply
* make dtbs in linus/master
From: Olof Johansson @ 2012-10-02 16:59 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <alpine.DEB.2.02.1210021725320.29232@kaball.uk.xensource.com>
On Tue, Oct 2, 2012 at 9:36 AM, Stefano Stabellini
<stefano.stabellini@eu.citrix.com> wrote:
> Hello,
> I am testing linus/master after the recent merge with the arm-soc tree
> and I find that if I choose:
>
> ARM system type
> 1. Allow multiple platforms to be selected (ARCH_MULTIPLATFORM) (NEW)
> 2. ARM Ltd. Integrator family (ARCH_INTEGRATOR)
> 3. ARM Ltd. RealView family (ARCH_REALVIEW)
>> 4. ARM Ltd. Versatile family (ARCH_VERSATILE)
>
> in my kernel config, then "make dtbs" doesn't work.
> However if I choose ARCH_MULTIPLATFORM then it works properly.
>
> Is it expected?
Yes, because versatile does not list any device tree files to build in
the makefile (arch/arm/boot/dts/Makefile)
-Olof
^ permalink raw reply
* [alsa-devel] [PATCH 2/3] ASoC: Davinci: pcm: add support for sram-support-less platforms
From: Daniel Mack @ 2012-10-02 16:50 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20121002164116.GT5641@beef>
On 02.10.2012 18:41, Matt Porter wrote:
> On Tue, Oct 02, 2012 at 03:42:47PM +0200, Daniel Mack wrote:
>> On 02.10.2012 13:06, Sekhar Nori wrote:
>>> On 10/2/2012 4:03 PM, Daniel Mack wrote:
>>>> On 02.10.2012 11:37, Mark Brown wrote:
>>>>> On Tue, Oct 02, 2012 at 10:48:53AM +0300, Peter Ujfalusi wrote:
>>>>>
>>>>>> I also agree that ifdef is not a good solution.
>>>>>> It is better to have this information passed as device_data and via DT it can
>>>>>> be decided based on the compatible property for the device.
>>>>>
>>>>> That's not really the problem here - the problem is that the APIs used
>>>>> to get the SRAM are DaVinci only so it's not possible to build on OMAP
>>>>> or other platforms. The SRAM code needs to move to a standard API.
>>>>
>>>> What about following Matt Porter's idea and ignore the SRAM code
>>>> entirely and port the entire PCM code to generic dmaengine code first?
>>>> The EDMA driver needs to learn support for cyclic DMA for that, and I
>>>> might give that a try in near future.
>>>>
>>>> Later on, the SRAM ping-pong code can get added back using genalloc
>>>> functions, as Sekhar proposed. That needs to be done by someone who has
>>>> access to a Davinci board though, I only have a AM33xx/OMAP here.
>>>
>>> We cannot "get rid" of SRAM code and add it back "later". It is required
>>> for most DaVinci parts. The SRAM code can be converted to use genalloc
>>> (conversion should be straightforward and I can help test it) and the
>>> code that uses SRAM can probably keep using the private EDMA API till
>>> the dmaengine EDMA driver has cyclic DMA support. Matt has already
>>> posted patches to move private EDMA APIs to a common location. That
>>> should keep AM335x build from breaking. Is this something that is feasible?
>>
>> Yes - by "later" I just meant in a subsequent patch. But you're probably
>> right, we can also do that first.
>>
>> I'm looking at that right now and the problem seems that we don't have a
>> sane way to dynamically look up gen_pools independently of the actual
>> run-time platform. All users of gen_pools seem to know which platform
>> they run on and access a platform-specific pool. So I don't currently
>> see how we could implement multi-platform code, gen_pools are fine but
>> don't solve the problem here.
>>
>> Would it be an idea to add a char* member to gen_pools and a function
>> that can be used to dynamically look it up again? If a buffer with a
>> certain name exists, we can use it and install that ping-pong buffer,
>> otherwise we just don't. While that would be easy to do, it's a
>> tree-wide change.
>>
>> Is there a better way that I miss?
>
> At the high level there's two platform models we have to handle, the
> boot from board file !DT case, and then the boot from DT case. Since
> Davinci is just starting DT conversion, we mostly care about the !DT
> base in which the struct gen_pool * is passed in pdata to the ASoC
> driver. It is then selectable on a per-platform basis where the decision
> should be made.
>
> Given a separate discussion with Sekhar, we're only going to have one
> SRAM pool on any DaVinci part right now...this was only a question on
> L138 anyway. But regardless, the created gen_pool will be passed via
> pdata.
I thought about this too, as mmp does it that way.
> Since DT conversion is starting and we need to consider that now,
> the idea there is to use the DT-based generic sram driver [1] such that
> when we do boot from DT on Davinci, the genpool is provided via phandle
> and the pointer extracted with the OF helpers that are part of the
> series.
A phandle is the cleanest way I think, yes.
> That's pretty much it. I'm reworking the backend support as discussed
> with Sekhar wrt to my uio_pruss series. I can post a standalone series
> that just replaces sram_* with genalloc for davinci ASoC.
As you can also test it, it would be easiest if you came up with a patch
for that, yes. I can have a look at the dma bits laters, once my OMAP
board finally works with the code as it currently stands. I'm still
fighting with the mcasp driver right now ...
Daniel
^ permalink raw reply
* [alsa-devel] [PATCH 2/3] ASoC: Davinci: pcm: add support for sram-support-less platforms
From: Matt Porter @ 2012-10-02 16:41 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <506AEF57.2000306@gmail.com>
On Tue, Oct 02, 2012 at 03:42:47PM +0200, Daniel Mack wrote:
> On 02.10.2012 13:06, Sekhar Nori wrote:
> > On 10/2/2012 4:03 PM, Daniel Mack wrote:
> >> On 02.10.2012 11:37, Mark Brown wrote:
> >>> On Tue, Oct 02, 2012 at 10:48:53AM +0300, Peter Ujfalusi wrote:
> >>>
> >>>> I also agree that ifdef is not a good solution.
> >>>> It is better to have this information passed as device_data and via DT it can
> >>>> be decided based on the compatible property for the device.
> >>>
> >>> That's not really the problem here - the problem is that the APIs used
> >>> to get the SRAM are DaVinci only so it's not possible to build on OMAP
> >>> or other platforms. The SRAM code needs to move to a standard API.
> >>
> >> What about following Matt Porter's idea and ignore the SRAM code
> >> entirely and port the entire PCM code to generic dmaengine code first?
> >> The EDMA driver needs to learn support for cyclic DMA for that, and I
> >> might give that a try in near future.
> >>
> >> Later on, the SRAM ping-pong code can get added back using genalloc
> >> functions, as Sekhar proposed. That needs to be done by someone who has
> >> access to a Davinci board though, I only have a AM33xx/OMAP here.
> >
> > We cannot "get rid" of SRAM code and add it back "later". It is required
> > for most DaVinci parts. The SRAM code can be converted to use genalloc
> > (conversion should be straightforward and I can help test it) and the
> > code that uses SRAM can probably keep using the private EDMA API till
> > the dmaengine EDMA driver has cyclic DMA support. Matt has already
> > posted patches to move private EDMA APIs to a common location. That
> > should keep AM335x build from breaking. Is this something that is feasible?
>
> Yes - by "later" I just meant in a subsequent patch. But you're probably
> right, we can also do that first.
>
> I'm looking at that right now and the problem seems that we don't have a
> sane way to dynamically look up gen_pools independently of the actual
> run-time platform. All users of gen_pools seem to know which platform
> they run on and access a platform-specific pool. So I don't currently
> see how we could implement multi-platform code, gen_pools are fine but
> don't solve the problem here.
>
> Would it be an idea to add a char* member to gen_pools and a function
> that can be used to dynamically look it up again? If a buffer with a
> certain name exists, we can use it and install that ping-pong buffer,
> otherwise we just don't. While that would be easy to do, it's a
> tree-wide change.
>
> Is there a better way that I miss?
At the high level there's two platform models we have to handle, the
boot from board file !DT case, and then the boot from DT case. Since
Davinci is just starting DT conversion, we mostly care about the !DT
base in which the struct gen_pool * is passed in pdata to the ASoC
driver. It is then selectable on a per-platform basis where the decision
should be made.
Given a separate discussion with Sekhar, we're only going to have one
SRAM pool on any DaVinci part right now...this was only a question on
L138 anyway. But regardless, the created gen_pool will be passed via
pdata. Since DT conversion is starting and we need to consider that now,
the idea there is to use the DT-based generic sram driver [1] such that
when we do boot from DT on Davinci, the genpool is provided via phandle
and the pointer extracted with the OF helpers that are part of the
series.
That's pretty much it. I'm reworking the backend support as discussed
with Sekhar wrt to my uio_pruss series. I can post a standalone series
that just replaces sram_* with genalloc for davinci ASoC.
-Matt
^ permalink raw reply
* [PATCH v2 2/5] iommu/omap: Merge iommu2.h into iommu.h
From: Tony Lindgren @ 2012-10-02 16:40 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1349131591-10804-2-git-send-email-ido@wizery.com>
* Ido Yariv <ido@wizery.com> [121001 15:48]:
> Since iommu is not supported on OMAP1 and will not likely to ever be
> supported, merge plat/iommu2.h into iommu.h so only one file would have
> to move to platform_data/ as part of the single zImage effort.
Thanks I'll be applying patches 2 - 5 once we have -rc1 available.
Regards,
Tony
^ permalink raw reply
* make dtbs in linus/master
From: Stefano Stabellini @ 2012-10-02 16:36 UTC (permalink / raw)
To: linux-arm-kernel
Hello,
I am testing linus/master after the recent merge with the arm-soc tree
and I find that if I choose:
ARM system type
1. Allow multiple platforms to be selected (ARCH_MULTIPLATFORM) (NEW)
2. ARM Ltd. Integrator family (ARCH_INTEGRATOR)
3. ARM Ltd. RealView family (ARCH_REALVIEW)
> 4. ARM Ltd. Versatile family (ARCH_VERSATILE)
in my kernel config, then "make dtbs" doesn't work.
However if I choose ARCH_MULTIPLATFORM then it works properly.
Is it expected?
Cheers,
Stefano
^ permalink raw reply
* [PATCH v2 1/5] [media] omap3isp: Fix compilation error in ispreg.h
From: Tony Lindgren @ 2012-10-02 16:31 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1349131591-10804-1-git-send-email-ido@wizery.com>
* Ido Yariv <ido@wizery.com> [121001 15:48]:
> Commit c49f34bc ("ARM: OMAP2+ Move SoC specific headers to be local to
> mach-omap2") moved omap34xx.h to mach-omap2. This broke omap3isp, as it
> includes omap34xx.h.
>
> Instead of moving omap34xx to platform_data, simply add the two
> definitions the driver needs and remove the include altogether.
>
> Signed-off-by: Ido Yariv <ido@wizery.com>
I'm assuming that Mauro picks this one up, sorry
for breaking it.
Acked-by: Tony Lindgren <tony@atomide.com>
> ---
> drivers/media/platform/omap3isp/ispreg.h | 6 +++---
> 1 file changed, 3 insertions(+), 3 deletions(-)
>
> diff --git a/drivers/media/platform/omap3isp/ispreg.h b/drivers/media/platform/omap3isp/ispreg.h
> index 084ea77..e2c57f3 100644
> --- a/drivers/media/platform/omap3isp/ispreg.h
> +++ b/drivers/media/platform/omap3isp/ispreg.h
> @@ -27,13 +27,13 @@
> #ifndef OMAP3_ISP_REG_H
> #define OMAP3_ISP_REG_H
>
> -#include <plat/omap34xx.h>
> -
> -
> #define CM_CAM_MCLK_HZ 172800000 /* Hz */
>
> /* ISP Submodules offset */
>
> +#define L4_34XX_BASE 0x48000000
> +#define OMAP3430_ISP_BASE (L4_34XX_BASE + 0xBC000)
> +
> #define OMAP3ISP_REG_BASE OMAP3430_ISP_BASE
> #define OMAP3ISP_REG(offset) (OMAP3ISP_REG_BASE + (offset))
>
> --
> 1.7.11.4
>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-omap" in
> the body of a message to majordomo at vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* [alsa-devel] [PATCH 2/3] ASoC: Davinci: pcm: add support for sram-support-less platforms
From: Matt Porter @ 2012-10-02 16:30 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <506AC303.9080906@gmail.com>
On Tue, Oct 02, 2012 at 12:33:39PM +0200, Daniel Mack wrote:
> On 02.10.2012 11:37, Mark Brown wrote:
> > On Tue, Oct 02, 2012 at 10:48:53AM +0300, Peter Ujfalusi wrote:
> >
> >> I also agree that ifdef is not a good solution.
> >> It is better to have this information passed as device_data and via DT it can
> >> be decided based on the compatible property for the device.
> >
> > That's not really the problem here - the problem is that the APIs used
> > to get the SRAM are DaVinci only so it's not possible to build on OMAP
> > or other platforms. The SRAM code needs to move to a standard API.
>
> What about following Matt Porter's idea and ignore the SRAM code
> entirely and port the entire PCM code to generic dmaengine code first?
> The EDMA driver needs to learn support for cyclic DMA for that, and I
> might give that a try in near future.
>
> Later on, the SRAM ping-pong code can get added back using genalloc
> functions, as Sekhar proposed. That needs to be done by someone who has
> access to a Davinci board though, I only have a AM33xx/OMAP here.
I already backed away from that idea since the older SoCs without a
FIFO absolutely need ping-pong buffering in SRAM.
-Matt
^ permalink raw reply
* [alsa-devel] [PATCH 2/3] ASoC: Davinci: pcm: add support for sram-support-less platforms
From: Matt Porter @ 2012-10-02 16:28 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <506A9C65.5040309@ti.com>
On Tue, Oct 02, 2012 at 10:48:53AM +0300, Peter Ujfalusi wrote:
> On 09/22/2012 06:33 PM, Mark Brown wrote:
> > On Fri, Aug 31, 2012 at 06:20:58PM +0530, Hebbar, Gururaja wrote:
> >
> >> +config SND_DAVINCI_HAVE_SRAM
> >> + bool
> >> + default y if ARCH_DAVINCI=y
> >> + default n if ARCH_OMAP=y
> >> +
> >
> > I've been sitting on this mostly since it seems like a step back from
> > multi-platform kernels (which is where we're trying to get to) and I've
> > been trying to decide what the best approach is. I'm thinking that we
> > do want a generic API for allocating this stuff, it's a fairly generic
> > feature (there's TCMs as well).
> >
> > Adding ifdefs like this does just doesn't seem good.
>
> I also agree that ifdef is not a good solution.
> It is better to have this information passed as device_data and via DT it can
> be decided based on the compatible property for the device.
The driver is going to be used by both !DT and DT only platforms for a
while so DT-centric solutions just don't make sense. There's a clean way
to do this that was used for uio_pruss.c. When davinci is further along
on DT conversion we can make use of the devicetree-based generic sram
driver that's progressing along right now [1]. It needs some minor help
to allow specifying the gen_pool allocation order, but it will work
nicely for getting access to the right sram pool.
-Matt
[1] https://patchwork.kernel.org/patch/1421961/
^ permalink raw reply
* [PATCH v2 4/7] ARM: davinci: Add support for an L3RAM gen_pool
From: Matt Porter @ 2012-10-02 16:20 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <506ACC77.9090604@ti.com>
On Tue, Oct 02, 2012 at 04:43:59PM +0530, Sekhar Nori wrote:
> On 10/1/2012 7:20 PM, Ben Gardiner wrote:
> > On Mon, Oct 1, 2012 at 8:32 AM, Matt Porter <mporter@ti.com> wrote:
> >> On Mon, Oct 01, 2012 at 05:34:02PM +0530, Sekhar Nori wrote:
> >>> Hi Matt,
> >>>
> >>> On 9/29/2012 1:07 AM, Matt Porter wrote:
> >>>> L3RAM (shared SRAM) is needed for use by several drivers.
> >>>> This creates a genalloc pool and a hook for the platform code
> >>>> to provide the struct gen_pool * in platform data.
> >>>>
> >>>> Signed-off-by: Matt Porter <mporter@ti.com>
> >>>
> >>> I am not sure if any of the DaVinci devices have a need to allocate from
> >>> *both* ARM RAM and shared RAM. Shared RAM is not present on all DaVinci
> >>> devices AFAIR, and on DA850, there is just 8KB ARM RAM so I am not sure
> >>> if there is much point in trying to allocate from there.
> >>>
> >>> Can you instead see if Ben's earlier patch[1] to use shared RAM for SRAM
> >>> allocation on DA850 makes sense for your case? If yes, can you repost
> >>> with Ben's patch included in your series instead of this patch? I would
> >>> prefer that over creating a new pool for shared RAM.
> >>
> >> Hrm, I did look at Ben's earlier patch. The reason I added a separate
> >> pool mostly was so I didn't have to touch the PM code at all. That can
> >> continue using the private SRAM API with the ARM RAM as it is now. The
> >> idea here was to allow that to be separate since no other bus masters
> >> can access the ARM RAM anyway and do something that didn't require
> >> regression testing PM. Also, I figured there's really no reason to use
> >> even a tiny bit of the shared SRAM on PM if we have that ARM RAM there
> >> and working fine for that use case.
> >> [...]
> >
> > I agree with Matt. Preserving the use of the ARM RAM (8K on L138 -- as
> > you said, Sekhar) in any fashion is preferable to moving suspend
> > support into shared RAM. There is more of it (128K on L138) but also
> > more pressure on allocations there since there are more clients.
>
> There is where I would like to see more information on who the potential
> clients are. Even if DSP takes away 64K of the shared RAM on OMAP-L138,
> there should be more than enough for PM, Audio and PRU. I haven't
> checked the PM code size lately but it should be fairly small and I can
> check the actual number if that helps. So, adding a new pool just to
> save on those bytes doesn't sound like helping a lot.
The only wildcard is PRU usage due to the small per-PRU memory on PRUss
v1...though no sense in speculating further until somebody demonstrates a
need.
> > I appreciate that you are trying to preserve prior efforts in
> > attempted merging of SRAM support -- thank you for that; however, that
> > patch [1] was just an import of Subashish Ghosh's patch [2] -- I
> > chose _that_ implementation option then mainly because I imagined it
> > would be the least risky to get accepted upstream and not because of
> > any particular technical merits.
>
> Its not a question of prior effort since Matt has already put in the
> effort too. I am yet unconvinced that we need to add support to manage
> two blocks of SoC internal RAM on DA850 in the kernel today. That's all.
Yeah, I've come to agree with that. If somebody ends up needing that
extra 8K of local ram on L138 then they can add support.
-Matt
^ permalink raw reply
* [PATCH v2 4/7] ARM: davinci: Add support for an L3RAM gen_pool
From: Matt Porter @ 2012-10-02 16:14 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <506ABBCF.8010009@ti.com>
On Tue, Oct 02, 2012 at 03:32:55PM +0530, Sekhar Nori wrote:
> On 10/1/2012 6:02 PM, Matt Porter wrote:
> > On Mon, Oct 01, 2012 at 05:34:02PM +0530, Sekhar Nori wrote:
> >> Hi Matt,
> >>
> >> On 9/29/2012 1:07 AM, Matt Porter wrote:
> >>> L3RAM (shared SRAM) is needed for use by several drivers.
> >>> This creates a genalloc pool and a hook for the platform code
> >>> to provide the struct gen_pool * in platform data.
> >>>
> >>> Signed-off-by: Matt Porter <mporter@ti.com>
> >>
> >> I am not sure if any of the DaVinci devices have a need to allocate from
> >> *both* ARM RAM and shared RAM. Shared RAM is not present on all DaVinci
> >> devices AFAIR, and on DA850, there is just 8KB ARM RAM so I am not sure
> >> if there is much point in trying to allocate from there.
> >>
> >> Can you instead see if Ben's earlier patch[1] to use shared RAM for SRAM
> >> allocation on DA850 makes sense for your case? If yes, can you repost
> >> with Ben's patch included in your series instead of this patch? I would
> >> prefer that over creating a new pool for shared RAM.
> >
> > Hrm, I did look at Ben's earlier patch. The reason I added a separate
> > pool mostly was so I didn't have to touch the PM code at all. That can
> > continue using the private SRAM API with the ARM RAM as it is now. The
>
> But you dont have to touch the PM code. PM code can continue using SRAM
> API. I have verified in the past that PM can work using shared RAM.
>
> > idea here was to allow that to be separate since no other bus masters
> > can access the ARM RAM anyway and do something that didn't require
> > regression testing PM. Also, I figured there's really no reason to use
> > even a tiny bit of the shared SRAM on PM if we have that ARM RAM there
> > and working fine for that use case.
>
> I see no reason why PM would break with shared RAM. I have not even seen
> reports of shared RAM being short of size so we need to save space by
> having PM code in ARM RAM. I can test the changes before the code is
> committed and it will get tested in linux-next as well.
Ok, sounds good to me.
> > The other thing is that Ben's patch needs to be rewritten to at least
> > have the hook I added so we can provide the gen_pool in platform data.
> > If you prefer this path still, I can add the needed hook on top of his
> > original patch. Ultimately, I only *need* genalloc support for the
> > shared sram so I can remove the private SRAM API from uio_pruss...so I'm
> > happy with any way to get at it.
>
> Right, I prefer just adding the hook so that genalloc can be used along
> with SRAM API.
Ok.
> > Oh, and to be honest...it's not just for uio_pruss, but also to cleanly
> > remove the private SRAM API usage from the davinci ASoC driver too.
>
> Audio can use the shared RAM too. And once all users of the SRAM API are
> gone, only the hook to help pass the gen_pool as platform data needs to
> remain.
Right, I think we are on the same page now. I'll post an update to Ben's
original patch with required gen_pool hook for pdata use.
I noticed the beginning of DT support for davinci and the DT-based
genalloc driver, https://patchwork.kernel.org/patch/1421961/, fits
into that well.
-Matt
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox